![]() Some people don't do the mental switch between "I'll wait for fix" and "I'll fix it" if they're not used to it, even if they are perfectly capable of fixing it and have time for it. I suspect he might be able to provide this particular fix himself - or, if he isn't, then he might be able to contribute by providing a well-detailed feature request for others to implement (with that even I might be able to go and fix it, while without it I surely won't, as I lack the knowledge, hardware and in fact even awareness of this problem only reading this post put some light on it for me). The author seems to be technical enough to make a nice analysis of what's done and what needs to be done. Well, at least when ignoring the UI/UX mention that has absolutely nothing to do with the discussion here (color correction is required in many fields, but UI and UX aren't really those ones). and this type of replies is why it stays that way. So you'd much rather do the conversion before throwing away the extra precision, assuming the application was working in greater than 24-bit pixels. When you do a naive linear conversion of whatever precision color the application is operating in down to the 24-bit rgb frame buffer, you've lost the increased accuracy in the regions that happen to actually be more significant on a given display. To clarify, the reality implied by the need for correction is that some areas of the 0-256 range of values are more significant than others. But this is what I've come to understand is the nature of the issue. ![]() I'm not an expert in this field at all, just play with graphics hacks. change the entire system to have more bits per color component all the way down to the framebuffer, then the per-component LUTs at the CRTC can profitably contain > 256 entries. inform the software of the LUT and let it perform the transform before it packs the pixels for displayĢ. ![]() This is why it's desirable to do one of the following:ġ. If by "video LUT" you mean something at the CRTC or even after it on some external device, if the software producing the visuals has already reduced the pixels down to 8-bits-per-component before they hit the LUT, then you've lost accuracy particularly in the small values. I know just from writing graphics hacks that you get significantly better results if you do the correction in the HDR color space before you produce the 24-bit, 8-bits-per-component pixels shipped to the GPU. If I only want to make things look "better" in my linux kiosk, and care not about absolute color correctness, let me stick a drm.gamma=.55 field on the kernel commandline to generate the correction table in lieu of a full calibrated table. Hell there are fairly well-known simple algorithms for generating approximate color tables from a single gamma value. I should be able to tell the kernel the correction table, maybe compile it in, or another payload on the boot parameters cmdline. Programs like Plymouth or other embedded style applications running directly on libdrm should be able to have color-corrected output without needing bespoke software implementations and their own calibration tables. If not floats, at least more bits than 8 per color component. I don't want to be forced into OpenGL/Vulkan just to be able to have the hardware apply gamma correction on a software-rendered frame buffer, and if I have the hardware do color correction, it kind of needs the HDR of floats - not uchars, which I don't think libdrm supports with dumb buffers of today. We also need floating point frame buffers to be first-class citizens at the KMS level. ![]() Then the layers up the stack like Wayland/X/GNOME/KDE are just messengers to/from the bottom drm. But always be able to read it out, make it linear nonsense when the support isn't there - that won't be worse than what we have now. It should just be part of the video mode, maybe with a bit to indicate when the driver/hardware doesn't support changing it. It's unclear to me why there's no color palette/correction table exposed in libdrm/KMS at the kernel.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |