EskoArtworks, Equinox?

[gordo]

Too bad the design was incomplete. Ask any Brand Owner and they'll say the same thing, "Nice spot color matches, but why don't my images 'POP' as well?" Because CMYK images must 'conform to the appropriate ISO specification.' Yeah right...

Brad.

You seem to have difficulty understanding my posts. Perhaps I'm not being clear?

If you want the images to "pop" as you put it, then use the extra process colors to do so by making use of an appropriate ICC profile to do the separations.

In Kodak's case you use Spotless to handle the screen tint builds to simulate spot colors and an ICC profile to handle the RGB to CMYK++

If you want the images to look normal or confirm to an ISO spec then use a conventional CMYK separation either using an ICC profile in the workflow to go RGB to CMYK or by preseparating the images in PShop.

I have spoken with many national and international brand owners and I can assure you that they would never say "Nice spot color matches, but why don't my images 'POP' as well?" If they know what they're doing then they would use the appropriate methodology according to the needs of the project at hand.

Gordo

 

[Bradleyp]

In Kodak's case you use Spotless to handle the screen tint builds to simulate spot colors and an ICC profile to handle the RGB to CMYK++

What if the customers images are already in CMYK? (not RGB), how does an ICC profile produce CMYK++?

Brad.

 

[gordo]

What if the customers images are already in CMYK? (not RGB), how does an ICC profile produce CMYK++?

Brad.

If the image is already in CMYK then its gamut has already been truncated - an ICC profile can't add to what isn't there in the first place. If your source images are CMYK then your best option is a manual CMYK++ separation. I.e. you build the extra channels manually yourself.

gordo

 

[Bradleyp]

If the image is already in CMYK then its gamut has already been truncated - an ICC profile can't add to what isn't there in the first place.

All these years, I've been lead to believe ICC profiles could do anything. Now you've shattered me. Luckily the world will end in an hour. Finally put us all out of our expanded gamut misery - LOL

Brad.

 

[Bradleyp]

If the image is already in CMYK then its gamut has already been truncated - an ICC profile can't add to what isn't there in the first place.

Technically RGB and CMYK 8-bit files have exactly the same color gamut (dynamic range) @ 256 gray levels per channel.

The CMYK gamut is not 'truncated' by Photoshop per say. Select > Image > Adjustments > Levels... displays 256 gray levels in both CMYK or RGB modes. CMYK is only truncated when the 8-bit dynamic range is further compressed upon final output (i.e. a halftone plate @ 100 gray levels per color).

Photoshop's standard (US SWOP v2) profile applies a compression algorithm of 256 > 100 gray levels for CMYK printing in the foreground (actual CPU data remains 256 gray levels). This 'apparent' gamut compression 'assumes' it will be for the offset process.

However, if the same CMYK file is output via http://www.durstus.com/mbLit/dl/Lambda/Lambda130_E.pdf, the color gamut is preserved because the output medium defines the 'gamut' (not Photoshop's ICC). Lambda simply converts CMYK to RGB (internal ICC) and images all 256 gray levels per channel to produce a vibrant photographic transparency.

Therefore, ICC based CMYK++ separations from CMYK files should also be possible because the dynamic range is still 8-bit.

 

[meddington]

Technically RGB and CMYK 8-bit files have exactly the same color gamut (dynamic range) @ 256 gray levels per channel.

I am not following this logic. Dynamic range/gray level and color gamut are not the same thing. A conversion from one color space too another invariably results in give and take between the achievable color gamuts, regardless of bit-depth. This is the nature of device-dependent color spaces.

See this for clarification:
http://printplanet.com/forums/color-management/24434-bit-depth-vs-gamut

However, if the same CMYK file is output via http://www.durstus.com/mbLit/dl/Lambda/Lambda130_E.pdf, the color gamut is preserved because the output medium defines the 'gamut' (not Photoshop's ICC). Lambda simply converts CMYK to RGB (internal ICC) and images all 256 gray levels per channel to produce a vibrant photographic transparency.

