View Issue Details

IDProjectCategoryView StatusLast Update
0006844ScribusGraphics / Image Framespublic2008-06-24 22:22
ReporterplinnellAssigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version1.3.3.12svn 
Summary0006844: Differing Display of RGB grey 50% in vector and bitmap object
DescriptionSee the difference in the output from PDF which is equal and the on screen display with the attached file.
TagsNo tags attached.
Patch

Activities

2008-03-13 21:05

 

rgbgreybug.png (27,168 bytes)   
rgbgreybug.png (27,168 bytes)   

2008-03-13 21:05

 

scribus_match.tar.gz (38,040 bytes)

jghali

2008-03-13 22:13

administrator   ~0019171

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.

roberte

2008-03-14 23:56

reporter   ~0019191

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.

jghali

2008-03-15 13:41

administrator   ~0019195

Last edited: 2008-03-15 13:45

>> 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.

roberte

2008-03-15 15:50

reporter   ~0019196

Last edited: 2008-03-15 16:05

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

 

jghali

2008-03-15 16:17

administrator   ~0019197

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.

jghali

2008-03-15 16:27

administrator   ~0019198

Last edited: 2008-03-15 16:32

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.

roberte

2008-03-15 16:38

reporter   ~0019199

Last edited: 2008-03-15 16:46

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

 

schwarztest.tar.bz2 (58,775 bytes)

Tino Schwarze

2008-06-24 18:43

reporter   ~0019880

Last edited: 2008-06-24 18:44

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.

jghali

2008-06-24 19:34

administrator   ~0019881

>> I just figured out it should probably be a separate bug report since it's not related to vector vs. image colors.

No

jghali

2008-06-24 22:22

administrator   ~0019882

>> 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.

Issue History

Date Modified Username Field Change
2008-03-13 21:05 plinnell New Issue
2008-03-13 21:05 plinnell File Added: rgbgreybug.png
2008-03-13 21:05 plinnell Reported where => IRC
2008-03-13 21:05 plinnell File Added: scribus_match.tar.gz
2008-03-13 22:13 jghali Note Added: 0019171
2008-03-14 23:56 roberte Note Added: 0019191
2008-03-15 13:41 jghali Note Added: 0019195
2008-03-15 13:42 jghali Note Edited: 0019195
2008-03-15 13:42 jghali Note Edited: 0019195
2008-03-15 13:45 jghali Note Edited: 0019195
2008-03-15 15:50 roberte Note Added: 0019196
2008-03-15 15:57 roberte Note Edited: 0019196
2008-03-15 15:58 roberte Note Edited: 0019196
2008-03-15 16:03 roberte File Added: scribus_match_updated.tar.bz2
2008-03-15 16:05 roberte Note Edited: 0019196
2008-03-15 16:17 jghali Note Added: 0019197
2008-03-15 16:27 jghali Note Added: 0019198
2008-03-15 16:32 jghali Note Edited: 0019198
2008-03-15 16:32 jghali Note Edited: 0019198
2008-03-15 16:38 roberte Note Added: 0019199
2008-03-15 16:46 roberte Note Edited: 0019199
2008-06-24 18:41 Tino Schwarze File Added: schwarztest.tar.bz2
2008-06-24 18:43 Tino Schwarze Note Added: 0019880
2008-06-24 18:44 Tino Schwarze Note Edited: 0019880
2008-06-24 19:34 jghali Note Added: 0019881
2008-06-24 22:22 jghali Note Added: 0019882
2015-09-17 20:10 Kunda Category Graphics / Image Frames => Graphics/Img Frames
2015-09-17 20:11 Kunda Category Graphics/Img Frames => Graphics / Image Frames