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
