Any plans for an active color management?

Any plans for an active color management?

[Jan U. Hasecke]

Hi all,

I would like to come back to a discussion from 2018 on this list.

After printing some flyers for my cooperative I come to the conclusion
that color management *is* very difficult.

In my eyes, the only way of getting good results seems to be the
following process.

My starting point are RGB colors as we are doing online first.

So if I create a poster or a flyer I have to do this:

1. Decide which print shop will print the material.

2. Download and install the color profile for this print shop in ConTeXt.

3. Specify CMYK values by using transicc with the given profile

4. Define named corporate colors with these CMYK values for typography,
colored background in ConTeXt.

5. Convert all RGB images to CMYK using the given color profile
especially if they contain corporate colors.

Now if we decide to use another print shop, the whole process has to
start again. The result is that I end up with color settings for x
different print shops and cmyk images for x different print shops.

Are there any plans to automate these steps into ConTeXt? That would
enable us to work in RGB the whole time. Only when creating a print pdf
we would specify a color profile and ConTeXt would do the rest by
converting all rgb values to cmyk values due to the given color profile.

As this seems very complex I fear that there are no plans to do this.

What alternatives I have?
=========================

What if deliberately define my own cmyk values once and for all?

Can I work with the same cymk values no matter what profile is used by
the print shop?

TIA
juh
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Any plans for an active color management?

[Hans Hagen]

On 2/17/2020 3:03 PM, Jan U. Hasecke wrote:

> Are there any plans to automate these steps into ConTeXt? That would
> enable us to work in RGB the whole time. Only when creating a print pdf
> we would specify a color profile and ConTeXt would do the rest by
> converting all rgb values to cmyk values due to the given color profile.

that would mean plugging some color transfer function into the rgb -> 
cmyk conversion that is already there (but i never had to deal with 
color transfer functions)

> As this seems very complex I fear that there are no plans to do this.
not unless i know exactly what to do (or am forced to use it myself)

can't you use spotcolors? these are kind of standardized (say pantone)

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Any plans for an active color management?

[Floris van Manen]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]



On 17-02-2020 15:39, Hans Hagen wrote:
> On 2/17/2020 3:03 PM, Jan U. Hasecke wrote:
> 
>> Are there any plans to automate these steps into ConTeXt? That would
>> enable us to work in RGB the whole time. Only when creating a print pdf
>> we would specify a color profile and ConTeXt would do the rest by
>> converting all rgb values to cmyk values due to the given color profile.
> 
> that would mean plugging some color transfer function into the rgb ->
> cmyk conversion that is already there (but i never had to deal with
> color transfer functions)
> 
>> As this seems very complex I fear that there are no plans to do this.
> not unless i know exactly what to do (or am forced to use it myself)
> 
> can't you use spotcolors? these are kind of standardized (say pantone)

As in print the default is CMYK, why not start there.
The online might be RGB but all pdf viewers know how to deal with the
convertion from CMYK to RGB by themselves.

.F



[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 2456 bytes --]

