| |||||||||||||
SCALE 8x: Color management for everyoneSCALE 8x: Color management for everyonePosted Mar 4, 2010 14:28 UTC (Thu) by farnz (guest, #17727)In reply to: SCALE 8x: Color management for everyone by ssam Parent article: SCALE 8x: Color management for everyone
sRGB isn't the only standard RGB colourspace. Just off the top of my head, I can think of sRGB, Adobe RGB, BT.709 RGB, CIE 1931 RGB and I'm sure there are more out there. I can very easily find images in three of those colourspaces (my digital camera can produce two of them, I can get a third by grabbing a frame from BBC HD and converting from YUV to RGB). Plus, many images aren't in an RGB colourspace to begin with; if the image is CMYK (common if it's being prepared for print), or some variation on YCbCr (common if it's from TV). The application needs to tell the graphics driver about all of this information if you're to get a precise match; what's more, not all colour values are in 8-bits per channel RGB; if I had 16-bit per channel CMYK, I'd like the graphics driver to know that I want a slightly darker red than the RGB tuple suggests, so that it knows which way to round error. This becomes more important on 30-bit displays (where an RGB tuple is three ten-bit values, not three 8-bit values), as the conversion formulae are not precise, and it would be nice to use the extra accuracy to improve colour reproduction.
(Log in to post comments)
SCALE 8x: Color management for everyone Posted Mar 4, 2010 15:02 UTC (Thu) by ssam (subscriber, #46587) [Link]
ok. so the application would just need to pass some colour space metadata along with the pixels.
SCALE 8x: Color management for everyone Posted Mar 5, 2010 23:39 UTC (Fri) by roelofs (guest, #2599) [Link] ok. so the application would just need to pass some colour space metadata along with the pixels.No--any application that does its own alpha-blending, for example, needs to convert the image(s) and background from their native color space(s) to linear (gamma = 1.0), do the compositing, and (usually) convert back. Other transformations (lighting/shading calculations and whatnot in 3D, IIRC) also require linear gamma for correctness. And it's hard to imagine a driver complex enough to support multi-source display app like a browser ("this block of pixels is linear, this block uses this custom ICC profile, that block is SGI/gamma-1.7, and everything else is sRGB"). Conceivably it's doable, but I'm not sure a driver is the best place for it. Greg
SCALE 8x: Color management for everyone Posted Mar 8, 2010 3:50 UTC (Mon) by psyquark (subscriber, #58373) [Link]
Almost.
All color triplets have a color space, either explicit or implicit. On a stand alone uncalibrated machine the implicit colorspace is the colorspace of the display. The problems start when sharing files with other computers, each of which has its own implicit colorspaces. Known colorspace to known colorspace mapping is doable but unknown colorspace to any colorspace is not feasible. To fix that the sRGB colorspace was created. It was defined to be a decent approximation of the standard displays of the time. The web standard became "If you don't know the space and care about color, treat it as sRGB."
The naive solution is to have the client handle all color management and output pixel values in the display's colorspace. This can be useful in cases when a specific or controlled rendering intent is needed to accommodate special needs. The problem is that client side management does not handle multiple outputs well. In fact, it is not possible for a client to handle simultaneous display on multiple outputs such as from software mirror to a projector or a visual pager application showing a preview on a second display.
The best solution is to have the Compositor handle the final colorspace conversion. It knows exactly where each pixel is going to be displayed because it will be putting that pixel there. There has been some work towards this (but not mentioned in any slides or the writeup) from a Google Summer of Code in 2008. It was called "Color Management Near X" and I believe the "net-color" standard. The solution was not to send colorspace with each pixel, but rather to set window properties defining the icc profile for the window or regions of the window. I should note that specifying client's colorspace to be the same as one of the outputs results in a null transform. That gives the application the same power as before, but allows the Compositor to give sane colors on other displays. Sadly I can't find much information on it with google.
As it stands "color managed applications" can display correctly on my wide-gamut LCD or my normal gamut LCD but not both. The colors will be flat wrong when they appear on the "other" output.
YUV and YCbCr irrelevant Posted Mar 4, 2010 23:07 UTC (Thu) by spitzak (guest, #4593) [Link]
Spaces such as YUV and YCbCr are not "color spaces" really. They are simply an encoding of an RGB space, and any definition of them will include the values of the R, G, and B primaries and the fact that they are YUV or YCbCr encoded. There is no such thing as a "Y primary" and certainly no such thing as a "Cb" primary (since there .5 is black!).
Claiming these are color spaces is equivalent to claiming that jpeg is a color space, rather than a compression algorithm.
YUV and YCbCr irrelevant Posted Mar 5, 2010 10:02 UTC (Fri) by farnz (guest, #17727) [Link] Depends on how you define a colour space; on the one hand, they are just a reversible transform from a known RGB colour space. On the other hand, practical YUV colour spaces, while sharing primaries with practical RGB colour spaces, tend to have different gamuts. Additionally, they only correspond perfectly under the assumption of infinite precision; in colour management situations, it's of interest to the output driver to know that when I ask for 8-bit BT601 RGB (236, 250, 255), it actually came from YUV (230, 140, 120), and thus if display RGB (237, 251, 255) corresponds to BT601 RGB (237, 251, 255) while display RGB (236, 250, 255) corresponds to BT601 RGB (235, 249, 255), the former is a closer approximation to the desired colour than the latter. YUV colour spaces differ from JPEG in a very important manner; JPEG is lossy by design, whereas YUV isn't lossy until you subsample. Any loss between an RGB and YUV colour space occurs due to loss of precision
|
|||||||||||||