One CMYK-profile to rule them all?

[Stephen Marsh]

Although this is not about PDF-X standards, it is similar to saying that PDF/X-4 is dead, long live PDF/X-1 :]



Stephen Marsh

 

[Magnus]

Although this is not about PDF-X standards, it is similar to saying that PDF/X-4 is dead, long live PDF/X-1 :]

Stephen Marsh

No I disagree, no body said you need to convert your your data to eciCMYK. Instead use PDF/X-4 and always set eciCMYK as Output Intent.

The Rip will then convert from Output Intent (eciCMYK or tagged RGB) to your destination profile.

The advantage would be that the creative Indesign user wouldn't need to care about the other 23 different standard cmyk profiles. The same way many work today with Fogra39 but secured for any output. This way you can get full advantage of a new digital printer with a larger gamut then Fogra39.

 

[Stephen Marsh]

No I disagree, no body said you need to convert your your data to eciCMYK. Instead use PDF/X-4 and always set eciCMYK as Output Intent.

I obviously read the ECI press release differently then.

The Rip will then convert from Output Intent (eciCMYK or tagged RGB) to your destination profile.

Presuming that the RIP is configured this way, many RIPs are setup to ignore the OI and to assume a given input condition such as F39.

The advantage would be that the creative Indesign user wouldn’t need to care about the other 23 different standard cmyk profiles. The same way many work today with Fogra39 but secured for any output. This way you can get full advantage of a new digital printer with a larger gamut then Fogra39.

I am not yet drinking the cool-aid. :]



Stephen Marsh

 

[Magnus]

I obviously read the ECI press release differently then.

Yes we did. I don't see anything stated like "Convert all your data to eciCMYK before you proceed to the next step". But the release of dedicated DeviceLink Profiles indeed makes you wonder a bit..

http://www.eci.org/en/colourstandards/workingcolorspaces

I am not yet drinking the cool-aid. :]

Stephen Marsh

But you doesn't totally disagree, do you?

This is the way we are handling RGB today, why wouldn't it be possible to do the same with CMYK?

Best regards,

Magnus

 

[Danny Whitehead]

I also don't see any benefits over RGB, and it has the same drawback of designers working in out-of-gamut colours. In fact, if I read correctly, they even suggest signing off on proofs that will likely contain colours that are out-of-gamut of the final output. Not 255 Blue out-of-gamut, but still. Wouldn't a narrower 'standard' RGB profile achieve pretty much the same?

 

[abc]

I find this a very interesting topic, but it assumes that the Print Service Provider understands and has the means to perform a Devicelink conversion.
Also I remember from conversations at the Ghent Workgroup that it's not advisable to perform Devicelink conversions on pages with live transparency as it can lead to undesireable results.

I didn't look at all the documentation regarding the supplied Devicelinks yet, but I wonder if they provide any workflow guidance.

 

[arossetti]

Why can't we make LAB the default design colorspace instead of trying to force a CMYK or RGB?

 

[Puch]

This is the way we are handling RGB today, why wouldn't it be possible to do the same with CMYK?
Magnus

Magnus, just because you have a deep understanding of colormanagement, color spaces and conversion between them doesn't mean that any other person down (up?) the line will have the same knowledge. Eg. designers know that RGB will change when printed, but they assume that CMYK data stays the same (=treated as DeviceCMYK). The new system – when implemented – will change that, which will cause innumerable annoyances ("my 100 percent Y got contaminated").

And no, you can't magically stretch the color defined in a smaller color space into a new, wide-gamut color space on your brand new digital device. Not without causing differences, which might get approval or rejection from the client. To make this work, you have to acquire the data in PDF/X-4 (or PDF/X-6, if we want to be sooooo advanced boys).

On another note: "it assumes that the Print Service Provider understands and has the means to perform a Devicelink conversion". DeviceLink conversion on a service provider level is a must today. No way to escape that.

The real culprit here is what Danny Whitehead raised: so the client should sign off material in a totally different color space (and media) as the intended output. This is very far from the current practice when we use two proofers just to provide Coated and Uncoated proofs to mimic the surface characteristics of the final product. I don't believe clients used to get to this system will approve a newspaper ad proofed on a 'general-use' material in a 'general-use' color space.

 

[Magnus]

Why can't we make LAB the default design colorspace instead of trying to force a CMYK or RGB?

Interesting thought, but we still need CMYK to make 100% k text and grayscale drop shadows..

 

[Magnus]

Magnus, just because you have a deep understanding of colormanagement, color spaces and conversion between them doesn't mean that any other person down (up?) the line will have the same knowledge. Eg. designers know that RGB will change when printed, but they assume that CMYK data stays the same (=treated as DeviceCMYK). The new system – when implemented – will change that, which will cause innumerable annoyances ("my 100 percent Y got contaminated").

Of course you would have to setup the RIP in a such way that solids stays solids and a C100 M040 Y000 K000 only contain Cyan and Magenta after the conversion, eg C100 M032 Y000 K000 (Same as basic DeviceLink rules).

And no, you can't magically stretch the color defined in a smaller color space into a new, wide-gamut color space on your brand new digital device. Not without causing differences, which might get approval or rejection from the client. To make this work, you have to acquire the data in PDF/X-4 (or PDF/X-6, if we want to be sooooo advanced boys).

Yes, this would need to acquire PDF/X-4 or newer.

On another note: "it assumes that the Print Service Provider understands and has the means to perform a Devicelink conversion". DeviceLink conversion on a service provider level is a must today. No way to escape that.