[-- Attachment #3: Type: text/plain, Size: 493 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Any plans for an active color management?

[juh]

Floris van Manen writes:

> On 17-02-2020 15:39, Hans Hagen wrote:
>> On 2/17/2020 3:03 PM, Jan U. Hasecke wrote:
>> 
>>> Are there any plans to automate these steps into ConTeXt? That would
>>> enable us to work in RGB the whole time. Only when creating a print pdf
>>> we would specify a color profile and ConTeXt would do the rest by
>>> converting all rgb values to cmyk values due to the given color profile.
>> 
>> that would mean plugging some color transfer function into the rgb ->
>> cmyk conversion that is already there (but i never had to deal with
>> color transfer functions)
>> 
>>> As this seems very complex I fear that there are no plans to do this.
>> not unless i know exactly what to do (or am forced to use it myself)
>> 
>> can't you use spotcolors? these are kind of standardized (say pantone)
>
> As in print the default is CMYK, why not start there.
> The online might be RGB but all pdf viewers know how to deal with the
> convertion from CMYK to RGB by themselves.

At least, digital images are always RGB.

In my special case we started with a RGB corporate design as we are an
online cooperative. Print comes later.

(Strange I can't see the answer of Hans.)

Mit freundlichen Grüßen
Jan Ulrich Hasecke

-- 
Soziale Plastik. Die Kunst der Allmende
Essay zum 30. Todestag von Joseph Beuys
http://www.amazon.de/dp/1523458763/
Taschenbuch, 130 Seiten, EUR 9,90
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Any plans for an active color management?

[Floris van Manen]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]



On 17-02-2020 16:10, juh wrote:
> At least, digital images are always RGB.
> 
> In my special case we started with a RGB corporate design as we are an
> online cooperative. Print comes later.

The thing is that in print the CMYK will result in a fixed well defined
object: a physical  print on paper. That is then the reference.
The complete chain of getting the information into print is well defined.

Compare that to the world of digital monitor viewing.
None is well defined, every monitor and platform has its own unknown
settings. How would you translate those into a printed document?

So my point was that it might be more convenient to first create the
publication for print, then let individual pdf browsers do their trick
in their own environment rendering the CMYK into RGB or whatever...

Unless it is fun to do both of course...

.F

[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 2456 bytes --]

[-- Attachment #3: Type: text/plain, Size: 493 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Any plans for an active color management?

[Hans Hagen]

On 2/17/2020 6:52 PM, Floris van Manen wrote:
> 
> 
> On 17-02-2020 16:10, juh wrote:
>> At least, digital images are always RGB.
>>
>> In my special case we started with a RGB corporate design as we are an
>> online cooperative. Print comes later.
> 
> The thing is that in print the CMYK will result in a fixed well defined
> object: a physical  print on paper. That is then the reference.
> The complete chain of getting the information into print is well defined.
> 
> Compare that to the world of digital monitor viewing.
> None is well defined, every monitor and platform has its own unknown
> settings. How would you translate those into a printed document?
> 
> So my point was that it might be more convenient to first create the
> publication for print, then let individual pdf browsers do their trick
> in their own environment rendering the CMYK into RGB or whatever...
indeed, start with cmyk when doing print

and given differences in displays one can then just be more tolerant in 
how it shows up on screen, as it's unpredictable anyway

Hans



-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Any plans for an active color management?

[Henning Hraban Ramm]

Hi juh,

it doesn’t make sense to use device profiles of any printshop, since all the printshops in most of Europe are supposed to standardize on Euroscale CMYK (ISO Coated FOGRA##) while in the USA they use SWOP CMYK and in Japan their own standard. So you can stay with the same profiles as long as you stay on the continent.

The main difference in CMYK profiles is in relation to the general kind of paper: coated or uncoated or maybe newspaper / web offset.
(Web offset = Rollenoffset, no relation to the www / Coated = gestrichen, Bilderdruck / Uncoated = ungestrichen, Werkdruck/Naturpapier)

The difference between FOGRA27 and 39 is marginal, AFAIK. Use the latter.

If you use properly profiled RGB images, the printshop’s workflow software should convert them properly and consistently.

Conversion of CMYK colors (e.g. Euroscale to SWOP) is a serious problem, though. AFAIK the separation method (UCR/GCR) is not part of any standard.
Often I want some device dependent CMYK tone (like deep black: 30/0/0/100); if you convert that via L*a*b (even back to the same profile) you might get a 4c tone that’s harder to print and might look less clean, even if the measurable hue is the same.

That means you should keep your photos in (profiled) RGB. Probably best use sRGB to stay device independend, because that’s default for monitors, even if printshops like Adobe RGB or one of the profiles that shrink the RGB color space to printable colors.

For type and logos I still rely on (device dependend) CMYK colors and my experience how they’ll come out in Euroscale printing.
For an international project that should print the same e.g. in the US, in Europe and in Japan, I’d use differently defined graphics or Pantone spot colors. (I guess Pantone is the one spot color system that will work world-wide, even if HKS is still usual in Germany and Toyo in Japan.)
It could also work to use spot colors and have the printshop convert them to “their” CMYK profile.

Colors that you define in TeX or Metapost are a different problem. I *think* they should use the output intent as their profile. But I don’t know if the intent option of \setupcolors and/or \setupbackend really works this way. (My only means to check was Acrobat Pro 9, and that won’t run on a current macOS any more.)

Hope that helps a bit and doesn’t confuse you more…

Color management *is* hard.

Best, Hraban

> Am 2020-02-17 um 15:03 schrieb Jan U. Hasecke <juh+ntg-context@mailbox.org>:
> 
> Hi all,
> 
> I would like to come back to a discussion from 2018 on this list.
> 
> After printing some flyers for my cooperative I come to the conclusion
> that color management *is* very difficult.
> 
> In my eyes, the only way of getting good results seems to be the
> following process.
> 
> My starting point are RGB colors as we are doing online first.
> 
> So if I create a poster or a flyer I have to do this:
> 
> 1. Decide which print shop will print the material.
> 
> 2. Download and install the color profile for this print shop in ConTeXt.
> 
> 3. Specify CMYK values by using transicc with the given profile
> 
> 4. Define named corporate colors with these CMYK values for typography,
> colored background in ConTeXt.
> 
> 5. Convert all RGB images to CMYK using the given color profile
> especially if they contain corporate colors.
> 
> Now if we decide to use another print shop, the whole process has to
> start again. The result is that I end up with color settings for x
> different print shops and cmyk images for x different print shops.
> 
> Are there any plans to automate these steps into ConTeXt? That would
> enable us to work in RGB the whole time. Only when creating a print pdf
> we would specify a color profile and ConTeXt would do the rest by
> converting all rgb values to cmyk values due to the given color profile.
> 
> As this seems very complex I fear that there are no plans to do this.
> 
> What alternatives I have?
> =========================
> 
> What if deliberately define my own cmyk values once and for all?
> 
> Can I work with the same cymk values no matter what profile is used by
> the print shop?
> 
> TIA
> juh
> ___________________________________________________________________________________
> If your question is of interest to others as well, please add an entry to the Wiki!
> 
> maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
> archive  : https://bitbucket.org/phg/context-mirror/commits/
> wiki     : http://contextgarden.net
> ___________________________________________________________________________________

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Any plans for an active color management?

[Jan U. Hasecke]

Hi Henning Hraban,

I contacted three print shops and they demand three different color
profiles, one of them prints on "100 % recycling paper" with an uncoated
profile. The other two use ISO Coated v2 300% and Coated Fogra 39.

Being online shops I think they will complain if not the right profile
is provided. But anyway.

I will summarize:

Am 17.02.20 um 16:35 schrieb Henning Hraban Ramm:

> That means you should keep your photos in (profiled) RGB. Probably
> best use sRGB to stay device independend, because that’s default for
> monitors, even if printshops like Adobe RGB or one of the profiles
> that shrink the RGB color space to printable colors.

1. All my images should be profiled. I think I can do this in Gimp.

> For type and logos I still rely on (device dependend) CMYK colors and
> my experience how they’ll come out in Euroscale printing. 

Device depended means what?

I did this to convert our RGB corporate colors to device depended CMYK:

transicc -i sRGB.icc -o Fogra/Iso-whatever.icc

But what shall I do with the logo? It is a RGB SVG.

Do I understand you correctly that the best would be to ask someone with
Indesign to convert it to CMYK with the above cited profile chain?

Or shall I tell the designer: These are the values I need as CMYK, just
do it.

> Colors that you define in TeX or Metapost are a different problem. I
> *think* they should use the output intent as their profile. But I
> don’t know if the intent option of \setupcolors and/or \setupbackend
> really works this way. (My only means to check was Acrobat Pro 9, and
> that won’t run on a current macOS any more.)

I do it like this:

\startmode[fogra39]
\definecolor  [hs-logoblau]   [c=1.000, m=0.735, y=0.279, k=0.160]
\definecolor  [hs-dunkelblau] [c=0.844, m=0.544, y=0.070, k=0.000]
\definecolor  [hs-hellblau]   [c=0.468, m=0.220, y=0.086, k=0.002]
\definecolor  [hs-orange]     [c=0.127, m=0.832, y=1.000, k=0.042]

\setupcolors[cmyk=yes,rgb=no,]

\setupbackend[
   format=PDF/X-3:2003,
   intent={Coated FOGRA39 (ISO 12647-2:2004)},
   ]
\stopmode


I like your thought that all profiles are more or less the same. That
would mean that my designer could convert our SVG logo and our SVG icons
to Device-profiled CMYK-PDF and I am good.
 Thanks for your help.
juh
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Any plans for an active color management?

[Henning Hraban Ramm]

> Am 2020-02-17 um 17:57 schrieb Jan U. Hasecke <juh+ntg-context@mailbox.org>:
> 
> I contacted three print shops and they demand three different color
> profiles, one of them prints on "100 % recycling paper" with an uncoated
> profile. The other two use ISO Coated v2 300% and Coated Fogra 39.

Oh my, the sick state of my industry…
But ISO Coated and Coated FOGRA are quite similar.

> Being online shops I think they will complain if not the right profile
> is provided. But anyway.

They probably won’t recognize if you use any or no profile...

> 1. All my images should be profiled. I think I can do this in Gimp.

✔︎

>> For type and logos I still rely on (device dependend) CMYK colors and
>> my experience how they’ll come out in Euroscale printing. 
> Device depended means what?

Not profiled.

I.e. the actual resulting color depends on the device, if it’s only defined as RGB or CMYK values, those don’t define a location in L*a*b color space without a profile.

> I did this to convert our RGB corporate colors to device depended CMYK:
> 
> transicc -i sRGB.icc -o Fogra/Iso-whatever.icc

Never used lcms, sorry. Always wanted to try...

> But what shall I do with the logo? It is a RGB SVG.

AFAIK SVG uses sRGB per definitionem.
But I don’t know what happens on conversion.

I just checked:
You can set an output intent color profile in Inkscape’s document settings, and the reference ends up in the SVG (with an absolute path).
If I define colors in CMYK, they get safed only as (HTML-style) RGB colors, but if I re-open the file, CMYK color values are still the same. Don’t know how Inkscape does it.
The exported PDF (using cairo) is not profiled (DeviceRGB color space).

(Around 2004 there was a discussion about CMYK or profile based colors in SVG. I used the preliminary standard for color definitions in SVGs that were meant for exchange between a Flash based online ad designer and our EPS based newspaper workflow. I was in the position to force the programmers of that horrible Flash app to export something adhering to open standards… <evil grin> But then the SVG-color stuff got delayed and finally declined. I think there are profile based colors possible now, but Inkscape as one of the main SVG players doesn’t support them…)

> Do I understand you correctly that the best would be to ask someone with
> Indesign to convert it to CMYK with the above cited profile chain?

Mmm, no. Acrobat Pro can do proper profile conversions of graphics. Don’t know another tool.

> Or shall I tell the designer: These are the values I need as CMYK, just
> do it.

Exactly ;) Unfortunately they can’t really do that with Inkscape.

>> Colors that you define in TeX or Metapost are a different problem. I
>> *think* they should use the output intent as their profile. But I
>> don’t know if the intent option of \setupcolors and/or \setupbackend
>> really works this way. (My only means to check was Acrobat Pro 9, and
>> that won’t run on a current macOS any more.)
> 
> I do it like this:
> 
> \startmode[fogra39]
> \definecolor  [hs-logoblau]   [c=1.000, m=0.735, y=0.279, k=0.160]
> \definecolor  [hs-dunkelblau] [c=0.844, m=0.544, y=0.070, k=0.000]
> \definecolor  [hs-hellblau]   [c=0.468, m=0.220, y=0.086, k=0.002]
> \definecolor  [hs-orange]     [c=0.127, m=0.832, y=1.000, k=0.042]
> 
> \setupcolors[cmyk=yes,rgb=no,]

Try to set the same intent profile in \setupcolors. (It’s older than \setupbackend, and I actually don’t know what it does.)

> \setupbackend[
>   format=PDF/X-3:2003,
>   intent={Coated FOGRA39 (ISO 12647-2:2004)},
>   ]
> \stopmode

BTW: ConTeXt enforces some properties of the PDF/X standards, e.g. you don’t get transparencies with PDF/X-3. While InDesign would fake such effects (generating bitmaps), you just get plain colors with ConTeXt. That took me by surprise. *This* you can avoid with PDF/X-4, but I don’t know if that might cause different problems (e.g. printshop workflows that can’t handle it).

> I like your thought that all profiles are more or less the same.

No, that’s a misunderstanding. The several ISO/FOGRA Coated profiles *are* very close, as well as their Uncoated counterparts, but these groups are distinct.
If you let print on recyling/offset/copy paper, you need an Uncoated profile; if they use coated/silk/image… paper, you need an Coated profile. There are also different sets of spot colors for coated/uncoated paper.

> That would mean that my designer could convert our SVG logo and our SVG icons
> to Device-profiled CMYK-PDF and I am good.

Not device profiled, but device dependend, that means unprofiled. I’d expect unprofiled colors to use the default color space, and that would probably the right thing.

> Thanks for your help.

You’re welcome.

Best, Hraban


___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________