|
2008-03-13 21:05
|
rgbgreybug.png (27,168 bytes) |
|
2008-03-13 21:05
|
|
|
|
You have not understood what i told you on irc : RGB greys used in vector objects or text are automatically mapped to CMYK K channel as this is usually done by preflight softwares such as Pitstop. For example RGB (50, 50, 50) will be translated to CMYK (0, 0, 0, 50), hence the difference you see. Change the color you defined in scribus to RGB (50, 50, 51) and the color difference between the image and the vector object will disappear. |
|
|
I see your point. I changed the color after you told me on IRC. But I assumed you were talking about the rgb from the image. So as soon as a vector object inside scribus gets an rgb color assigned that has zero saturation the normal color mapping does not apply in the softproof. Nonetheless the PDF exporter behaves as expected (and thus differently from the softproof). So I think it would be a good idea to "fix" that behavior nonetheless. Injecting some tiny amount of color into the grey is a viable workaround but not a real solution. |
|
|
>> Nonetheless the PDF exporter behaves as expected (and thus differently from the softproof). No, you're wrong because softproof simulates cmyk output (remember the option is called "Simulate printer on screen") and you're exporting to rgb. In pdf export dialog, change destination in color tab from "Screen/Web" to "Printer" and you'll see that the behavior is perfectly consistent. When doing so PDF exporter outputs using cmyk colors and not rgb ones. |
|
|
That the printer output is set to screen is a mistake in the test file I made. I was refering to printer output. And in the resulting PDF both rgb colors (from scribus and from the image) are mapped to the same cmyk color as it should be (cause they are the same rgb value using the same profile). But in the softproof they turn out to look different, cause the scribus rgb from the vector element is simply mapped to the k channel (not using the profile maybe?). I would call that different bahvior of the softproof and the exporter. Not? Note: Added an updated test file. |
|
2008-03-15 16:03
|
|
|
|
You misunderstood again. If you use the "Use icc profiles" options in pdf export dialogs, the color will be tagged with RGB profiles and hence will *not* use cmyk color space. Unchecked those options, export and see the result. |
|
|
If you enable the "Use icc profiles" options, you are changing the target color space and consequently the screen softproofing, which use the printer color space, is of course not valid anymore. Remember again, the softproofing option is called "Simulate printer on screen" : if you change any export options so that the destination color space is different from the printer color space, then screen proofing and output will of course differ. |
|
|
I see. I misinterpreted the profiles setting in the pdf export dialog. I thought they where used to translate to CMYK (in a way to override the default settings). So the softproof indeed is compliant with the pdf output. So all that remains is to be careful with pure rgb greys in Scribus vector objects as they circumvent the normal color conversions* and are mapped directly to the k channel. Maybe that could be mentioned somewhere in the docs? Thanks for the detailed explanations. * You said this is standard behavior of other prepress software. I dont know better so ok. |
|
2008-06-24 18:41
|
|
|
|
I'm still seeing inconsistent behaviour with on-screen display and PDF output. Consider the following scenario: - take a RGB 0/0/0 black image, convert it to CMYK with embedded profile using tifficc: tifficc -i sRGB\ Color\ Space\ Profile.icm -o ISOcoated_v2_eci.icc -c2 -e -b -t1 $* "$filename" "${filename/.tif/-ISOcoated.tif}" - create new scribus document, enable color management, all RGB profiles as sRGB, all CMYK profiles as ISOCoated v2, [x] Simulate Printer on Screen [x] Enable Blackpoint compensation, relative colorimetric intent - import both images (RGB and ISOCoated) They look different on screen - the RGB image looks lighter, greyish. Now export the document to PDF 1.3, Printer target, uncheck ICC checkboxes. The resulting PDF will have both images with exactly the same CMYK color: CMYK 87%/79%/64%/93% -> see attached schwarztest.tar.bz2 which also contains the CMYK TIFF of the resulting PDF created using Ghostscript 8.5 My conclusion: Soft proofing should match the final output. If it's the same color in CMYK, it should be the same color on screen, always. IMO, the process RGB-image -> CMYK image -> screen should yield identical results, no matter whether I do the RGB-image -> CMYK conversion externally or implicitly internally. I just figured out it should probably be a separate bug report since it's not related to vector vs. image colors. |
|
|
>> I just figured out it should probably be a separate bug report since it's not related to vector vs. image colors. No |
|
|
>> IMO, the process RGB-image -> CMYK image -> screen should yield identical results, no matter whether I do the RGB-image -> CMYK conversion Unfortunately because of gamut mapping issues that's wrong. Proofing printers colors to screen does not in fact use any RGB => CMYK conversion. This precise case is however a known issue with littlecms 1.16/1.17. To make things look better, disable black point compensation when using the "simulate printer on screen" option. Or revert to littlecms 1.15. |
- Anonymous
