[scribus] Color management conclusions (was: Re: No real CMYK black possible??)

[Tino Schwarze]

Hi Jean,

On Mon, Jun 23, 2008 at 01:58:06PM -0700, Jean Ghali wrote:

> > I observed the following:
> > - black image with ISOCoated profile looks different on screen than
> >   black RGB image, even though they come out the same in CMYK (ISOCoated
> >   image looks a lot blacker on screen). IMO that shouldn't be the case.
> 
> This is perfectly expected and not an issue. The RGB and CMYK ISOCoated
> black points are simply completely different. A RGB monitor profile will
> usually have its black point set at L*0, the CMYK ISOCoated black point is
> around L* 14, which means that RGB black is *way* darker than ISOCoated
> black and explain why they look different on screen. When RGB black is
> converted to ISOCoated, well it just does not fit in the ISOCoated gamut and
> is usually mapped to ISOCoated black point ("black point compensation").
> Which explain why RGB black looks identical to ISOCoated black after
> conversion.

I don't agree. I've got the "simulate printer on screen" checkbox
enabled. Therefore, what will look the same on printer should look the
same on screen, no matter what the source profile is. It should always
get converted source->printer->screen - that's what a soft proof is for,
IMO. Otherwise it is useless.

> > - RGB 0/0/0 black became CMYK 0/0/0/100 black.
> >   -> this does not match the black image, so I cannot combine a black
> >   RGB background with a black RGB image for printing!
> 
> This is in fact the result of a very old design decision (1.2.x or even
> older, not sure tho). It reflects how most preflight softwares used in
> printing houses will handle RGB black and more generally RGB greys (eg: RGB
> 55/55/55) conversions to CMYK. Why so? Because use of RGB greys are in more
> than 99% of the cases a designer error and result in time loss on press and
> sometime hardly printable jobs! Fyi, according to the logs of our workflows,
> those kind of errors affect tens of files *by day* where i work.
> 
> However, i think those mapping from RGB greys to black ink should be handled
> more selectively. In 1.3.6 i plan to give more control to users about how
> conversion from RGB greys to CMYK is done. All i can say now is that direct
> mapping from RGB greys to black ink will be the default at least for text
> objects. 

Alright, thanks for the explanation. 

BTW: Is there (will there be) a color picker in 1.3.[56] which allows me
to pick CMYK from imported images? That would ease things a lot - I'd
just import my RGB image and pick the desired CMYK color from it. Well, 
for the time being, I could use Cinepaint for that.

> > Should I file a bug report on these issues or are they known? 
> 
> There's is already one : #6844
> 
> Hope i was clear enough in my explanations,

Yes, thanks. I'll add a comment to the above bug regarding the softproof
issue, so at least it's documented, no matter what final decision is made
about it.

Thanks,

Tino.

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."

www.craniosacralzentrum.de
www.forteego.de