The output medium certainly does define the gamut, but your description above isn’t preserving any gamut. A more appropriate description is that the Lamba device is not honoring the intent of the original CMYK ICC profile. If it were, the result should look as if it were printed via the methodology of the original CMYK ICC profile.

Therefore, ICC based CMYK++ separations from CMYK files should also be possible because the dynamic range is still 8-bit.

Its certainly possible ( CMYK++ separations from CMYK files), but you won’t gain any gamut volume. You could perform the conversion from CMYK to CMYK++ and when printed it should render the appearance of the original CMYK. If you wanted to take advantage of the available CMYK++ gamut, you would either work from the original, larger gamut RGB file, or edit your CMYK++ image separation to take advantage of the available volume. Esko provides the Equinox Plugin to facilitate this. Spotless relies on the end user to do this manually.

 

[Bradleyp]

The output medium certainly does define the gamut, but your description above isn’t preserving any gamut. A more appropriate description is that the Lamba device is not honoring the intent of the original CMYK ICC profile. If it were, the result should look as if it were printed via the methodology of the original CMYK ICC profile.

We agree the output medium defines the color gamut. Therefore, using the same CMYK ICC profile to image a CMYK file via Lambda will reproduce a larger color gamut than the same CMYK file printed in offset at say ISO 12647-2 specs. Lambda utilizes the full 256 gray levels per RGB channel. In process printing however, the 'originals' dynamic range must be compressed from 256 (2.40d) to 100 (2.0d) to produce 4 x halftone plates. The "color gamut" is further compressed because process CMY inks cannot be printed with a Dmax of 2.0 due to loss of print contrast (i.e. excessive dot-gain). The SWOP Dmax standard is C&M-1.40, Y-1.00. On a Lambda device CMY photographic dyes can print a Dmax beyond 2.0 because the process is continuous tone (not halftone).

Dynamic range/gray level and color gamut are not the same thing.

However dynamic range compression is directly related to gamut compression. Gamut = Range. A dynamic range of 2.4d can reproduce a greater color gamut that a dynamic range of 2.0d (halftone compression) and 1.40d (ink/color compression). This is a mathematical fact. 'Color' in a CPU doesn't exist per say. RGB images are simply (3 x 256) grayscale channels = 16.7 million 'colors'. CMY images (forget K channel) are also (3 x 256) grayscale channels = 16.7 million 'colors'.

