|
2009-04-22 22:08
|
testbw.png (100 bytes) |
|
2009-04-22 22:09
|
|
|
|
I've just found that the problem only occurs when "Output Intended for Printer" is selected when exporting to PDF ... output intended for Screen/Web has no problems. |
|
|
That image is an image indexed with rgb values and rgb grays *do not* translate to black channel only when converted to cmyk hence the values your observe. This is standard behavior for color managed rgb grays. When color management is disabled Scribus use some default rgb => cmyk conversion, which uses icc profiles. |
|
|
They DO translate to black channel only when printing directly from Scribus. They DO translate to black channel only when exporting to PDF intended for Screen/Web. They DO translate to something not black-channel-only but still a reasonable shade of gray when colour management is enabled. This problem is not just that it is not black-channel-only, it is that the image is obviously and clearly not what it is supposed to be. Part of it is a bright cyan! Remember, this is on a document with COLOUR MANAGEMENT DISABLED. RGB grays should translate to black channel only when colour management is disabled. Your comment above says "this is standard behaviour for color managed rgb grays" but the whole point is that these are NOT color managed rgb grays! |
|
|
Current expected behavior is that RGB grays should translate to black channel only for *vectors*. But this is a scribus behavior and not quite standard color management. >> Your comment above says "this is standard behaviour for color managed rgb grays" but the whole point is that these are NOT color managed rgb grays! Wrong. Since scribus 1.3.3.10 and Scribus 1.3.5svn, when color management is disabled scribus uses some default color transforms based on icc profiles (when the default profiles provided by scribus are available). So rgb values are color managed when translated to cmyk. |
|
|
>> They DO translate to black channel only when exporting to PDF intended for Screen/Web No, after having analyzed output file with Acrobat + Pitstop, image use an RGB colorspace... as expected. |
|
|
It is still a serious bug that the output of printing from scribus does not match the output of exporting to pdf from Scribus. Why would you get such a weird colour mismatch when you export to PDF, but not when you print? And why does it only apply to images with the Brightness effect enabled? If there is no brightness effect applied, the PS and PDF outputs match (and they match the screen display). In that case, you get a pure-gray output. But with brightness applied, you get a pure-gray output when you generate a PS file and you get a pure-gray output when you generate a PDF intended for screen/web but you get a very weirdly coloured image when you generate to PDF intended for printer! You point out that the PDF generated for Screen/Web actually uses an RGB image so that explains why that is correct. But the PS output when you print to file and the PDF output from export to PDF both use CMYK images. Regardless of WHICH is the correct and intended behaviour (you're arguing that the PDF output is correct, I'm arguing that the PS output is correct) it is surely not correct that printing directly from Scribus should give you a very different result from exporting to PDF. |
|
|
>> you get a pure-gray output when you generate a PS Yes and given the input rgb image this is a problem. R0 G0 B0 should not translate to C0 M0 Y0 K100 for the quite simple reason that C0 M0 Y0 K100 is not the black point of a cmyk color space. Again we do that for vectors and this is not standard color management at all. >> you get a pure-gray output when you generate a PDF intended for screen/web No, you get an rgb image (3 bytes/pixel), not a gray image (1 bytes/pixel) >> you get a very weirdly coloured image when you generate to PDF intended for printer There are several issues related to image effects and color spaces, but they won't be tackled before 1.3.6. In fact neither ps nor pdf output is quite correct when effects are used. If you want better control over k channel, i strongly advise you to use real gray (no rgb grays) tiffs or PSDs. |
|
|
>> No, you get an rgb image (3 bytes/pixel), not a gray image (1 bytes/pixel) I didn't mean it was a DeviceGray image, I meant it was an RGB image with the property that R=G=B. Which in a non-color-managed space refers to a shade of pure gray (and I believe that is also true in a colour-neutral space such as sRGB, though I could be wrong on that). >> R0 G0 B0 should not translate to C0 M0 Y0 K100 for the quite simple reason >> that C0 M0 Y0 K100 is not the black point of a cmyk color space. Again we do >> that for vectors and this is not standard color management at all. It is wrong for scribus to be considering "black point" or "color management" when the user has explicitly disabled it. When colour management is disabled, RGB->CMYK translation should be done as specified in section 7.2.3 of the PostScript Language Reference manual (3rd edition; don't know offhand the location in the latest editions). According to this standard, R0 G0 B0 should translate to Cx Mx Yx Ky where x=min(1, max(0,1-UCR(1))) and y=min(1,BG(1)). Thus C0 M0 Y0 K1 is a very reasonable expectation (corresponding to simple UCR/BG functions UCR(k)=k and BG(k)=k) but REGARDLESS of the choice of UCR/BG functions this formula leads to R0 G0 B0 ALWAYS translating to a CMYK colour that has the property C=M=Y. And similarly for any other "gray" RGB colour with R=G=B. As it stands right now, with colour management disabled, Scribus follows Adobe's standard calculation for vector RGB objects. It also follows it for all RGB images when printing to a PostScript file. However, it does not follow that standard for RGB images when exporting to PDF. This it the crux of the problem. I think the correct solution is to back out whatever change was made in 1.3.3.10 to use colour management against the user's explicit wishes when generating a Printer-ready PDF from RGB images. No means no -- if the user says "no colour management", it is wrong for Scribus to then use colour management (but in a way where the user has no control over the profiles used) for some things. At the very least, the user should be given some choice, just as when colour management is enabled the user is given choice about whether to use embedded image profiles. The corresponding dialog when colour management is disabled could be something like: Convert RGB images to CMYK using: o Colour management with default profiles o Standard Postscript RGB->CMYK conversion (For more control, activate colour management for the document) If the user selects the first option, both PDF export and print-to-file would behave as PDF export does now. If the user selects the second option, both PDF export and print-to-file would behave as print-to-file does now. >> If you want better control over k channel, i strongly advise you to use real >> gray (no rgb grays) tiffs or PSDs. The images in the actual document (not the artificial ones I made to illustrate this bug report) are full colour, with the Grayscale effect applied. That way we can easily generate a full-colour version of the document by simply removing the grayscale effect. If we manually converted the images to pure gray we would need to maintain two separate documents or reacquire the image source each time. It is similarly unwieldy to use PSDs (or CMYK tiffs) because then when we generate screen/web versions of the document they will have gone through an RGB -> CMYK -> RGB round trip which doesn't 100% preserve the original RGB photograph. It would be much easier for us if Scribus could be fixed to use Adobe's standard formula for RGB->CMYK conversion when colour management is disabled. To say this is "not standard colour management" is beside the point, because this is only in a case in which the user has explicitly requested NOT to use colour management! |
|
|
I have now figured out how to do what we need to do with colour management enabled for the export (turns out when I was originally trying I had "use colour profiles" set for the RGB images when I thought I hadn't! so that's my fault and we have no need to disable colour management for what we need to do). And of course with colour management enabled everything works as expected. So perhaps now there is less of a usage case for having colour management disabled and hence it is less urgent to fix the discrepancy in how Scribus handles PDF export versus print-to-file in the non-colour-managed case. |
|
|
>>When colour management is disabled, RGB->CMYK translation should be done as specified in section 7.2.3 of the PostScript Language Reference manual No modern application behaves like that anymore. It's also clear that disabling color management into Adobe applications does not make them uses those formulas. Imho those formulas should not be taken out the chapter context. The reference for example states (section 7.2, p474) : "Additionnally device color spaces can be remapped into CIE-based color spaces"... in which case those formulas do not apply anymore. The chapter (titled *Rendering*) introduction also seems to imply that those formulas applies to the rendering stage done at device level. >>This it the crux of the problem. I think the correct solution is to back out whatever change was made in 1.3.3.10 to use colour management against the user's explicit wishes when generating a Printer-ready PDF from RGB images. No means no -- if the user says "no colour management", it is wrong for Scribus to then use colour management (but in a way where the user has no control over the profiles used) for some things. It seems that not a single modern application behaves like that anymore, not even Adobe's one. Adobe obviously remap device color space to some default CIE-based color spaces when color management is disabled. >> And of course with colour management enabled everything works as expected. In my testing this is not quite the case and i see things that should be fixed. When exporting an rgb image to cmyk with effects applied to pdf, at least in some case the code does this : load image as rgb > convert to cmyk > apply effects. It should do load image as rgb > apply effects > convert to cmyk. |
|
|
>> In my testing this is not quite the case and i see things that should be fixed. When exporting an rgb image to cmyk with effects applied to pdf, at least in some case the code does this : load image as rgb > convert to cmyk > apply effects. It should do load image as rgb > apply effects > convert to cmyk. I disagree, at least for the greyscale effect, if I'm understanding you correctly. If image 1 is RGB and image 2 is CMYK and both images have the Greyscale effect applied and they are exported to pdf with "Use colour profile" unchecked, then they will currently both be exported as cmyk images with only K nonzero. However, if scribus were to apply the greyscale effect BEFORE converting to cmyk, then image 1 would no longer export the same way as image 2. Should image effects not behave consistently across all image types? |
|
|
>> However, if scribus were to apply the greyscale effect BEFORE converting to cmyk, then image 1 would no longer export the same way as image 2. Well, properly implemented that works perfectly. The prerequisite is that scribus implements at least basic handling of DeviceGray colorspace, currently our internal handling of that kind of color space sucks. Then greyscale effect can be implemented as a real conversion to gray (no more rgb gray). Once that conversion to device gray is done, exporting to pdf is easy : - one can use directly a DeviceGray color space - or use an indexed color space with cmyk values using only k channel - or use a cmyk colorspace with DeviceGray mapping directly to k channel |
|
|
That would be perfect. All the problems we're having to work around would go away in a flash if scribus could internally use a DeviceGray colorspace as you describe. Obviously such a feature would have to wait for a later version of scribus but I'm happy to help test patches (or work on developing some if you can point to some relevant source code files) if needed. |
|
|
Targetting at 1.3.6 as 1.3.6 will see our color management rewritten |
|
|
Image representation in preview mode seems not to bee repaird. Tif-images area yellow colored. This can be viewed in rgb and cmyk separated tif-images. The rendering of jpg-images are looking washy if i have switched on color management. If color management is switched of, jpg-images are looking good. |
|
|
Devs, please advise about this ticket? Does it need to be attached to something ? |
- Anonymous
