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

Patrick Noffke patrick.noffke at gmail.com
Tue Dec 20 22:36:53 UTC 2011


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.

Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus/attachments/20111220/4c32379d/attachment.html>


More information about the scribus mailing list