Agreed.

The real culprit here is what Danny Whitehead raised: so the client should sign off material in a totally different color space (and media) as the intended output. This is very far from the current practice when we use two proofers just to provide Coated and Uncoated proofs to mimic the surface characteristics of the final product. I don't believe clients used to get to this system will approve a newspaper ad proofed on a 'general-use' material in a 'general-use' color space.

True, it could be an issue. But the service provider should (if working with this hypotetical workflow) be able to provide the client with a proof that simulates the final printing method and substrate (eg. ISOnewspaper) when asked for.

For this workflow to work we would also need a way to communicating the diviation between the woking CMYK colorspace (Fogra53) and the final output colorspace.

For instance like this:

Original color space: eciCMYK (Fogra53)
Target color space: ISOCoated_v2_ECI (Fogra39)
Expected color gamut: 72%
Expected contrast: 65%
Maximum color difference: 16 ∆E00
Differens of whitepoint: 3 ∆E00

 

[cementary]

Why can't we make LAB the default design colorspace instead of trying to force a CMYK or RGB?

LOL That's definitely not enough — i, personally, would've vote for XYZ as working space

 

[Deleted member 16349]

LOL That's definitely not enough — i, personally, would've vote for XYZ as working space

Me too. It is scalable. Scalability is very important when trying to make screened images that will retain colour. IMO

 

[Magnus]

Me too. It is scalable. Scalability is very important when trying to make screened images that will retain colour. IMO

Yeah, go to sarcasm. We really need more sarcasm and bitterness in this industry, then it will bloom again.

 

[cementary]

Yeah, go to sarcasm. We really need more sarcasm and bitterness in this industry, then it will bloom again.

That's what industry really needs. We need it to resist lot's of bullshit - like concentric screening, xm-developments, ecological yammering and ecicmyk for sure.
btw, ecirgb (v1 or v2, doesn't matter) has been around for several years. Did you find that useful?

 

[gordo]

That's what industry really needs. We need it to resist lot's of bullshit - like concentric screening, xm-developments, ecological yammering and ecicmyk for sure.
btw, ecirgb (v1 or v2, doesn't matter) has been around for several years. Did you find that useful?

The great thing about standards is that there are so many of them. On the other hand, the bad thing about standards is that there are so many of them

 

[Magnus]

That's what industry really needs. We need it to resist lot's of bullshit - like concentric screening, xm-developments, ecological yammering and ecicmyk for sure.
btw, ecirgb (v1 or v2, doesn't matter) has been around for several years. Did you find that useful?

If you read my first post in this thread you will see that I mentioned eciRGB (as not so successful). Please take the time to read through the posts before start bashing. I started this post to discuss the pros and cons of eciCMYK, and the workflow it would acquire.

You might wanna contribute with some of your ideas and knowledge regarding why it wouldn't work on a more technical level?

 

[cementary]

If you read my first post in this thread you will see that I mentioned eciRGB (as not so successful). Please take the time to read through the posts before start bashing. I started this post to discuss the pros and cons of eciCMYK, and the workflow it would acquire.

You might wanna contribute with some of your ideas and knowledge regarding why it wouldn't work on a more technical level?

I didn't say it wouldn't work. What i'm trying to say -
there's no need for one. I personally believe that if you work or design looking into RGB display - you should do your work in RGB. Ecicmyk is an unnecessary step. There are enough color transformations as it is and one shouldn't vote for one more.

Implementing of eciCMYK would create at least three points where error can occur. At the designer level first. At the proof level second. And at the printer's level third. I think it's too much.

In Russia you've hardly can find a printer with pdfx4 workflow, devicelinks for every situation and educated enough customers who know how relative RI differs from perceptual. In fact most of workflows are setup for pdf without any oi or embedded ICC profiles. So for my experience ecicmyk will make things even more cloudy than they are today. Customers and most printers don't know anything about color management. I dunno maybe in your country things are different.

But, even with well educated customers, pdfx4 workflow and printers who understands devicelinks ecicmyk is still an unnecessary step where errors can stand up and lot's of misunderstanding occur.

 

[Deleted member 16349]

Yeah, go to sarcasm. We really need more sarcasm and bitterness in this industry, then it will bloom again.

Sorry Magnus, but I was not being sarcastic at all. I am very serious about thinking XYZ is a better metric. I can not say how cementary actually views this but I do have an opinion on it that I have had it for quite some time.

 

[Deleted member 16349]

Why can't we make LAB the default design colorspace instead of trying to force a CMYK or RGB?

Here is a link to a Wiki entry for Dan Margulis. He has taught courses and written books on colour management and covers using Lab as a way to work to edit and correct images. This might be of interest to you.

https://en.wikipedia.org/wiki/Dan_Margulis

 

[arossetti]

Here is a link to a Wiki entry for Dan Margulis. He has taught courses and written books on colour management and covers using Lab as a way to work to edit and correct images. This might be of interest to you.

https://en.wikipedia.org/wiki/Dan_Margulis

I must admit living outside of the pre-press/pre-media room makes me less aware of all the difficulties of editing/color correcting a file before it hits the printer. My thoughts on LAB as standard colorspace comes from the thought that if the majority of ICC profiles are using LAB as the connection space it would eliminate a conversion.

I'm assuming Margulis using LAB over XYZ was just a limitation of the software?
What are your thoughts on why XYZ would be a better design space than LAB?