[cairo] Spot colors (and CMYK)

[Chris Murphy]

On Feb 16, 2010, at 1:08 PM, Bill Spitzak wrote:

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

This is a redundant question, implicitly asked in another post:

How do you intend to pass colors which are specific in unclamped sRGB, into file formats which do not support unclamped sRGB? It seems you will necessarily limit the palette to that of sRGB which just seems laughable in 2010. This is not how devices work.

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

I don't see how you can get 100% of the stuff I have into a PDF, if there are two size boxes. One is too small for my stuff, and one is so big PDF cannot (presently) contain it.


> You are living in a fantasy world if you believe screen shots have ICC 
> profiles attached. This is not true even on OSX.

It has been true for about a decade, plus or minus a couple of years.


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

Well this explains everything. You're a very confused and ill informed person when it comes to embedded ICC profiles, their function, their history, and what we've learned over the years. It's like you're stuck in 1996.


> We ignore them in png, we ignore 
> them is exif files, we ignore them in Red camera data.

Oh my god, this is just painful to read. You must not understand at all what you're doing. There is a case to be made for validating such data and determining if the embedded profile information is obviously wrong (this is done in FireFox, and Photoshop for example), and rejecting it in favor of something else (an assumed source space). But if it's valid data and you're just rejecting it all wholesale? Then that is f|cking high order sabotage, there is no diplomatic way to put it.


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

Bull. Users want what they want. They can hardly articulate what they want, let alone articulate it with any consistency. I know that color management in video is a really appalling, idiotic and painful mess, but a lot of this results from legacy issues, and then also complete color management ignorance in certain instance where necessary metadata is lost in encoding, or encoded incorrectly, many issues with video.

> 
> In real software, "correctly displaying" is a very very very rare 
> desire. "lossless in/out" is ENORMOUSLY more important.

Ignoring color space information is data loss. What you're doing is lossy when you reject color profile information.


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

User friendly and completely incapable of producing consistent color, by design? Such software has no hope of communicating color intent, at all, down stream. This would be crap software, in my view. It's 2010 for crying out loud.


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

Agreed, the OS should do this.



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

You know. I love how you make all of these assumptions based on your own experience and then ridicule other use cases you've never thought of as nonsense. It makes me feel justified in ridiculing your color crippled software ideas, and sabotage of valid color profile metadata by ignoring it in favor of something you randomly prefer. It's ironic. I'm waiting in glee for the next stage of cognitive dissonance.


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


This is mental diarrhea. RGB values are meaningless without a color space attached to them. Color management enables the consistency you claim you're after. You can't get "the same color" with the "the same values".



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

You're the one in a fantasy world, because you assume that displays are all approximately sRGB-like. They aren't. So you need to stop touting sRGB as something that describes real devices. Some manufacturers do a lot of work to ensure their devices do correlate well to sRGB. Most do not. Printers definitely do not. Spot colors do not. CMYK does not.

Your screen shot, if always tagged sRGB, is essentially always bogusly tagged. Color intent will not be preserved. Almost certainly more valid would be to use a profile based on the display's EDID color primaries info.


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

Cute how you're casting all "color theorists" as goons staring at flat fields of color. It's beyond insulting to use that term so pejoratively, especially when it's not at all applicable. This kind of propaganda technique is old. We had these kinds of arguments back in, well it was 1996.

My clients are involved in fine art photography and image reproduction, as well as high end commercial printing and proofing. You are conflating a number of issues, and then using extremely condescending language while knowing nothing about the people you are directing your invective.

> 
>> 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" has been, since inception, and now for a very long time since, been used in vernacular reference to a clamped RGB color space. If you mean something else, then qualification falls on you. Not for the reader to assume.



Chris Murphy
Color Remedies (TM)
New York, NY
----------------------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"