Perceptual Rendering Argyll CMS

[DaveRichardson]

I've been reading this with interest and got to thinking why two profiles based on the same data, but constructed using different manufacturer software, might produce different outputs from RC intent but for "in gamut" colours.

My thoughts were :
1. Measurement differences - but Andrew's methodology takes this out of the equation.
2. "Broken" software - as put forward by Doug. Possible - but not proven.
3. Given that these are printer profiles, which are likely to be anything but the simple shape of a working colorspace, do the two pieces of software treat the smoothing of the profile and gamut differently? So that for example a colour classed as "in gamut" for the printer on one profile is classed as "out of gamut" on the other.
4. Are the two pieces of software introducing any compensation for Optical Brightners in the paper? As there is no standard method for this (as far as I am aware) then this would lead to different assumptions and therefore different profiles.

Dave

[digitaldog]

Doug, do you own a copy of ColorThink Pro?

[digitaldog]

My thoughts were :
1. Measurement differences - but Andrew's methodology takes this out of the equation.
2. "Broken" software - as put forward by Doug. Possible - but not proven.
3. Given that these are printer profiles, which are likely to be anything but the simple shape of a working colorspace, do the two pieces of software treat the smoothing of the profile and gamut differently? So that for example a colour classed as "in gamut" for the printer on one profile is classed as "out of gamut" on the other.
4. Are the two pieces of software introducing any compensation for Optical Brightners in the paper? As there is no standard method for this (as far as I am aware) then this would lead to different assumptions and therefore different profiles.

1. Exactly! Not sure why Doug is having difficulties doing this as ProfileMaker Pro and i1P will accept the same CGATs data.
2. Unproven and based on assumptions. I suspect he has no way to directly compare individual pixels converted through two profiles as I did. He's measuring a print which isn't by any stretch, the best way to test two profiles and their colorimetric effect on each image pixel.
3. Very possible. We'll probably never know without input from the color scientists and software engineers at each company. What is clear to me and perhaps other but not Doug is, this isn't shocking and somewhat expected. Not all profiles are created equally even when feed the same measurement data.
4. Not with my tests. Those are secondary options in the software products not accessed. At least with the two profiles I built for all the colorimetric tests shown here.

[DaveRichardson]

Cheers Andrew.

Very possible. We'll probably never know without input from the color scientists and software engineers at each company.

Does ColorThinkPro allow you to extract and display the printer gamut from the two printer profiles and see how they map onto each other. That may show such a difference.
The Argyll tools to do this would be iccgamut (to extract the gamut) and viewgam (to display)  - unfortunately I don't have two sets of profiling software that would accept the same data to try this.

Dave

[digitaldog]

Cheers Andrew.
Does ColorThinkPro allow you to extract and display the printer gamut from the two printer profiles and see how they map onto each other. That may show such a difference.

Yes it does, and images too. That's how I illustrated to Doug that the sRGB Macbeth image, aside from white, is fully enclosed within the printer's color gamut and by a lot! There's no color clipping.
What CTP does that presumably Doug can't is extract unique or all colors from an image too. That produces what's called a color list. One can build multiple such lists, then build a deltaE report as I did, that gave Doug the false impression 'something is broken'. ONE patch among the 220,000 device values extracted had a dE of 9. This is pure(er) Colorimetry than measuring a print by a long shot! Profile A produced 220,000 values, pixels, as did Profile B. We end up with 2 sets of Lab values and then produce a dE report directly from what the profile produced upon the image. Where the report gets useful is viewing the average dE and like all averages, the numbers used to produce that dE value. Max, Min, best and worst 10% reported also give you a vastly superior view of the differences in the two profiles, something measuring a patch on a print can't do, despite all the measurement noise added to that data. IF Doug had CTP, he could of course see his methodology and the ideas he's formed by them are not providing good data.

[digitaldog]

Ah, back to your two profiles that display poor profile programming. 

