Hello Hans, Thanks for the comments and good to know that V4L2 already has something similar. It would be great to have something to compare / discus with :) Yes, I agree that we can share a color library which can use any interface underneath. Once we have some framework level stability, I would like to hear about it from you. We are planning to publish the implementation soon, and it would be great to hear from you on the implementations. You can have a look at the code and we can discuss about the implementation point by point. Regards Shashank -----Original Message----- From: Hans Verkuil [mailto:hverkuil@xxxxxxxxx] Sent: Friday, June 26, 2015 5:27 PM To: Sharma, Shashank; 'robdclark@xxxxxxxxx'; 'alexander.deucher@xxxxxxx'; 'bskeggs@xxxxxxxxxx'; dri-devel@xxxxxxxxxxxxxxxxxxxxx Cc: Matheson, Annie J; R, Dhanya p; Pillai, Manikandan K; Mukherjee, Indranil; Barnes, Jesse; Smith, Gary K; Palleti, Avinash Reddy; Kamath, Sunil; Vetter, Daniel; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Bhattacharjee, Susanta Subject: Re: Color management in DRM framework Hi Shashank, I have been working on support for colorspace handling for V4L2 (video capture), basically the flip-side of the coin that you are working on. While both the V4L2 and DRM/KMS APIs are completely different, the part that does the matrix calculations can be shared between the two. I would prefer that to be something that lives in lib and can be used by both. I noticed that you use 16.16 fixed point for the primaries, which is a bit on the low side w.r.t. precision in my opinion. What is the precision used for the internal calculations? That was not immediately obvious to me from the code. In my implementation I've chosen to go with a fixed point 32.32 format. See an initial implementation here (search for fixp64_t): http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/tree/include/media/v4l2-dv-timings.h?h=csc I don't have a div_fixp64 yet as I do not need it at the moment. But the 'Hacker's Delight' book has code for that as well, so that can be added. I didn't see any code for handling limited and full range quantization, but I suspect that's done elsewhere in DRM/KMS? Regards, Hans On 06/25/2015 06:19 PM, Sharma, Shashank wrote: > Gentle reminder for the review and comments. > > > > For those who prefer having the design available with the mail, I am attaching a PDF copy of the design document with this mail. > > It would be great for us to hear from you guys, on this. > > > > Regards > > Shashank > > *From:*Sharma, Shashank > *Sent:* Monday, June 22, 2015 7:09 PM > *To:* robdclark@xxxxxxxxx; alexander.deucher@xxxxxxx; > bskeggs@xxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx > *Cc:* Smith, Gary K; Barnes, Jesse; Lespiau, Damien; Roper, Matthew D; > Vetter, Daniel; Bhattacharjee, Susanta; Matheson, Annie J; Malladi, > Kausal; Mukherjee, Indranil; Kamath, Sunil; Pillai, Manikandan K; > Palleti, Avinash Reddy; R, Dhanya p > *Subject:* Color management in DRM framework > > > > Hi Rob, Alex, Ben, All J > > > > I am Shashank Sharma, from Linux display team Intel, Bangalore. > > We are planning to add a color management extension in the existing I915 driver, for Intel HWs. > > Plan was to provide a color correction and enhancement interface for any Linux based userspace, based on various HW capabilities. > > > > We are now thinking that if we can generalize this implementation, in such a way that other drivers can also utilize this, this idea can act as an extension to the DRM framework itself. > > Based on that thought, We have prepared a design for the same, and a rough implementation based on this design. > > > > Would you all be kind enough to have a look at this design, and give us some feedback, so that we can implement this in a way best suitable to most of the drivers ? > > We have gone through few rounds of design discussions internally (design contributors, reviewers in CC), and we all are moreover agree on the design (few comments still in progress). > > > > *The highlights of the design:* > > 1. The color correction capabilities of a HW are being registered as a DRM property of a CRTC / Plane (depending on a HW) > > 2. Properties will be of blob type. > > 3. New data structures will be added in DRM layer, to encoder and decode color correction and enhancement data. > > 4. The color correction DRM properties would look like : > > a. Palette correction / programming based color properties (like gamma correction). This can support various coefficients counts and correction values, based on the underneath HW. > > b. Color transformation matrix based color correction (CSC, wide and narrow gamut mapping) > > c. Plane level corrections like gamma correction, hue, saturation, contrast and brightness. > > d. One blob type property to showcase the color correction capabilities to the userspace, superset of all other color correction properties. > > 5. The driver’s init function can create the superset color property, and show its color capabilities to the userspace. > > 6. Userspace can query the current color correction Or apply a new color correction using a set/get property interface. > > > > Please find the detailed design, in this shared google document: > > https://docs.google.com/document/d/1jyfNSAStKHEpmIUZd_1Gd68cPuyiyr8wmJ > XThSDb_2w/ > > Please feel free to add more people in the design discussion, once we have some basic agreement on the design, we will share the patches in dri-devel level. > > > > Regards > > Shashank > > > > > > > > > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
