[cairo] Spot colors (and CMYK)

[Kai-Uwe Behrmann]

Am 17.02.10, 12:26 -0800 schrieb Bill Spitzak:
> Kai-Uwe Behrmann wrote:
>
>>> You are not claiming that Cairo needs to calculate how ink dot coverage
>>> will work when compositing images, are you? At least I hope not, but it
>>> sure sounds that way, that is pretty scary!
>> 
>> Ink dot coverage? What is that? I am no printer.
>
> Possibly I misunderstood. You said "users see the print simulation on 
> screen". Unless you are just using Cairo as a way to dump a CMYK image, the 
> composited result of Cairo is NOT going to be any kind of simulation, unless 
> we actually add compositing operators that are "act like you are printing ink 
> here on this device".

Cmyk and alpha is not my speciality. But I am shure this matter could be 
further thought out. However it is not the core of Cmyk, spot colour or CM 
support in cairo.
Most people in the graphics world can live with that Cmyk alpha imperfection.

> A 100% opaque filled shape or a 100% opaque image, except for the antialised 
> image, could produce exactly the predicted ink levels specified by some CMYK 
> api or from a spot-color interface. But any compositing or blending is not 
> going to produce a predictable color. The only predictable color would be to 
> use the output CMS to convert the composited sRGB image into output inks, but 
> this would produce a discontinuity with the solid areas that is unlikely what 
> the user wants or expects.

For a on monitor simulation it would be good enough. For printing the RIP 
takes resposibility. The spot colour or Cmyk would have to be mixed with 
alpha. That, I would guess, shall appear on print.

> My recommendation (no matter what is done about color management) is to say 
> that the results are unpredictable for any result that is not 100% some spot 
> color or some CMYK quad. But this means that the on-screen image is going to 
> be wrong for these areas.

Agreed. But, no one here is calling cairo to make a world leader in print 
simulation.

>>> I absolutely think that "simulate how the printer deposits ink" is a job
>>> for the application. It can calculate the resulting sRGB value and send
>>> that to Cairo. Cairo can then produce this simulation with as much
>>> accuracy as possible on various output devices. To actually control the
>> 
>> If the sRGB floats to montior RGB conversion is handled in the according 
>> cairo backend I agree. For printing, some users prefere to supply Cmyk 
>> directly. No deviceN in Cairo == no way to pass it to PDF.
>
> I always said there should be a way to specify the exact CMYK.

Fine.

> All I am doing is requiring the application to supply the sRGB alternative, 
> rather than having Cairo calculate it.

I am in doubt that this will lead to a compact, flexible and sufficient 
qualified colour API in cairo. It has drawbacks as well.

>> For the "sRGB only" model I would ilke to summarise some preconditions for 
>> a real CM API:
>> * float support in cairo, to allow negative values with sufficient
>>   precission
>
> Only the necessary precision to handle the output device space is needed. If 
> the output device is sRGB then an 8 bit/channel buffer with clamped 0-1 
> values can be used.
>
> If the output device is not sRGB then 16-bit half floats are probably needed, 
> though an offset fixed-point format with a range of -.5 to 1.5 would probably 
> work well.

Ok, half floats would be a good thing.

>> * a CMM which can handle floats precissely, lcms2 is on the path to that
>>   but not much tested yet
>
> lcms does have a floating point api, but it is likely the internal 
> implementation just uses integers. This is the sort of bug that makes me not 
> want Cairo to call such libraries!

Some years ago people rejected any idea to need more then 8-bit per 
channel ;-)  I wold say it needs time. And lcms moving to real floats as 
API and internal is a good sign.

> As full cms may not be needed (due to one of the targets being the fixed sRGB 
> target) it may be practical for an application to use it's own library in my 
> scheme.

As CMS hooks I am all for using a own CM library.

> Probably much more important is the need to support floating point images, 
> otherwise the replacement images are all going to be clamped to the sRGB 
> gamut.
> 
>> * APIs in cairo to tell a backend which colour space to convert to on
>>   output
>
> This is backend specific and only needed for backends that do not get this 
> information from somewhere else (such as the device or by assuming the device 
> is sRGB).
>
>> * embedd that ICC profile to the output by the cairo backend
>
> Again this is backend specific.
>
> I think you are concentrating on "produce a .png with my embedded profile"

Indeed. A generic way to handle and pass colour meta data.