One being the product you yourself use?
The point is, what you can't seem to understand and can't test on your end is this silly statement of yours:
AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always.

What you refuse to see is that your profiles are flawed in some way in their AtoB1 conversions. Having seen individual profiles that were also far more flawed, it doesn't surprise me and, frankly, I don't see what conclusions you can draw from them other than one or the other of them had some sloppy programming.

You have absolutely no proof that's true nor have you provided an ounce of proof to back it up. You have some odd belief system based on poor testing methodology, that's rather clear.

[DaveRichardson]

I am not a colour scientist or software engineer (my field was telecommunications) however just thinking of this as a process. Even if we only take the simple case of relative intent and in gamut colours the software engineer still has to make decisions on :
a. How he will allow/account for variations in the printer output of patches used to create the profile
b. How he will allow/account for variations in the measurement of patches used to create the profile
c. How he will interpolate between the patches
d. How he will balance point accuracy with smoothness

The more I think about this , the more surprised I am how close two manufacturers profiles rather than there being differences.

Dave

[GWGill]

AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always. They are not supposed to scaled to the black point or in any way other than the media's white point.

I've always attempted to make ArgyllCMS profiles have an A2B Absolute Colorimetric rendering (when used with the ArgyllCMS CMM) that accurately represents an instrument measured behavior of a device,  but I've never assumed that other profile makers adhere to the same principles, although I would hope they would, and some seem to.

Relative Colorimetric introduces a few subtle issues related to Chromatic adaptation to the PCS white, that complicate things. This is because the ICC spec. says to use a very poor chromatic adaptation transform, the so called "wrong Von Kries". This and the mess made of Absolute Colorimetric intent and ICCV4 Display profiles hints to me that there are some cross purposes involved. I think that a bedrock foundation of a color profile format should be an unambiguous representation of it's measured behavior, but the ICC profile format sharing one table for both Absolute and Relative colorimetric seems to have lead to some problems in this regard. ( It is interesting that some later additions to the format allow for other tables that have discrete Absolute and Colorimetric tables.)

If you are interested in the details about the problems with Relatively Colorimetric, this may be of interest.

[GWGill]

Even if we only take the simple case of relative intent and in gamut colours the software engineer still has to make decisions on :
...

It's even more fun that that! There's also all the ways that the ICC machinery can be used to model the transform. Just sticking to ICCV2 for the moment there is:
* Choice of PCS - XYZ or L*a*b*
* If XYZ, you can use a matrix.What matrix do you use ?
* There are per-channel input curves, and these affect the cLUT grid placement. What shape should they be ?
* There are per-channel output curves. What shape should they be ?

All these effect the profile accuracy and efficiency.

Latter ICC revisions add even more flexibility.

[digitaldog]

But thank you for agreeing that the white patch is out my printer/paper gamut.

It is, but another of your poor assumptions and speculations without a lick of sound colorimetry. In terms of the dE report that proves the two profiles differ, it doesn't matter! The worst dE set of patches that produced the dE of 3 IS NOT WHITE! Those patches are only dE 1.5 different.
While I admitted that replying to you was largely a waste of my time, it's worth doing so to prove colorimetrically so many of your ideas have no basis in fact.

[DaveRichardson]

It's even more fun that that! There's also all the ways that the ICC machinery can be used to model the transform. Just sticking to ICCV2 for the moment there is:
* Choice of PCS - XYZ or L*a*b*
* If XYZ, you can use a matrix.What matrix do you use ?
* There are per-channel input curves, and these affect the cLUT grid placement. What shape should they be ?
* There are per-channel output curves. What shape should they be ?

Thanks Graeme it all helps my understanding and emphasises why we see differences. It also enhances my respect for those who produce such software 

Dave

[digitaldog]

The worst dE set of patches that produced the dE of 3 IS NOT WHITE! Those patches are only dE 1.5 different.

