[cairo] Spot colors (and CMYK)
spitzak at gmail.com
Tue Feb 16 12:08:49 PST 2010
Kai-Uwe Behrmann wrote:
> There is no one colour space. sRGB is one of many.
However we all agree that unclamped sRGB values can be converted to all
other 3-dimensional color spaces, including XYZ and Lab. So it is
sufficient for all 3D spaces.
> All colour management experts will agree that it is not possible to
> spcify (CMY) K behaviour with RGB or whatever tripples.
Obviously mathematically a 4D space cannot map to a 3D space without
multiple values mapping to the same one. However from all the discussion
here it appears that ALL color management is done by passing through an
intermediate 3D space, so this loss of data is apparently not a real
Therefore the 4D space is only useful for a device-specific api. All
device independent interpretation is done by reducing to 3D, therefore
the application can do the 3D reduction itself and use the 3D sRGB api.
>> MAYBE there needs to be a channel to communicate that a specific device
>> color is needed.
> This approach is inflexible. It might easly end in having such special
> cases for the same task with many backends.
That is EXACTLY what I intended. I want to make absolutely certain that
none of this crap has to be defined by Cairo. I believe that 100% of the
use of any such api is "get this stuff I need into the pdf" and
therefore the closer the api resembles "the stuff in the pdf" the better.
> Broken software needs to be fixed. A screenshot needs the monitors ICC
> profile attached if it has no other means to know about the image data.
> A screenshot with the monitors ICC profile will show equal on the same
> monitor and on monitor with larger gamut. Some shifts for very saturated
> colours can happen on smaller gamut monitors.
You are living in a fantasy world if you believe screen shots have ICC
profiles attached. This is not true even on OSX.
More importanly, "attached profiles" are NOT WANTED, EVER! I work with
professional image processing software, and we long ago learned that
attached profiles are NEVER wanted. We ignore them in png, we ignore
them is exif files, we ignore them in Red camera data. One of the
biggest pains at The Foundry is figuring out how to ignore profiles in
Apple Quicktime files and get the raw data. Please take a look at the
Nuke release notes if you don't believe me. This crap is occupying at
least one developer 100% of the time and many other are working on it.
Currently Nuke is using ffmpeg whenever possible, it reports raw YUV
values and we do a FIXED and predictable conversion to sRGB. THIS IS
WHAT USERS WANT!!!!
In real software, "correctly displaying" is a very very very rare
desire. "lossless in/out" is ENORMOUSLY more important. And I am sorry
to report, but users think that "strip the profile" and "display with a
program that ignores the profile" should be lossless operations. No
arguing from color theorists is going to change this and we have to live
with that fact and make software that is actually user friendly.
> Of course. Your "solution" does not work on multi monitor situations.
I don't know what you are talking about. My solution is the ONLY way I
can see to work on multiple monitors. The input to Cairo has to be in a
defined fixed color space, and then it can be converted as needed
correctly to each monitor. I do not think any application should have to
change the data it sends depending on the monitor.
> screenshots almost always are intented for remote observers, it is clear
> that colour management is the solution for that main use case.
That is nonsense. Screenshots are used locally. I want to look at a
pixel with a color picker and know exactly what values software needs to
communicate to Cairo or whatever to get the same color. I want to paint
on that screen shot and send it back to the first user and they see the
same colors they got initially. "color management" makes this impossible.
> question must be: can I produce a screenshot which looks identical on my
> laptop, my desktop computer monitor and on the monitor of others. Non
> broken adn correctly colour managed software together with correctly
> configured hardware can this.
Absolutely you can do this. Cairo will return a "screen shot" as sRGB
values. You then send it to another screen as sRGB values. And it will
look "identical". In a perfect world this means that advanced color
correction will cause the display to emit exactly the photons defined by
sRGB and all your devices will be emitting these exact same photons.
In the real world you have to remember that "identical" means that if
there are 256 levels in the image, I better get 256 different output
levels. If I pick a color off the image and put it into my painting
program and then display that painting I must get the same color. If
there is a beautifully dithered smooth gradient in the image, I better
not see banding or posterization. A ramp that is as smooth as possible
better not have Mach highlights in it (which would be caused by a lookup
table that clamps or otherwise does not have a continuous derivative).
I think that color theorists are ignoring the above. Users think that
huge skews in the emitted photons are "identical" but consider problems
like I have listed to be unacceptable differences. Color theorists have
got to learn how the real world works. We are not looking at flat fields
of color, we are looking at images with tons of information stored in
the higher frequencies and that information must be preserved!
> The hardware configuration is often enough automatic (EDID).
I would agree. If possible Cairo should be using such settings to
convert sRGB data to emit the correct colors from the screen. However
this has nothing to do with the Cairo application API.
> This is completely wrong. If a program wants a good usage of hardware
> then it needs to supply colours close to the hardwares colour space.
Stop pretending the sRGB data is clamped! It is not and can specify any
color in any well-known 3D color space.
>> sRGB values must be sent to the display, or color management must be
>> done by hardware between the buffer and the display.
> In the cable?
Yes, if the buffer is only 8 bits then that is the ONLY possibility.
There are only two possible designs:
1. The buffer contains sRGB values and output hardware converts them to
the display. This is the ONLY solution if the buffer is 8 bits as there
must be 8 bits of fractional resolution so that images are lossless. If
your display has a larger gamut then either it cannot display the full
gamut, or a *SIGNED* format with at least 8 bits of fraction must be
used (16 bit half is probably best as it has hardware support, if you
insist on integers than an offset with a range like -.5 to 1.5 is
needed). Note that unsigned larger than 8 bits is almost useless.
2. The buffer contains values that are linearly related to what the
hardware requires, this can use clamped integers. As round-trip
conversion of 8-bit sRGB must be the identity, this requires I believe
10 bits for Adobe RGB and even more bits for higher gamuts. As
compositing will be done in this space and this puts serious limits on
the gamma, it cannot vary too much from sRGB due to applications relying
on 1-x being perceptually inverted and how partial transparency composites.
Notice that if the buffer is 8 bits and there is no hardware conversion,
then the only possible implementation is to claim that the buffer
contains sRGB data. It does not matter how screwed up the display is,
that is the best you are going to get.
More information about the cairo