> while I am concentrating on "produce the image with maximum color accuracy on 
> the output device the back end knows the full details of".

Hmm, I see no contrary in CM and "maximum color accuracy". I love both.
lcms1, the actual is not the best choice for colour management of floats, 
but as said above this hopefully changes soon. So I expect very good 
quality.

>> What I really wonder is the suggestion that floats might be no problem to 
>> implement in cairo but more than 3 channels are. Pretty all blending 
>> operations work in a single channel plus alpha. From that logic it makes a 
>> small difference if a image is
>> gray+alpha, duotone+alpha, rgb+alpha, cmyk+alpha ... deviceN+alpha
>
> The problem is simply that anything other than sRGB will require information 
> attached to it to specify exactly what it is. From what I have seen of color 
> management, this information is much much too complicated for a back end to 
> be forced to interpret.

lcms has a very easy to use API. It is a main factor to have already so 
many applications support CM on Linux.

> Floats are no problem for modern GPUs. If floats are a problem I believe all

Agreed.

> of color management is a problem and almost certainly not supported by the

CM is up to now almost a CPU thing on linux. Its GPU independent.

> device, which is why I am trying to design the conversion to sRGB to be 
> trivial, as this would be used by all simple devices.
>
>> But it remains a bottleneck compared to sending Cmyk to cairo. A
>> conversion must be somewhere anyway.
>
> Yes I understand that the composited operation would be faster.
>
> However in my experience I have needed the device-independent color spec 
> anyway. This is needed to produce predictable results or to show information 
> to the user, and to talk to back ends other than Cairo. In our software this 
> has defeated any such composites, and in fact we have to do considerable work 
> to extract half-composites from cms back ends (Nuke works in "linear sRGB" 
> which has no gamma curve, and the cms libraries are very poorly equipped to 
> handle input that does not follow a gamma curve, due to bad design of the 1D 
> lookup tables). We have pretty much given up on using cms libraries and now 
> do the conversion with our own code.

So you see quality problems with CM in your workflow. Thats interessting. 
I had perhaps similiar problems with lcms and CIE*XYZ and other big gamut 
differences in colour space conversions. This was really troublesome. 
However, I did not exact round trip tests for gamma as I work more with 
stills.

I think ICC has slowly came to adress round trip requirements for motion 
pictures in its cinema work group. An other initiative comes from ILM with 
the OpenEXR CMS called CTL. I would expect it to meet the needs of exact 
colour conversions in the motion picture industry. Did you evaluate that?

>> No no. Cairo should not directly interprete ICC profiles. There are 
>> libraries for that.
>
> There are libraries to choose and render fonts and lay out text too. Text 
> just took a few seconds to add to Cairo because of these libraries, it was so 
> amazingly easy! And the information required for pdf's was just instantly 
> available because of the magic ability of the library authors to think about 
> and predict exactly what pdf's needed! Wow, I am so impressed with the power 
> of libraries!</sarcasm>
>
> You say there is this new "device link profile" that is "not yet supported by 
> lcms or most other cms libraries". Okay, we are off to a great start as we

Device link profiles are well supported. Without that lcms would be really 
slow. Applications do not yet support deviec links at large. But it is 
coming.

> are already not supporting something and we haven't even written anything 
> yet!

I have written code to cirumvent cairos toy colour API. From that 
experience I would really like to see that stuff be handled inside cairo 
and see useful backends again.

As could be read from others emails there is already work on at least one 
prototype of CM inside cairo.

>>> Second you have limited the device description to whatever Cairo
>>> implements portably and without error, which from experience I know is a
>>> tiny subset even for very expensive commercial software. In particular
>> 
>> I cant follow here. Maybe my english. However a device description in form 
>> of a ICC profile is pretty flexible to convert to nearly any colour space 
>> which is in practical use today. So I would assume to convert from device X 
>> to device Y is not a problem for the ICC architecture.
>
> All CMS libraries I have ever encountered work with a very tiny subset of the 
> possible profiles. In particular they fail in spectacularly bad ways when you 
> combine unexpected profiles together (basically any pair other than a 
> computer screen and a printer was unreliable, so attempts to use these 
> libraries for linear sRGB in particular was useless).

Agreed, there are shortcomings in some implementations here and there. But 
thats the way of software. Bugs have to be fixed. In some CMS certain 
profiles are not useable as you say. This is a real cross platform 
problem. But using e.g. lcms this problem would be non existent as lcms is 
cross platform.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org