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
