[Scribus] [announce] CMYK Patch gets image support

[Franz Schmid]

David Purton schrieb:
> Hi folks,
> 
> I finally uploaded a first up attempt at getting CMYK images working.
> 
> http://marshwiggle.net/scribus/
> 
> There is a tarball containing test files and what I say is the "correct"
> output for comparison. I also have a nice highres duotone of a cow
> cartoon (C and K channels) if anybody is interested in seeing how it
> goes. This cow has appeared in a real live text book, so I even know
> what it looks like printed.
> 
> 
> I'd be especially interested to hear from people who have emailed
> recently with CMYK image questions, as to whether this patch gives then
> better results.
> 
> 
> So what does it do?
> 
> I wasn't too sure, how to tackle this at first, but I noticed that at
> some points in the code, Scribus stores CMYK data in the RBGA channels
> of the QImage. There are many problems, associated with this technique,
> but it does work, providing you don't care about losing the alpha
> channel. You can still use the alpha channel if you only want to using
> RGB colours of course. I think so anyway...
> 
> So I've written a new function that loads images. You request the type
> of image you want, based on what it is for (proof for screen or RGB
> export, CMYK for CMYK export, RGB for ICC based export) The new LoadPict
> function does the colour management magic and gives you a QImage in the
> desired format. Kludgy and hardly a final solution, but it does at least
> output colours that I am happy with.
> 
> Only a fairly small subset of the seemingly infinite varieties of TIFF
> are handled - see the website for details. and TIFF is the only format
> that can be loaded as a CMYK image at this point. Greyscale and bilevel
> tiffs are also loaded as CMYK. I gave bilevel bitmaps a transparent
> background, because I like it that way :)
> 
> 
> Now for the weird bit. You will recall my comment last week about byte
> ordering differences in Little CMS and QImage. It took me a bit to
> figure out what was going on, but it would seem that this is the case.
> Here is some explanatory code:
> 
> // say we have an 8bit RGBA pixel, we can represent it with an unsigned
> // int:
> unsigned int colour;
> 
> // we can pull out the different channels using a pointer to char:
> char *p = (char *) colour;
> 
> // now Little CMS expects this to be the case:
> char red_lcms = p[0];
> char green_lcms = p[1];
> char blue_lcms = p[2];
> char alpha_lcms = p[3];
> 
> // seems obvious enough, but it would appear that the QImage class
> // doesn't use this ordering, instead doing this:
> char red_qimage = p[2];
> char green_qimage = p[1];
> char blue_qimage = p[0];
> char alpha_qimage = p[3];
> 
> // So what would happen is that the colour passed to little CMS
> // was passed in with the wrong ordering, and of course little CMS would 
> // think it was a *completely* different colour. But of course the
> // colour on the way out of little cms is then dumped back into the
> // QImage class and because they've again been reversed, it would look
> // sort of ok - unless you compared the same colours with the solid
> // colours.
> 
> 
> Strange, but true. Anyone want to offer some insight into this? LibTiff
> loads the tiff by default in the same order as needed by little CMS. Why
> would QImage be different? Is this an Endian Issue? Do others get this
> problem?
> 
> Anyway, I threw in some QImage::swapRGB() calls in appropriate places to
> fix things.
> 
> It might also be possible to pass TYPE_BGRA_8 to little CMS and leave
> things in the QImage order. But in this case you must swap your loaded
> tiff, so you still have messing around. *shrug*
> 
> 
> 
> The other thing, that is changed is out of Gamut Checking. From looking
> at the tifficc source and the little CMS documentation, I believe that
> when asking for out of gamut colours to be highlighted, you must set
> your LCMS flags to *both* cmsFLAGS_GAMUTCHECK and cmsFLAGS_SOFTPROOFING.
> Scribus was doing only one or the other, and so nearly every single
> colour is marked as out of gamut. I also changed the gamut alarm colour
> to bright green, since it's hard to tell the difference between the out
> of gamut alarm colour and a grey that is in gamut.
> 
> It's still weird though, since there are CMYK colours that are still
> marked as out of gamut, even though both the input profile and the
> proofing profile are the same - notable C100 M100 Y0 K0 is marked as out
> of gamut. I would have thought that if you specifiy that your colour is
> already in the output colour space, then it would be by definition in
> gamut, no matter what. Any thoughts? I plan to drop a question to the
> little CMS people on this one, as tificc gives the same results.
> 
> 
> happy colouring peoples,
Hi,

i just applied your patch to the 1.3.0cvs sources,
works very well.

A big "Thank you" to you for this patch as you saved
me a lot of work. I just wanted to add CMYK-Tiff support
this weekend.

Best Regards,
Franz Schmid