3 ms·

What is the real-life difference between saturation cranked up via software compared to a screen with inherent high saturation?

001sky 14y ago
More gamut -> less cross-processing of the image. http://en.wikipedia.org/wiki/Color_management http://en.wikipedia.org/wiki/Color_management (see section on rendering intents)
kevingadd 14y ago
Cranking up saturation in software is likely to introduce artifacts due to the precision of the data being sent to the panel. For example, most framebuffers are still at most represented with 24 (color) bits per pixel, and the signals being sent from the GPU to the display may not have much more precision than that either (how much precision they have can depend on a variety of factors). The immediate consequences of this: User-mode software is unlikely to be able to increase saturation without hardware assistance, because it ultimately has to send 24bpp pixel data to the GPU. The dynamic range possible in 24bpp is pretty limited when you factor in what happens to it after it goes through the rest of the pipeline. Kernel-mode code, drivers, and firmware on a GPU can potentially adjust saturation more accurately by sending higher-precision color values out to the display, if it supports it. Not many displays today support higher than 24bpp precision, but such displays do exist. Unfortunately, the inputs from user-mode software were 24bpp, so some accuracy has already been lost and any lost accuracy will be compounded by saturation changes produced at this level. Finally, the display itself may actually be reducing the quality of input signals - many panels have less than 8 bits per channel (24bpp = 3 channels) of precision and represent higher accuracy signals with dithering and other techniques. This can make the result of adjusting saturation in software even worse. So, in practice, adjusting saturation in software will produce visible artifacts for images that need high dynamic range or high precision.

001sky 14y ago

More gamut -> less cross-processing of the image. http://en.wikipedia.org/wiki/Color_management http://en.wikipedia.org/wiki/Color_management (see section on rendering intents)

kevingadd 14y ago

Cranking up saturation in software is likely to introduce artifacts due to the precision of the data being sent to the panel. For example, most framebuffers are still at most represented with 24 (color) bits per pixel, and the signals being sent from the GPU to the display may not have much more precision than that either (how much precision they have can depend on a variety of factors). The immediate consequences of this: User-mode software is unlikely to be able to increase saturation without hardware assistance, because it ultimately has to send 24bpp pixel data to the GPU. The dynamic range possible in 24bpp is pretty limited when you factor in what happens to it after it goes through the rest of the pipeline. Kernel-mode code, drivers, and firmware on a GPU can potentially adjust saturation more accurately by sending higher-precision color values out to the display, if it supports it. Not many displays today support higher than 24bpp precision, but such displays do exist. Unfortunately, the inputs from user-mode software were 24bpp, so some accuracy has already been lost and any lost accuracy will be compounded by saturation changes produced at this level. Finally, the display itself may actually be reducing the quality of input signals - many panels have less than 8 bits per channel (24bpp = 3 channels) of precision and represent higher accuracy signals with dithering and other techniques. This can make the result of adjusting saturation in software even worse. So, in practice, adjusting saturation in software will produce visible artifacts for images that need high dynamic range or high precision.