Hacker News new | ask | show | jobs
by mark-r 3037 days ago
If you write the calibration info to the video LUT, why does software also need to know about it? Isn't your monitor displaying perfectly calibrated sRGB at that point?
3 comments

This is assuming all the content is sRGB, which is not a safe assumption especially if you care about color management to begin with.
If the content is not in sRGB, don't you need to actually know the contents color profile in order to convert it to sRGB? How does the monitor profile matter at this point?

(not challenging, just asking, I know next to nothing about color correction)

You don't want to convert to sRGB, you want to convert to the display device color space (which in professional displays is often larger than sRGB).

Most desktop environments and applications assume that the source is sRGB, unless specifically tagged (in image metadata).

So you have two points: source (image, video) and reproduction device (display, printer etc). And you convert colors from the former to the later. sRGB may not even come into play if the source image is AdobeRGB and the display is a wide-gammut pro LCD display!

Does the software know how to bypass the LUT, or do you in effect get a double conversion?
which LUT?
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 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.

This is why it's desirable to do one of the following:

1. inform the software of the LUT and let it perform the transform before it packs the pixels for display

2. 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.

I'm not an expert in this field at all, just play with graphics hacks. But this is what I've come to understand is the nature of the issue.

edit:

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. 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. 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.

Not necessarily. After calibration your monitor displays as accurately as it can sRGB (or any other profile you calibrated for). It still may miss or shift parts of sRGB though.

Thus your software has to know what your display is capable of. It can use this information to show you which parts of the photograph you edit are not shown accurately.

That would require a completely different profile, wouldn't it?