New Approach for Generating Optimal Profile Patch Sets

[Stephen Ray]

No, as it has to be assumed to be in some color space for any conversion. It is untagged because it's to be treated as a target. But you can't run it through any output profile without some assumption to get to Lab in the CMM. Depending on what software is being used for the conversion, that assumption is either sRGB or whatever RGB working space is set in Photoshop.
The idea is to print this out without color management. To test differing media settings prior to making a profile. To visually see what media setting, based on the output without color management might be the best choice. The idea is to dismiss the generalization as I noted, that RGB printers are well behaved. Some are, some are not. Much has to do with the driver handling the data. As you can see from Mark's output, or if you print this yourself, certainly on an Epson, the native driver isn't close to producing linear output. So we're kind of going around in circles, the target was created for a specific goal and I brought it up simply for others to use to see how their drivers behave with a fixed media setting and without color management.

Gotcha.

[Stephen Ray]

To that end, no, I don’t believe a profile is able to correct some colours to put them where they should be, because how is the profile supposed to know where those colours should be placed(?).
Sent from my iPhone using Tapatalk

So, you're saying a CMM is the actual component responsible for the corrections, yes?

[digitaldog]

So, you're saying a CMM is the actual component responsible for the corrections, yes?

Has nothing to do with corrections, CMM or otherwise. The CMM is simply the profile connection space component that converts between color spaces. Profiles define. They don't correct. Calibration can 'correct' (produce a desired behavior of a device, like a display). The profile reflects this condition for the CMS.
Humans correct. Based on viewing pixels in context and making subjective decisions (this is too dark, the WB isn't pleasing etc).

[Stephen Ray]

Has nothing to do with corrections, CMM or otherwise. The CMM is simply the profile connection space component that converts between color spaces. Profiles define. They don't correct. Calibration can 'correct' (produce a desired behavior of a device, like a display). The profile reflects this condition for the CMS.
Humans correct. Based on viewing pixels in context and making subjective decisions (this is too dark, the WB isn't pleasing etc).

Again, gotcha.

[aaron125]

So, you're saying a CMM is the actual component responsible for the corrections, yes?

No, a CMM can’t make any corrections because it has no idea of what is ‘correct’ and what is ‘wrong’. I think what you may be referring to as far as corrections are concerned is actually the calibration process. You initially mentioned correcting the cyan channel. As in RGB devices there is no cyan channel, I’m inferring you’re talking about CMYK devices, regardless of whether it be an inkjet printer or a printing press. In this case, it would be the calibration process which would make the corrections, as in when using a RIP and prior to creating a profile, one sets ink limits, etc. and this would be where the corrections you speak of are made.


Sent from my iPhone using Tapatalk

[Stephen Ray]

No, a CMM can’t make any corrections because it has no idea of what is ‘correct’ and what is ‘wrong’. I think what you may be referring to as far as corrections are concerned is actually the calibration process. You initially mentioned correcting the cyan channel. As in RGB devices there is no cyan channel, I’m inferring you’re talking about CMYK devices, regardless of whether it be an inkjet printer or a printing press. In this case, it would be the calibration process which would make the corrections, as in when using a RIP and prior to creating a profile, one sets ink limits, etc. and this would be where the corrections you speak of are made.
Sent from my iPhone using Tapatalk

After the initial RIP setup steps of calibration, etc., one proceeds to generate the ICC output profile as the last step. How would one describe, or what keyword would one use, the process of optimizing the accuracy of colors? I've been calling it "correction" (as in correcting deviant values) but is "re-mapping" or "converting" a better term?

[aaron125]

After the initial RIP setup steps of calibration, etc., one proceeds to generate the ICC output profile as the last step. How would one describe, or what keyword would one use, the process of optimizing the accuracy of colors? I've been calling it "correction" (as in correcting deviant values) but is "re-mapping" or "converting" a better term?

No, I think you’re spot on and correction is fine imho. I’ve only had a bit of experience with RIPs, mostly using EFI  Colorproof XF but I’m pretty sure they all use a reasonably similar process. Afaik, it’s not the setting up of the RIP where one calibrates but it should be done for every new media to be used with the RIP.


Sent from my iPhone using Tapatalk

[Stephen Ray]

No, I think you’re spot on and correction is fine imho. I’ve only had a bit of experience with RIPs, mostly using EFI  Colorproof XF but I’m pretty sure they all use a reasonably similar process. Afaik, it’s not the setting up of the RIP where one calibrates but it should be done for every new media to be used with the RIP.
Sent from my iPhone using Tapatalk

Thanks for the words of confidence!

[Doug Gray]

Here's the ICC description of a "profile"

ICC.1:2010 specifies the profile format defined by the International Color Consortium ® (ICC). The
intent of this format is to provide a cross-platform profile format for the creation and
interpretation of colour data. Such profiles can be used to translate between different colour
encodings, and to transform colour data created  using  one  device  into  another  device’s 
native  colour  encoding.  The  acceptance  of  this  format  by application and operating system
vendors allows end users to transparently move profiles, and images with embedded profiles, between
different systems. For example, this allows a printer manufacturer to create a single profile for
multiple applications and operating systems.

A CMM is mostly a module that does math. It's coded to run on a CPU, most commonly a iOS, Windows, or Linux system. It performs the math for applying a profile. A CMM, properly constructed*, will produce highly consistent results for printing because the ICC defines their requirements.  OTOH, a Profile is a binary object that is independent of OS's. The same profile can be used on any system. But a printer profile is specific to each printer and paper combination even though it can be used in any OS. A profile is a binary recipe that provides consistency more than anything else by mapping the printer's actual RGB (or CYMK) response to/from what colors it will actually print.

But not all CMMs are created equal. There have been different interpretations of what a CMM should do in certain circumstances. The most serious differences are mapping RGB colorspaces that have different white points. Microsoft's CMM, designed 20 years ago or so, will produce a vastly different image converting Adobe RGB to ProPhoto RGB using Abs. Col. with a large blue shift while Adobe's CMM will not. Adobe's follows a "clarification" the ICC made around 2002 while Microsoft's retains an older interpretation.

Microsoft's CMM also makes larger, though still small, errors converting back and forth between colorspaces.

[Stephen Ray]

The smoothness of transitions afaik is a purely subjective thing where one must determine for themselves if a particular printer/substrate/ink/profile combination provides the smoothness they desire. Typically something like a Granger rainbow might be used as a kind of (still subjective, but at least it’s a known image and therefore can be used to visually compare and make a choice regarding the way a profile handles various transitions) benchmark to show how transitions in areas of the colour spectrum are handled by a profile.
Sent from my iPhone using Tapatalk

Is Bill Atkinson's file "Twenty-eight balls" regarded as a good test for smoothness?

[Doug Gray]

Is Bill Atkinson's file "Twenty-eight balls" regarded as a good test for smoothness?

It is. It was actually designed for that purpose according to an email Andrew posted at dpreview. To do so print it untagged like you would print a profile target chart using ACPU or anything else that disables color management.

It doesn't have to (and typically won't) print the same on different printers. One looks for abrupt banding. A good printer should have no areas where there is abrupt banding. Do not compare it with color managed prints of the same. This shows a different kind of banding more related to how the profiles being used were created. The former is direct to the printer and no profile is involved. The latter can be used to select profiles. For instance the canned profiles in many Epson printers will print the blue ball as black. A different, custom profile may print it somewhat close to how it looks on a display. One can chance the profile's Perceptual table by a few different sliders in I1PRofiler to affect how the different balls print.

[Doug Gray]

It is a real pain to determine how much better one profile is than another. Particularly at high patch counts. Many things make it hard to determine profile quality.

1. Variation just due to printing two successive pages of the same image. I typically get a variation of .15 to .20 dE00 with glossy type papers and .1 to .15 dE00 with matte.

2. Variation when patches are randomized. Two pages with the same set of patches but randomized differently show a dE00 of about .25-.30 with glossy paper and .15 to .20 with matte. So location changes increases the variation in patches.

3. Subtle effects. I see smaller changes based on how humid it is when the print is made, .05 to .10 differences. And drying time of course effects things as well with about a .10 shift from 2hrs to 24hrs. To control this I try to keep the same drying time between the print and the scan. Within a few hours if the drying time is 24 hrs, within 5 minutes for a 2 hr drying time.  Almost all the changes occur while the surface is "wet" which can be easily checked with an IR imager since evaporation, even at low levels when it's 95% dry, can create a  2C down to .05C temp gradient from unprinted regions. This time varies between about 15 minutes on a real dry day to 45 minutes at 70% humidity.

Measuring small changes like the above can be done by making many copies of the same color. For instance duplicating each of 100 patches 9 times and scanning the 9000 patch set. This duplication reduces the variation (standard deviation of the mean) by about a factor of 3. Increasing the duplication to 50 patches reduces the uncertainty by a factor of about 5.  This is doable, and I've spend too much time trying to quantify some of these smaller effects.

So one can print a color managed CC with each of the 24 patches duplicated 9 times and that gives a good measure off accuracy. But only for those 24 CC colors. Alternately, one can print say, 318, in gamut, patches duplicated 3x, with known LAB values and get a wider spread of color accurate data. But that still only gets some info or profile quality.

I realized the way I'm approaching comparing profiles to each other needs to be done a different way to get reasonable results in a short time without wasting tons of paper. Here's what I came up with.

Given two profiles we will call profile A and Profile B do the following:

1. Generate 100000 random RGB triplets in device space.
2. Find the expected Lab values using AtoB from each profile.
3. To compare the profiles we concentrate on the differences. So...
4. Calculate  the dE00 on the 100000 Lab values from each profile.
5. Sort them for the largest dE00s.
6. Print the the RGB triples that produce the largest dE00 as a target.
7. Measure the actual Lab values of those triplets.
8. Compared the Lab values as measured against the predicted Lab values from each profile.
9. The profile that produces the closest dE00's is a better profile.

Easy, Peasy. Only have to print and measure two, single page targets!

Here's the results of from comparing the default iSis 957 patch against a printer/paper optimized target.

The Optimized patch set was created by using a 9x9x9 grid (729 patches). together with 512 patches on the centers (512 additional). Then the fraction of the patches that produced the largest dE compared to the 8 surrounding patches was sorted and the ones with the largest dE00 ( > .8 )  were added to the 729 to make 957 total patches which were then compared to the 957 iSis default patch set.

[Mark D Segal]

Technically interesting and very methodical, but would any one be able to perceive any difference in prints made with different profiles generated from the one approach or the other?

[digitaldog]

There is yet another variation; noise, slightly different measurements of the same target read two times in a row, even a minute apart. You'd need to do this multiple times, average the dE and subtract that. Fortunately everything is below a visual difference.

[Doug Gray]

Technically interesting and very methodical, but would any one be able to perceive any difference in prints made with different profiles generated from the one approach or the other?

Not with this particular printer/paper. I've generally found the 957 iSis Patch set works very well and haven't found any improvement visually using more patches like the Atkinson set outside of the 9800. I have found some improvement using larger patch sets with the 9800. Especially for B&W where the 9800 has some abrupt shifts the 9500 or Pro1000 does not. I have not yet investigated using this technique with the 9800 but I suspect it would improve it also. Right now my best 9800 profile set uses 3828 patches. I'm hoping this process lets me reduce the patch set size while stull producing excellent profiles.

Ideally, I'd like to make a set of patches that is small but still produces great results for each of my printer/paper combos.

But yeah, I'm a little OCD and I like to quantize stuff.

[Doug Gray]

There is yet another variation; noise, slightly different measurements of the same target read two times in a row, even a minute apart. You'd need to do this multiple times, average the dE and subtract that. Fortunately everything is below a visual difference.

There is indeed. And it's different between glossy and matte types as well. Typical differences for matte are on the order of .02 to .03 ave. with glossy slightly higher. I chalk it up partially to noise and partially to the glossy having more surface variations and subsequent passes having slightly different registration against the end diamonds.

BTE, To address, and minimize these effects, when I print targets to read with the iSis 2, I add a registration bar at the bottom so I can flip the paper around and read it backwards. Then the CGATs file can be flipped end over end and the results compared and averaged. It turned out to be differ about 1/4 of what reading a second randomized target produces. You can see the second registration bar on the ColorChecker like iSis targets I've posted on other threads.

[MHMG]

Technically interesting and very methodical, but would any one be able to perceive any difference in prints made with different profiles generated from the one approach or the other?

The answer lies in what colors are generating the dE2000 errors greater than 1 JND (just noticeable difference = 1 dE2000 unit) and how they present themselves in the printed image, i.e. how they alter visual contrast relationships within the image and also how colorful the colors with highest dE2000 errors are. Viewers are much more aware of neutral and near neutral dE2000 errors than the same dE2000 errors occurring in vivid colors when the colors are presented in the context of a complex image rather than as two isolated colors side-by-side on a neutral surround at a 2 degree or 10 degree angle of view.  So, the answer for the results Doug has presented is yes they might be observable and thus meaningful, or no, they may not be observable depending on the nature of the dE2000 errors (hue, chroma or lightness errors?) and how they are geometrically presented within the printed image.  Image banding, for example is typically a contrast error that can develop with very small L* errors in neighboring color values. It can also manifest as hue and chroma variations, but more often it grows more objectionable with L* errors.  To summarize, evaluating color for color's sake with color difference models like dE2000 is not the same thing as evaluating both color and tonal relationships in the context of complex images containing viewer identifiable information content.  Another metric beside dE or dE2000 is required to quantify the results... the reason the I* metric was invented. Other than that, one can only resort to printing an appropriate number of challenging images and then subjectively assess the situation. Easier said than done because choice of image also plays a big role.

cheers,
Mark
http://www.aardenburg-imaging.com

[Mark D Segal]

Thanks Mark - all of that makes a lot of sense to me.

[Mark D Segal]

But yeah, I'm a little OCD and I like to quantize stuff.

And I like to quantify stuff.....

-:)

