Perceptual Rendering Argyll CMS

[digitaldog]

Obviously not the result of a spectro measurement.

No! Because that methodology is FLAWED as would be the conclusions from it.
You don't appear to wish to tell us what Spectrophotometer you're using but I well. Here's the same target scanned twice on an i1 iSis XL:

--------------------------------------------------


dE Report


Number of Samples: 1728


Delta-E Formula dE2000


Overall - (1728 colors)
--------------------------------------------------
Average dE:   0.25
    Max dE:   0.75
    Min dE:   0.01
 StdDev dE:   0.12


Best 90% - (1554 colors)
--------------------------------------------------
Average dE:   0.22
    Max dE:   0.41
    Min dE:   0.01
 StdDev dE:   0.10


Worst 10% - (174 colors)
--------------------------------------------------
Average dE:   0.49
    Max dE:   0.75
    Min dE:   0.42
 StdDev dE:   0.06


--------------------------------------------------
--------------------------------------------------
That's noise in the data you don't have to introduce to see the differences in two RelCol results!


Now look at the dE differences measuring the same target with two different iSis XL's one being a Rev C and one a Rev E:



--------------------------------------------------


dE Report


Number of Samples: 1485


Delta-E Formula dE2000


Overall - (1485 colors)
--------------------------------------------------
Average dE:   0.71
   Max dE:   1.81
   Min dE:   0.02
StdDev dE:   0.30


Best 90% - (1336 colors)
--------------------------------------------------
Average dE:   0.65
   Max dE:   1.14
   Min dE:   0.02
StdDev dE:   0.24


Worst 10% - (149 colors)
--------------------------------------------------
Average dE:   1.29
   Max dE:   1.81
   Min dE:   1.14
StdDev dE:   0.13


--------------------------------------------------
--------------------------------------------------


Now examine what I just illustrated correctly: sRGB, a mere 24 patches of a MacBeth, run through two profiles with identical measured spectral data and a dE reported without any such Spectrophotometer noise or differences. A max dE of 3. Not egregious but enough to put the myth that:  AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always, doesn't hold any value Colorimetrically!

[Doug Gray]

What Spectrophotometer would that be, since you brought that into the discussion?

I have a I1 Pro, and I1 Pro uv cut, and an I1 Pro 2. I needed the uv cut because I had a few cases where the paper had OBs but I was going to show it under uv filtered glass. Got to have uv cut for accurate color doing that.

They all, in M0 or M2 as appropriate, are quite consistent though the I1 Pro 2 produces more consistent readings of the same patch. Average dE2ks are just over 0.1 on repeat scans. I get more variation from humidity and temp changes with a new printed scan sheet than the instrument itself. The three match to about .5 dE76 on the various colorcheckers I have.  They actually vary in color more - upwards of dE76 5 (much less in dE2k) in some cases on the colorchecker patches.

[digitaldog]

I have a I1 Pro, and I1 Pro uv cut, and an I1 Pro 2.

Mine's better 


Try measuring the same target two times in a row and examine what I just illustrated to you, using a much more accurate Spectrophotometer! The difference are to be expected. But they don't need to be used to pollute the differences in the testing of two RelCol profile tables!