And the winner, the one patch with a dE of 3 from the Macbeth in sRGB (sorry, took CTP about an hour to sort 169000 color values):
R138.0   G130.0   B135.0   55.29   -0.02   -1.32         
R137.0   G135.0   B134.0   56.00   -1.88   0.05         dE3.01   

[Doug Gray]

And the winner, the one patch with a dE of 3 from the Macbeth in sRGB (sorry, took CTP about an hour to sort 169000 color values):
R138.0   G130.0   B135.0   55.29   -0.02   -1.32         
R137.0   G135.0   B134.0   56.00   -1.88   0.05         dE3.01

Thanks, I appreciate your effort.

Those are clearly from the Lab50 gray patch. Now I can see what process occurred. It's a roundtrip RelCol from each profile. The reported Lab values are what each profile, expects to be printed for that color. It may, or may not, reflect the color each profile would actually print. Given both profiles estimate the gray patch printed would have significant color shifts, one along the a axis, the other, the b axis, I would expect both would show a noticeable shift in color from a neutral gray in soft proofing. Interesting how different the printer's RGB values are as well.

My own profiling uses a patch set with added gray patches at delta 5 increments specifically to improve the interpolation algorithms for more B&W tonal accuracy. It improved things but I believe adding more patches in close proximity to the neutral ones  would provide even better results.

[Doug Gray]

It's even more fun that that! There's also all the ways that the ICC machinery can be used to model the transform. Just sticking to ICCV2 for the moment there is:
* Choice of PCS - XYZ or L*a*b*
* If XYZ, you can use a matrix.What matrix do you use ?
* There are per-channel input curves, and these affect the cLUT grid placement. What shape should they be ?
* There are per-channel output curves. What shape should they be ?

All these effect the profile accuracy and efficiency.

Latter ICC revisions add even more flexibility.

They do, however, my reading of the ICC spec and associated papers is that this added stuff, apparently so that vendors can incorporate their proprietary secret sauces, is being done for Perceptual intents. They seem to be trying to reel in the RelCol side though. V4 is more strict about RI and now clearly disallows BP correction in RI. Incorporating BP in the 3DLUT transforms, engaged in by a minority of even V2 vendors, hoses over the ability to proof. It also, probably even more problematically, creates unnecessary problems using different vendor profiles. For instance creating a hard proof targeting a printer that has a profile with BP baked in v a local printer's that did not.

[GWGill]

They seem to be trying to reel in the RelCol side though.

That's what I mean by cross purposes. On the one hand the Relative Colorimetric table has the purpose of representing the colorimetric behavior of the device. On the other hand, users want to use it to render images in certain ways (gamut clipping). These are in conflict (for instance) when it comes to what to do with the black point. The users want to be able to link the profiles and have the black point mapped. If you don't do the mapping to/from a common luminance range in the Colorimetric tables, then you have to employ a messier solution such as Adobe BPC.

The correct (non-backwards compatible) solution is to separate the measurement/colorimetric table from the "clipping" intent table.

[Doug Gray]

That's what I mean by cross purposes. On the one hand the Relative Colorimetric table has the purpose of representing the colorimetric behavior of the device. On the other hand, users want to use it to render images in certain ways (gamut clipping). These are in conflict (for instance) when it comes to what to do with the black point. The users want to be able to link the profiles and have the black point mapped. If you don't do the mapping to/from a common luminance range in the Colorimetric tables, then you have to employ a messier solution such as Adobe BPC.

The correct (non-backwards compatible) solution is to separate the measurement/colorimetric table from the "clipping" intent table.

What seems to be happening is that BPC is being incorporated in Perceptual mapping but not in the RelCol. Both the older PM5 and the newer I1Profiler do it that way.  The ICC has published specific advice to V2 profile makers to do the same.

Under Black Point Scaling, putting it in the RelCol transforms is considered an error in the ICC note:

Error: Black point scaling applied in A2B1 or B2A1 transforms


http://color.org/v2issues.xalter