[scribus] RGB to CMYK not using ICC profile for R=G=B colors

[Patrick Noffke]

On Tue, Dec 20, 2011 at 4:36 PM, Patrick Noffke <patrick.noffke at gmail.com>wrote:

>
>
> On Tue, Dec 20, 2011 at 2:51 PM, Patrick Noffke <patrick.noffke at gmail.com>wrote:
>
>>
>>
>> On Tue, Dec 20, 2011 at 1:07 PM, Jean Ghali <jghali at libertysurf.fr>wrote:
>>
>>>
>>> ----- "Patrick Noffke" <patrick.noffke at gmail.com> a écrit :
>>> >
>>> > I expect all colors to use the profile to convert to CMYK, but for
>>> > RGB
>>> > colors when R=G=B, it is only using black.  I don't think this is the
>>> > correct behavior.
>>>
>>> The behavior here is explained by quality considerations. When using
>>> vector objects with r=g=b, icc conversions does not work well when document
>>> is targetted to be printed on a press (digital or not). In those case, icc
>>> base cmyk conversion will usually produce a separation using all 4 cmyk
>>> channels and this is the problem :
>>> - such color has very bad colorimetric stability on press : unless the
>>> color is very dark, any shift on a single color will trigger the gray to be
>>> shifted. As the shift depends on the ink percentage, the result will also
>>> be a poor gray balances.
>>> - using all 4 cmyk colors for grays on text and lines will deteriorate
>>> output quality by making text and lines look more 'fat' than they should
>>> be. Any ink registration problem will make the problem even worse.
>>> - such a document will need better ink registration and cause higher
>>> make-ready times if printed on traditional press, those higher make-ready
>>> times will however not really improve printed quality in this case
>>> - higher make-ready times will cause higher production costs
>>>
>>> Conclusion : in most case, traditional icc conversion is to be avoided
>>> for gray color with r=g=b. Scribus behavior has been implemented in view of
>>> those practical considerations. Preflight tools such as Pitstop implements
>>> similar handling of rgb grays btw.
>>>
>>>
>> Thank you for the explanation.  That all makes sense, but it seems like a
>> band-aid to account for some users' ignorance.  The correct way to fix
>> those problems is to use a CMYK color (with only black set to non-zero).
>>  But for those same users that want to create RGB colors that are near gray
>> and very similar to each other, they will not get the colors they expect
>> when they go to press, and they likely will not understand why.
>>
>> Can you please tell me how RGB images are treated, when a printer ICC
>> profile is assigned to the output intent, and an RGB ICC profile is
>> assigned to the RGB images?  Does Scribus do the color conversion when
>> creating a PDF/X-3 document, and store the images as CMYK, or store the
>> (RGB) profile in the PDF and associate it with the RGB images?  If the
>> latter, then it is up to the printer to do the CMYK separations, and
>> hopefully they do them correctly.
>>
>>
> A colleague of mine has Illustrator, InDesign, Photoshop, and Acrobat.  We
> did the same experiment in Illustrator and InDesign.  We created an RGB
> rectangle with R=G=B=128, and another rectangle with R=128, G=129, B=128.
>  If we had the CMYK ICC profile assigned for the output intent when we
> exported to PDF/X-3, it converted both rectangles to 4-color CMYK values
> (approximately C = 0.25, M = 0.19, Y = 0.19, K = 0.45 -- this was the
> profile I created with a lot of GCR).
>
> One thing that tripped us up was that, in Illustrator, if we had the image
> mode set to CMYK, then once we created a rectangle, the color was instantly
> converted to CMYK using the currently assigned profile -- even if we used
> the RGB color tool for that element to set it to (128, 128, 128).  Then
> when we changed the profile, the CMYK values weren't changing, which was
> what tripped us up.  The image had to be in RGB mode, if we wanted to
> change the output profile prior to exporting to PDF/X-3.
>
>
Another reason why I think this is incorrect behavior is with respect to
gradients.  If you create a rectangle with Black R=G=B=0 on the ends, and a
dark red (for example), with R=75, G= 45, B=45 in the middle, then when you
make the PDF, the black ends will get K only, and the middle will have
4-color, with the CMYK coverage depending on the output intent (for the
SWOPcoated5_240 TAC profile, the middle red CMYK is (40%, 70%, 36%, 76%)).
 If you want to print this on a high-quality device, which is capable of
handling high TAC levels, the black ends will be too light from what the
author intends.  Or to put it another way, if you work with RGB colors, to
get a nice saturated black on a high quality device, you have to create a
color like R=0, G=1, B=0.

What do others think?  I'm happy to file a bug report (with a patch), if
you think it makes sense to change the behavior.

Thanks,
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus/attachments/20111222/67631c34/attachment.html>