[Scribus] [announce] CMYK Patch gets image support

[David Purton]

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,


cheers

dc


-- 
David Purton
dcpurton at chariot.net.au
 
For the eyes of the LORD range throughout the earth to
strengthen those whose hearts are fully committed to him.
                                 2 Chronicles 16:9a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: Digital signature
Url : http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20050210/df61286f/attachment.pgp