Example: Open any colored CMYK image in PSD. Duplicate the image. Convert duplicated CMYK image back to RGB. Now copy/paste the C,M & Y channels (from original CMYK) to the R, G & B channels respectively. Select RGB image > View > Gamut Warning. Now PSD is saying the RGB 'color' is out of CMYK gamut? Yet we simply cut & paste 3 x 256 grayscale channels from one color mode to another. Where did the extra 'color gamut' come from? (that's apparently already been 'truncated' in CMYK mode)?

Back to my original statement: Technically RGB and CMYK 8-bit files have exactly the same color gamut (dynamic range) @ 256 gray levels per channel.

The process of extended color separation dates back to 1994 Patent US5528377 - Extended density color printing - Google Patents. Don Hutcheson's entire theory is based around dynamic range. The extra-trinary separations were derived from 8-bit CMYK files (back when ICC and "device-dependent" color spaces were still in diapers).

'Thus, the ability to accurately reproduce an image may be limited to only those densities equal or less than the print densities available on the printing device.' - Don Hutcheson

 

[gordo]

[SNIP]If you wanted to take advantage of the available CMYK++ gamut, you would either work from the original, larger gamut RGB file, or edit your CMYK++ image separation to take advantage of the available volume. Esko provides the Equinox Plugin to facilitate this. Spotless relies on the end user to do this manually.

Not quite right. Spotless is not involved with CMYK++ raster images/Hi-Fi image image separations. If you want to do CMYK++ separations in a Kodak Prinergy work flow you either do the separations manually, create the separations using a third-party application, or send the RGB image through Prinergy and let Prinergy do the separations auto-magically using a CMYK++ ICC Profile.

best, gordo

 

[Bradleyp]

I am not following this logic. Dynamic range/gray level and color gamut are not the same thing. A conversion from one color space too another invariably results in give and take between the achievable color gamuts, regardless of bit-depth. This is the nature of device-dependent color spaces.

Example: Open any colored CMYK image in PSD. Duplicate the image. Convert duplicated CMYK image back to RGB. Now copy/paste the C,M & Y channels (from original CMYK) to the R, G & B channels respectively. Select RGB image > View > Gamut Warning. Now PSD is saying the RGB 'color' is out of CMYK gamut?

You should end up with this https://dl.dropbox.com/u/10335197/CMYK & RGB examples.zip
CMYK 8-bit files contain plenty of 'color gamut' to extract CMYK++ separations. RGB files are not mandatory. This is a common misunderstanding.

Brad.

 

[gordo]

[SNIP]The "color gamut" is further compressed because process CMY inks cannot be printed with a Dmax of 2.0 due to loss of print contrast (i.e. excessive dot-gain). The SWOP Dmax standard is C&M-1.40, Y-1.00. On a Lambda device CMY photographic dyes can print a Dmax beyond 2.0 because the process is continuous tone (not halftone).

This is not quite correct.
You can increase the solid density (and hence the gamut (chroma)) of process inks to a certain point, but the limitation is not print contrast since print contrast can be restored with a compensation curve applied during plate imaging. The limitation is that as the density of process inks increases - at a certain point they lose sufficient transparency so as to block light being reflected by the substrate through the ink. At that point chroma no longer increases. E.g. a layer of ink 1/4" inch thick has the same density and chroma as a layer of ink that's 4" thick.

With process inks or (photographic) dyes (e.g. the Lambda device) you are using the substrate as the "light" that is then filtered by the ink which results in the colour that you see or measure. The limitation of density (and therefore increased opacity) vs transparency and hence potential gamut applies to both processes.

Technically speaking continuous tone process does not increase gamut compared with a halftone device.
Properly speaking, light reflected off the substrate is filtered by the ink or dye. With a halftone, some of the paper is covered by the ink, or dye, which then filters the light. However, some of the light falls between the halftone dots and is not filtered the ink, or dye. Instead, this unfiltered light merely reflects off the surface of the substrate and mingles with the light that has been filtered by the ink, or dye. This unfiltered light effectively contaminates the purity of the color reducing its chroma. This contamination of color does not happen with continuous tone printing because all of the light is filtered by the ink, or dye.

The bottom line is that the halftoning reduces the potential gamut compared with continuous tone printing.

[SNIP] The process of extended color separation dates back to 1994

That's not correct. By 1994 there were already 27 vendors of different extended color separation solutions. Linotype-Hell, for example, demonstrated their 7 color process at Drupa 1990. In my own library I have books printed before 1900 using 6 and 8 color process printing.

Here's a link to the most common methods for Hi-Fi printing (most available before 1994): http://the-print-guide.blogspot.ca/2009/06/hi-fi-color-8-strategies-to.html

'[SNIP] Thus, the ability to accurately reproduce an image may be limited to only those densities equal or less than the print densities available on the printing device.' - Don Hutcheson

Not quite. While densities are limited on different printing devices, there are other factors (such as screening method, base hues, etc.) that enable the reproduction process to accurately reproduce an image. If you've ever done limited edition print reproduction you'd know that is true.

gordo

 

[meddington]

Example: Open any colored CMYK image in PSD. Duplicate the image. Convert duplicated CMYK image back to RGB. Now copy/paste the C,M & Y channels (from original CMYK) to the R, G & B channels respectively. Select RGB image > View > Gamut Warning. Now PSD is saying the RGB 'color' is out of CMYK gamut?

You should end up with this https://dl.dropbox.com/u/10335197/CMYK & RGB examples.zip
CMYK 8-bit files contain plenty of 'color gamut' to extract CMYK++ separations. RGB files are not mandatory. This is a common misunderstanding.

Brad.

I agree that RGB files are not mandatory, and yes, you can certainly derive CMYK++ separations from a CMYK file. What I responded to was your contention that CMYK and RGB files have "exactly the same color gamut", due to their bit depth (8-bit = 256 levels of grey for both). However, changing the bit depth of an image from 8 to 16 bit does not change the gamut. It changes the number of discreet levels within that gamut. You can certainly obtain many different color gamuts (volumes if you will) from a single CMYK separation...simply by assigning different profiles or utilizing different output methodologies, but that's not really the point. Once you convert from RGB to CMYK, you'll be hard pressed to convert back to RGB and recover the original appearance (unless the majority of the image data was already within the gamut of the CMYK volume).

 

[Bradleyp]

You can certainly obtain many different color gamuts (volumes if you will) from a single CMYK separation...simply by assigning different profiles or utilizing different output methodologies, but that's not really the point.

Agreed. Let's ignore profiles for a moment and review the 'absolute' color gamut of an RGB file.

In the enclosed files https://dl.dropbox.com/u/10335197/CM...20examples.zip

The color gamut of an RGB file is:

Absolute Red: 255r.0g.0b
Absolute Green: 0r.255g.0b
Absolute Blue : 0r.0g.255b

There are no RGB definitions beyond 0-255. Therefore, an RGB files color gamut 'boundary' is directly related to it's bit depth.

The color gamut of a CMYK file is:

Absolute Red: 0.100m.100y
Absolute Green: 100c.0.100y
Absolute Blue: 100c.100m.0y

However, gray level 100 (CMYK mode) is still assigned 0 (in RGB mode) because both files are 8-bit. Each CMYK gray level is only compressed (2.56:1 ratio) upon output to a halftone dynamic range (0-100 = 2.0d). CMYK's 256 gray levels are preserved up until that point.

Technically RGB and CMYK 8-bit files have exactly the same color gamut (dynamic range) @ 256 gray levels per channel.

Please allow me to correct my original quote to: Technically RGB and CMYK 8-bit files have exactly the same color definitions (dynamic range) @ 256 gray levels per channel.

However, changing the bit depth of an image from 8 to 16 bit does not change the gamut.

Agreed, slicing the pizza into smaller pieces doesn't make it any bigger. However, an 'original' 16-bit file (i.e. not extrapolated from 8-bit) would definitely have a larger dynamic range and therefore a larger color gamut with 65,536 gray levels per channel.

The color gamut of a 16-bit RGB file is:

Absolute Red: 65,535r.0g.0b
Absolute Green: 0r.65,535g.0b
Absolute Blue: 0r.0g.65,535b

Imagine a monitor that could display this! - LOL

Brad.

 

[meddington]

I'm not able to review your images at the moment, but why would you expect an "original" 16 bit image to have a higher dynamic range? The levels of encoding have no bearing on a device's darkest black or whitest white...These are device dependent attributes. Gamut boundaries are based on colorants and dynamic range, but not bit depth.

 

[Stephen Marsh]

It is often hard to ignore profiles. In regards to the actual colour of a file, RGB numbers and CMYK numbers are simply values, until they are linked to a description or ICC profile. Once the files numbers are linked to an ICC profile one can have a better understanding of the meaning of those numbers. A RGB value of 255r0gb has a different L*a*b* colour when evaluated against Pro Photo RGB or sRGB ICC profiles.

Stephen Marsh

 

[Bradleyp]

I'm not able to review your images at the moment, but why would you expect an "original" 16 bit image to have a higher dynamic range? The levels of encoding have no bearing on a device's darkest black or whitest white...These are device dependent attributes. Gamut boundaries are based on colorants and dynamic range, but not bit depth.

When you do have time to review the posted images, I'd be happy to continue the discussion.

Gamut boundaries are based on colorants and dynamic range, but not bit depth.

In the meantime, maybe you can support this statement with actual data? Thanks.

Brad.

 

[Bradleyp]

It is often hard to ignore profiles. In regards to the actual colour of a file, RGB numbers and CMYK numbers are simply values, until they are linked to a description or ICC profile. Once the files numbers are linked to an ICC profile one can have a better understanding of the meaning of those numbers. A RGB value of 255r0gb has a different L*a*b* colour when evaluated against Pro Photo RGB or sRGB ICC profiles.

Granted, all RGB>CMYK conversions pass through a L*a*b* LUT. However, L*a*b* is NOT a color reproduction system. RGB is the additive system (light) & CMYK is the subtractive (ink). L*a*b* only assigns gray scale values in a given gamut.

Irrespective of the RGB profile or Monitor display (Meddington's 'colorants'), the actual gray scale data doesn't change. The color gamut 'boundary' (dynamic range) of an RGB 8-bit file is still:

Absolute Red: 255r.0g.0b
Absolute Green: 0r.255g.0b
Absolute Blue : 0r.0g.255b

Brad.

 

[Bradleyp]

That's not correct. By 1994 there were already 27 vendors of different extended color separation solutions. Linotype-Hell, for example, demonstrated their 7 color process at Drupa 1990. In my own library I have books printed before 1900 using 6 and 8 color process printing.

Thanks Gordo, you're correct. 'Touch' or 'bump' color separation was around long before 1994. I was referencing that particular patent as it related to CMK++ long before commercial ICC profiling even existed. My point being, nothing has changed except for the industry's ignorance pertaining to RGB and CMYK bit-depth = dynamic range.

Brad.

 

[Bradleyp]

I'm not able to review your images at the moment, but why would you expect an "original" 16 bit image to have a higher dynamic range? The levels of encoding have no bearing on a device's darkest black or whitest white...These are device dependent attributes. Gamut boundaries are based on colorants and dynamic range, but not bit depth.

This article explains how dynamic range is directly calculated from bit depth: https://dl.dropbox.com/u/10335197/Dynamic Range.pdf

Therefore, an 'original' 16-bit image captured from a drum scanner or digital camera must have a higher dynamic range and wider color gamut 'boundary' compared to a 12 or 8-bit image. We agree, extrapolating 8-bit to 16-bit in PSD does not extend the dynamic range or color gamut, it merely adds intermediate gray levels for enhanced editing purposes: 8 Bit Color vs 16 Bit Color - Working With 16 bit Images In Photoshop

Brad.

 

[meddington]

Example: Open any colored CMYK image in PSD. Duplicate the image. Convert duplicated CMYK image back to RGB. Now copy/paste the C,M & Y channels (from original CMYK) to the R, G & B channels respectively. Select RGB image > View > Gamut Warning. Now PSD is saying the RGB 'color' is out of CMYK gamut?

OK, I’ve followed your example above, but I’m not understanding what this is supposed to prove. I’m making the assumption that your Photoshop Working space is USWebCoatedSWOP for CMYK and sRGB for RGB. If that’s the case, the gamut warning is accurate in that a portion of cyan, green and a bit of yellow in SWOP is outside the gamut of sRGB. (attached pic shows your CMYK image data plotted against the sRGB colorspace. sRGB cannot fully contain SWOP).

Now, if you convert your CMYK image to RGB using AdobeRGB1998 as the destination and repeat your test, you’ll find significantly less colors reported as out of gamut. Why?....AdobeRGB has a larger gamut and more fully encompasses USWebCoatedSWOP.

A better test for you would be to create an RGB granger rainbow...any flavor of RGB. Then simply turn on the gamut warning, presuming a SWOP cmyk working space. All that color reported as ‘out of gamut’ is lost upon conversion and cannot be regained. You could play around with assigning different RGB and CMYK working spaces, but I can’t imagine how this would be beneficial in any way.

Irrespective of the RGB profile or Monitor display (Meddington's 'colorants'), the actual gray scale data doesn't change. The color gamut 'boundary' (dynamic range) of an RGB 8-bit file is still:

Absolute Red: 255r.0g.0b
Absolute Green: 0r.255g.0b
Absolute Blue : 0r.0g.255b

Yes, I agree that these values don’t change and that 255 is the max value for any 8-bit RGB image, but they are device numbers....reliant on the device that renders them as to what the actual color will yield. Absolute red on one monitor will yield a different appearance than absolute red on another monitor, or from a scanner or digital camera. Without defining the colorants, the numbers are pretty meaningless. You are using the terms bit depth, dynamic range and color gamut interchangeably, and they are interrelated, but they are not the same.

This article explains how dynamic range is directly calculated from bit depth: https://dl.dropbox.com/u/10335197/Dynamic Range.pdf

Therefore, an 'original' 16-bit image captured from a drum scanner or digital camera must have a higher dynamic range and wider color gamut 'boundary' compared to a 12 or 8-bit image. We agree, extrapolating 8-bit to 16-bit in PSD does not extend the dynamic range or color gamut, it merely adds intermediate gray levels for enhanced editing purposes: 8 Bit Color vs 16 Bit Color - Working With 16 bit Images In Photoshop.

Thanks for sharing that (Wow, 1993?!). There are two methods given for calculating dynamic range, DR=Dmax-Dmin & DR=log10 of the # of input gray levels. The second definition I would classify as theoretical, as its not based on any actual output or measurements (though manufacturers love it). And though it takes into account the number of gray levels, this doesn’t necessarily have a direct bearing on the maximum achievable color gamut. Digital cameras often fall well short of the reported theoretical dynamic range assertions from the manufacturer.

I come from a scanning background, and we calculated dynamic range directly from the measured media...reflective and transmissive grayscales (a method that is now a standard, ISO 21550). The dynamic range of PMT scanner I operated was certainly limited by the media being scanned. Different transparency emulsions would yield a different d-min/max. It is still my contention that dynamic and bit depth are not directly correlated, despite a methodology deriving a DR value from bit depth (and I'm not alone in this viewpoint). You can render an image with any number of bits, but the only obvious difference will be the number of steps.

Relating to color gamut, I created two Granger rainbows in Photoshop, one 16 bit, one 8 bit, then graphed the image data in Colorthink Pro. Both occupy the same gamut volume. (attached pic, 8bit green, 16bit red). The only perceivable difference was the smaller spot size on the 16 bit plot.

I guess we've wandered a bit off the topic of Esko Equinox.

 

[gordo]

[SNIP]
Therefore, an 'original' 16-bit image captured from a drum scanner or digital camera must have a higher dynamic range and wider color gamut 'boundary' compared to a 12 or 8-bit image.[SNIP]

I don't think so (but I'm happy to be shown to be wrong).

The key statement in the PDF you linked to is "Dynamic range is defined as the ratio of the maximum to the minimum density or luminance values". But to achieve a greater gamut you need more chroma rather than greater dynamic range. The darkest dark and the lightest light you can have in a transparency may be darker than the darkest dark and lighter than the lightest light that you can achieve in a print however (my speculation) the impact on gamut would be negligible to zero. Gamut is modeled somewhat like a football with light colors at the top and dark at the bottom. Just like a football the distance from neutral (the centerline of the football) to the perimeter (chroma) is very short at the lightest and darkest points. And our eye/brain has difficulty distinguishing very small chroma (and even hue) differences at the extremes.

The other article "8 Bit Color vs 16 Bit Color" basically talks about 16 bit color having more discrete steps between grey levels but the gamut is the same. Like two identical oranges (gamut volume) but one orange having more segments (discrete sections) than the other.

best, gordo