Any plans for an active color management?

older
Re: [NTG-context] Lucida small caps

Jan U. Hasecke

17 Feb 2020 17 Feb '20

2:03 p.m.

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

Show replies by date

Hans Hagen

17 Feb 17 Feb

2:39 p.m.

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

Floris van Manen

2:51 p.m.

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

juh

3:10 p.m.

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

Floris van Manen

5:52 p.m.

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

Hans Hagen

6:44 p.m.

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

Henning Hraban Ramm

3:35 p.m.

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 :

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 ___________________________________________________________________________________

Jan U. Hasecke

4:57 p.m.

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

Henning Hraban Ramm

6:36 p.m.

...

Am 2020-02-17 um 17:57 schrieb Jan U. Hasecke :

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

1771

Age (days ago)

1771

Last active (days ago)

List overview

Download

8 comments

5 participants

participants (5)

Floris van Manen
Hans Hagen
Henning Hraban Ramm
Jan U. Hasecke
juh

Any plans for an active color management?

tags

participants (5)