[Doug Gray]

The answer lies in what colors are generating the dE2000 errors greater than 1 JND (just noticeable difference = 1 dE2000 unit) and how they present themselves in the printed image, i.e. how they alter visual contrast relationships within the image and also how colorful the colors with highest dE2000 errors are. Viewers are much more aware of neutral and near neutral dE2000 errors than the same dE2000 errors occurring in vivid colors when the colors are presented in the context of a complex image rather than as two isolated colors side-by-side on a neutral surround at a 2 degree or 10 degree angle of view.  So, the answer for the results Doug has presented is yes they might be observable and thus meaningful, or no, they may not be observable depending on the nature of the dE2000 errors (hue, chroma or lightness errors?) and how they are geometrically presented within the printed image.  Image banding, for example is typically a contrast error that can develop with very small L* errors in neighboring color values. It can also manifest as hue and chroma variations, but more often it grows more objectionable with L* errors.  To summarize, evaluating color for color's sake with color difference models like dE2000 is not the same thing as evaluating both color and tonal relationships in the context of complex images containing viewer identifiable information content.  Another metric beside dE or dE2000 is required to quantify the results... the reason the I* metric was invented. Other than that, one can only resort to printing an appropriate number of challenging images and then subjectively assess the situation. Easier said than done because choice of image also plays a big role.

cheers,
Mark
http://www.aardenburg-imaging.com

Very true, and by a factor of 5 or more compared to dE76 in may cases. It's one of the reasons I have focused so much on the neutrals for my 9800.  I am very pleased by the smoothness of the Pro1000 in the neutrals. Profiles can accommodate smoothness much easier than the rapid changes in a* and b* the 9800 has.

And another point that coincides with your observations. I worry about overfitting. With too many patches the profile is at increased risk of overcompensating resulting in potentially visible changes if one happens to run across an overcompensated region. My sense is that the smallest number of patches needed for a given printer/paper combo will generally yield better results than just using a very large number of patches. Especially w/o duplicate patch averaging but that gets tedious fast. Using duplicates of 4k patches starts to get painful. Even with an iSis. Hence the search. Duplicates of a good, working, optimized 957 patch set is doable and not painful.

Also, your points about JND colors is, indeed, context sensitive. dE2000 is pretty good when patches are not adjacent. If adjacent, smaller dE00 differences are often visible as banding. Especially with large, dark regions. dE00 is excellent at JND for two patches, separated by a thin boundary with 2 degree spread in a surround of L*50.  But JND is magnified any time the surround is similar to the patches.