Just run images through the two profiles with the same RI and if you have the tools, you can produce a dE report of the differences. As you can see, on an sRGB image (gamut shouldn't be a factor) of a mere 24 patches, the differences in two profiles using RelCol is a max dE of 3. Again, not a huge problem, but it surely dismisses your expectations of what a RelCol provides. To be expected! The color engines are not the same.


What another wakeup call? Calibrate your display with the same instrument but two different packages using the same calibration targets. Try a standard illuminant for white point which has no ambiguities as to what that's supposed to be (let alone a CCT value). Bet you dollars to doughnuts you get different results.


Maybe in a prefect world, the two would match as would your idea that a RelCol result from two profiles would match. Spoiler alert, this isn't a perfect world.


Should we expect two packages with identical spectral data to produce differing results with a Perceptual table? Yes (Velvia or Ektachrome). Should YOU expect the same spectral data sent to two packages to produce identical results with a RelCol conversion? You shouldn’t and I just proved why. 

You are wrong.

You may wish to reconsider that....

[digitaldog]

I have a I1 Pro, and I1 Pro uv cut, and an I1 Pro 2. I needed the uv cut because I had a few cases where the paper had OBs but I was going to show it under uv filtered glass. Got to have uv cut for accurate color doing that.

How about another wake up call to ruin your day.
Take a few hundred color patches, perhaps those you use to build your profiles.
Measure them with each instrument using any or all modes you wish.
Compare the dE differences in ColorThink. Are they the same? What's the dE differences? Which one is 'correct'?
If I measure the same target on my iSis, guess what, there will be differences colorimetrically! Just look at the differences in the same hardware with different revisions I provided below (due to differences in components used between revisions). Which is 'correct'?
It's not rocket science but it is color science and there are lots of variables. Blanket statements about what should or shouldn’t be are one thing. The reality of the measurements is another.

[Doug Gray]

Mine's better 

Or at least more consistent which is normal for sheet scanners.

Try measuring the same target two times in a row and examine what I just illustrated to you, using a much more accurate Spectrophotometer! The difference are to be expected. But they don't need to be used to pollute the differences in the testing of two RelCol profile tables!

No. but the differences are not perceptible for in-gamut RelCol and are well below the variations caused by interpolation error in the profiles which is consistent with your report.

How about posting the image or link of the colorchecker you posted such an ugly color difference of earlier alaong with the profiles you used to create the difference. It's a pretty sever rendering to just plop out there without some investigation. I'd be happy to look into it.

[

Just run images through the two profiles with the same RI and if you have the tools, you can produce a dE report of the differences. As you can see, on an sRGB image (gamut shouldn't be a factor) of a mere 24 patches, the differences in two profiles using RelCol is a max dE of 3. Again, not a huge problem, but it surely dismisses your expectations of what a RelCol provides. To be expected! The color engines are not the same.

I have the tools and in fact have done that with colorcheckers in the past. IIRC, I've seen more difference between colorchecker vintages than prints from an "averaged" image. As measured.

What another wakeup call? Calibrate your display with the same instrument but two different packages using the same calibration targets. Try a standard illuminant for white point which has no ambiguities as to what that's supposed to be (let alone a CCT value). Bet you dollars to doughnuts you get different results.

Hardly a wakeup call. Quite right. In fact I set the xy coords of my CLD BL monitor (CG301) slightly differently from my LED BL CG318 to get the same white point appearance. The fluorescent BL of the 301 is, as all fluorescents, extremely spikey. I don't see a difference from spectros though. This could be just an individual difference in spectrum response. Spikey spectrums are known to exacerbate the normal differences in individual perception of color. The CIE color matching functions are themselves averages of a relatively small group of people from rather old experimental data. The spectrum from the LED BL is quite smooth and the 10nm sensitivity of the I1 isn't challenged unlike the CG301.

Maybe in a prefect world, the two would match as would your idea that a RelCol result from two profiles would match. Spoiler alert, this isn't a perfect world.

I'm not saying it's perfect. RelCol is a defined goal and the results depend on how smooth the printer responds to changes in RGB values. They have improved a lot over the last 15 years. All other intents (except Abs which is an unscaled Rel) and all colors that are out of gamut are a crapshoot. PI produces far more change to colors than  interpolation and instrument error.

Should we expect two packages with identical spectral data to produce differing results with a Perceptual table? Yes (Velvia or Ektachrome). Should YOU expect the same spectral data sent to two packages to produce identical results with a RelCol conversion? You shouldn’t and I just proved why. 

Agree re BtoA0, but we are talking apples and oranges. Rel col attempts, to within the physical limits of measuring equipment and printer rendering smoothness, to produce tables as accurately as possible. It is largely successful. Especially with printers that render their native RGB (or CYMK) smoothly.

But of course they don't produce identical results. Life has variations. I do expect in-gamut prints from them in RelCol to be visually indistinguishable and that has been my experience with a variety of printers outside of special cases such as printing smooth color gradients which can show variation, especially with printers that have significant non-linear changes over short RGB distances. The interpolation tables can't fix that. More patches can help. Or sometimes hurt.

[digitaldog]

How about posting the image or link of the colorchecker you posted such an ugly color difference of earlier alaong with the profiles you used to create the difference.

http://www.digitaldog.net/files/2014PrinterTestFileFlat.tif.zip Just crop the MacBeth, convert to sRGB.

It's a pretty sever rendering to just plop out there without some investigation. I'd be happy to look into it.

There's nothing to look into. The Macbeth when converted with two different profiles using RelCol, built with the same spectral data produce a dE 3 max difference. Simple colorimetry. As I said, it's not a huge difference but it IS a difference!
Your testing methodology is flawed IF your goal is to prove that two different profile packages are supposed to produce the same results using RelCol simply because you've introduced measurement noise into the data and it's totally unnecessary! Take any image you wish in any color space and convert them with both profiles. Extract all colors in ColorThink, build a dE report. I cut you a lot of slack by using sRGB on a very simple 'image' of 24 patches of color. And without a lick of measurement noise, the max dE is 3. It could be much, much higher. But the point is, they ARE different.
It disproves this concept: AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always.

[Doug Gray]

http://www.digitaldog.net/files/2014PrinterTestFileFlat.tif.zip Just crop the MacBeth, convert to sRGB.
There's nothing to look into. The Macbeth when converted with two different profiles using RelCol, built with the same spectral data produce a dE 3 max difference. Simple colorimetry. As I said, it's not a huge difference but it IS a difference!

Oh. I gathered from your color subtraction image that the difference was pretty large. Fair to say that it is not an accurate representation of the actual color changes. I agree it is different (of course) but perceptibly different? It's really hard to tell one patch from another patch with a dE2k of 3 (which is the max) unless they are in close proximity or adjacent to a similar color that is more accurately rendered.

Your testing methodology is flawed IF your goal is to prove that two different profile packages are supposed to produce the same results using RelCol simply because you've introduced measurement noise into the data and it's totally unnecessary! Take any image you wish in any color space and convert them with both profiles. Extract all colors in ColorThink, build a dE report. I cut you a lot of slack by using sRGB on a very simple 'image' of 24 patches of color. And without a lick of measurement noise, the max dE is 3. It could be much, much higher. But the point is, they ARE different.
It disproves this concept: AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always.

These are interpolated tables. The introduced instrument noise, whether .1, .2 , or .5, isn't going to make much difference at all to the accuracy of the RelCol table profile generation process. The errors in the printer steps are often larger and no one is going to make a 4 Meg set of patches to profile a printer with. I'm not even sure that would work very well not to mention the profile s/w would choke on it. We depend on a certain level of smoothness.  In real life, in gamut, RelCol the question is are the prints distinguishable?  Maybe you have better eyes that I do.

[digitaldog]

Oh. I gathered from your color subtraction image that the difference was pretty large.

That test has zero data about the largeness of difference, only there IS a difference and you can visually see where! It dismisses your idea that: AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always.
The report from ColorThink has no visual analysis, it is all about colorimetry and produces a dE report. It illustrates the max dE is 3. It equally dismisses your idea that: AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always.

I agree it is different (of course) but perceptibly different?

A dE of three, yes! It also dismisses your theory that: AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always.

It's really hard to tell one patch from another patch with a dE2k of 3

As I said and you ignored (again), this test was built to cut you an awful lot of slack: sRGB with only 24 patches. But it doesn't matter, the concept you have about RelCol tables has no basis in fact.
I don’t know if you are purposely trying not to understand this, or if you are really struggling with it.

[digitaldog]

These are interpolated tables. The introduced instrument noise, whether .1, .2 , or .5, isn't going to make much difference at all to the accuracy of the RelCol table profile generation process.

It's noise that's unnecessary and a poor way to test assuming you have the software (ColorThink Pro) and knowledge to do the testing correctly.
Take ANY image in ANY color space you wish, convert from two profiles built identically expect for the software product that creates them, build a color list and produce a dE report. You've done so using the least impact on the data! There is absolutely no reason to be measuring anything to see how two profiles convert the data and report what that difference is!

[Doug Gray]

Here is the description of RC from the ICC.

On the other hand, rendering into PCS via the media-relative colorimetric path does NOT impose an image state transition, but rather accomplishes only an image encoding change, with a chromatic adaptation to the D50 PCS illuminant. Hence the media-relative colormetric paths into PCS may deliver an input-referred image (e.g., a hardcopy document scan), or an output-referred image to PCS. A media-relative colorimetric transform to PCS encoding must normalize the white point of the image medium to the PCS white point, keep the relationships between all in-gamut colours unchanged, and let the black point fall as a result.

This means that profile makers should produce as accurate a rendition of color as possible in BtoA1 transforms. This doesn't mean that printers have to be perfect because they aren't but it does mean that profiles should map the same color to the same color within the technical capabilities of the printer, patch set, and spectro, scaled with white point adaptation. It goes without saying that perfection in this process or any other physical one, is not obtainable. It does say that what the goal of RC is. As for a dE2k of 3, that's pretty large even if hard to see unless the patches are side by side. I'll get back to you with what I get here converting the CC portion of the image. I'd be surprised if it's that large since I don't normally see that much variation except at the gamut edges where the LUTs are discontinuous. There are only a few of those on the colorchecker.

[digitaldog]

This means that profile makers should produce as accurate a rendition of color as possible in BtoA1 transforms.

The key word here is "should" And in the real world, that isn't happening, sorry.
Maybe in the world you reside a colorimetric difference with an average of 1.0.7 and a max of 3.0.1 isn't a difference. In the world I'm in, it's a colorimetric difference.
Should I try the same test with the Gamut Test File? How about the example I provided of the i1P profile and the Epson Sekio profile where the blue's map black in the later profile, using again RelCol?
Best thing you can do is cease suggesting in the real world: AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always.
Supposed to and actually do are not the same. 

[Doug Gray]

How about the example I provided of the i1P profile and the Epson Sekio profile where the blue's map black in the later profile, using again RelCol?

What example was that? Was this some other discussion?

Obviously if blues map to black that's a huge difference. I've never seen RelCol produce anything like that or even close for printable colors. In fact, I can't say I've ever seen prints that looked different when printable colors were printed with ColRel except on broken profiles. And I have seen that. Some of the canned profiles are hosed. This sounds like something is either broken or the colors were outside the printable range. That's when you can get really different results. It's the kind of thing you see with dEs of > 20. Blue and black? Really!   I'm guessing out of gamut. RelCol makes no promises about how that would work. Any idea what Aryll does?

[Stephen Ray]

Andrew,

How about the example I provided of the i1P profile and the Epson Sekio profile where the blue's map black in the later profile, using again RelCol?

I would be interested in examining that particular Sekio profile if you care to provide a link. If not, no problem, understood.

Further, the "Bill's Balls"; can you post a screenshot of any complete set of balls that you feel appear to be correctly rendered? Maybe a good example of both Relative and Perceptual?

Thanks.

[digitaldog]

What example was that? Was this some other discussion?

Yes. Sorry, I thought you were following along with that example when you wrote: A profile that renders an L=1 on medium that has a minimum L=20, and, when reversed, claims to have rendered L=1, is broken.  Badly broken.
Here's the photo, you've seen it. http://forum.luminous-landscape.com/index.php?topic=106337.msg875057#msg875057

I've never seen RelCol produce anything like that or even close for printable colors.

And I've been saying, that's not necessarily the case. And thus far, I've provided an example with a max dE of 3 and can get a higher value if necessary.

Some of the canned profiles are hosed.

How is the fact it's canned alter the attributes of the profile itself? Look, we're going in circles here. For no reason. I've stated, before you arrived here, that not all profiles are created equally. I've stated that a RelCol rendering isn't as fixed or perfect as you state it should be. I've provided two tests; one visual, one colorimetric where the only difference is the package that built the profile. I've suggested the statement you've made about RelCol results are not based in reality but based on what you believe to be true and apparently based on what you've read from the ICC. Where to go from here? Probably not state as a fact that: AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always. Unless you can prove it with the two packages you're using, using sound testing methodology that doesn't require the use of a Spectrophotometer but rather, the actual data from two such profiles.

[digitaldog]

Andrew,

I would be interested in examining that particular Sekio profile if you care to provide a link. If not, no problem, understood.

If you have an Epson printer, you've got the profile. It's for Luster and installed by their driver. If not, I can send you the profile.

Further, the "Bill's Balls"; can you post a screenshot of any complete set of balls that you feel appear to be correctly rendered? Maybe a good example of both Relative and Perceptual?

Here's an example using the same two profiles I've analyzed for Doug along with the Seiko profile from an actual print (Roman 16):

[Doug Gray]

Well, I don't have two profiles made with the same spectral data handy so I'll do something better. Actually print the chart, measure the colors, and report the results with dE2k compared to Andrew's CC image. Oh, and I'll do it from Lab. No point in clipping the cyan patch. Also, I don't have any recently made profiles from different S/W as I'm using I1Profiler for printer profiles and have been for some time.

After all, it's the print that counts.

I'm curious what color is producing the dE2k max of 3.  That's outside what I normally see.

Have to get my VM machines working. Something I installed in the last 2 days had stopped VMWare cold.

Be happy to look at how your two profiles render the CC image if you want to share them.

[GWGill]

Any idea how Argyll's mapping of out of gamut colors is done compared to other profile vendors in BtoA1?

Sorry, it's not something I've explored.

I've been looking at the difference between conversions of extreme ProPhoto RGB values going directly to the PCS v clipping to Adobe RGB first. The printer gamut boundaries are inside Adobe RGB much of the time and the conversion path using Adobe RGB as an intermediate seems to produce significantly larger dEs on average.

Extreme ProPhoto RGB values, particularly blue, can be problematic when represented in some colorspaces (L*a*b*, raw CIECAM02), so there's little surprise if there are gamut mapping issues.

[GWGill]

Argyll asks for a source colour space -rather than a picture - when building a profile for output.

You can also supply an image gamut, although I'd recommend a Device Link workflow rather than creating image optimized Device Profiles - you probably want to build one for each image or group of images, so you may as well build just one specific table rather than 4, and a Device Link will give a noticeably smoother conversion.

[GWGill]

If all his software needs is the gamut of what you'll eventually render (into ProPhoto RGB), then ProPhoto RGB should work.

Yes, the device value curve shape should make little or no difference - the white & black points and the shape of the gamut surface should be the same.

[GWGill]

Accurate, reproducible color is extremely important to me. I check RelCol accuracy using a spectrophotometer. I make a random patch set using selections different from the stepped RGB values used for creating profiles.

It would be nice if it were that way in the real world, but there are a couple of confounding factors. One is the fuzziness of the ICC spec. There is enough ambiguity in it and the various attached commentaries that one could be forgiven for thinking that conversion to PCS values (even for the colorimetric table) should involve an appearance transform, since PCS has defined appearance parameters. I don't agree that such an interpretation is useful - I think RC should be firmly tied to instrument measurable values, but different factions within the ICC seem to be pulling in other directions at times - witness the ICCV4 spec. change that switched from display profiles being based on contact me asurements, to be being based on less well defined tele. measurements.

The other confounding factor is a repeatability/statistical issue. Neither the printing nor the measuring process are perfectly repeatable. Every reading is a point sample in the colorspace with added print, measurement and instrument uncertainty added to it. So the mathematical fact is that the profile that best represents the underlying device behavior, is not the one that minimizes the delta E to the measurement point set that it is created from. The latter in fact risks being a case of over-fitting.