Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: DaveRichardson on December 10, 2015, 10:34:20 am
-
When producing a printer profile in Argyll I am asked to supply a profile that the picture will be converted from (eg ARGB) in order that the perceptual rendering will be correct. Why is this, and if it is needed why did X-rites i1 match, the software I used to use, not ask for the same?
I ask this only for my own education, as it is not difficult to supply that input nor even build 3 separate profiles to convert from sRGB, ARGB and proPhoto.
Dave
-
When producing a printer profile in Argyll I am asked to supply a profile that the picture will be converted from (eg ARGB) in order that the perceptual rendering will be correct. Why is this, and if it is needed why did X-rites i1 match, the software I used to use, not ask for the same?
I ask this only for my own education, as it is not difficult to supply that input nor even build 3 separate profiles to convert from sRGB, ARGB and proPhoto.
Dave
One possible reason could be that they expand the PerCol gamut a bit to encompass what a printer can print given the limitations of sRGB. Since many, if not most, people that use PerCol, are doing so from an sRGB source it might make some sense. PerCol, is, after all, designed to look pretty and not map the source gamut as close as possible. The problem, of course, is that printing processes don't intrinsically have any idea what the color sources are since all it sees is L*a*b*.
That's one of the reasons I dislike PerCol. You never know what assumptions the profile maker had.
-
Doug
Thanks for replying. A couple of things I don't understand - please excuse my ignorance.
First your reference to "the PerCol gamut". When I google "Percol" I get a return on paper emulsion (well that and coffee :) !). What is PerCol?
Second why a limitation of sRGB comes into it. I am creating profiles on an Epson3800, measuring patches created from Argyll CMS and printed with no colour management with an i1pro spectrophotometer. The need to supply an input profile is described in the Argyll documentation as required only for the perceptual intent. I don't use sRGB at all - except when preparing images for the web.
There is a description on the Argyll CMS website but after reading it I have still not grasped the reason why :-[
Thanks
Dave
-
First your reference to "the PerCol gamut". When I google "Percol" I get a return on paper emulsion (well that and coffee :) !). What is PerCol?
New term for me too! Probably Perceptual Rendering intent?
Second why a limitation of sRGB comes into it
By the time an output profile 'gets' it's data, it's in Lab or similar (from the PCS). Some assumption is can be made as to the gamut of the source. And AFAIK, this is true for all rendering intents! Now is it sRGB? I believe that depends on who's making the profile. So there are more than one set of assumptions here! ;D
Best to contact Graeme Gill and ask him specifically what's going on here! graeme@argyllcms.com
-
Thanks Andrew - makes sense. It could be that the X-Rite software was just making an assumption whereas the Argyll software is asking for reality, so that the printer profile perceptual rendering based on an sRGB source is "squeezed" less than that based on Pro-Photo source.
I'll drop Graeme a line.
Dave
-
It could be that the X-Rite software was just making an assumption whereas the Argyll software is asking for reality, so that the printer profile perceptual rendering based on an sRGB source is "squeezed" less than that based on Pro-Photo source.
Perhaps. This is supposed to be a major feature of V4 profiles, namely what's called PRMG. X-rite doesn't support it. So their V4 profiles are just V2 in sheep's clothing. But what Argyll is doing is just a guess, never used it. But Graeme is very open about what's going on and can answer your questions without ambiguities. Plus he does hang out here and posts regularly so you might just try sending him a private message.
-
When producing a printer profile in Argyll I am asked to supply a profile that the picture will be converted from (eg ARGB) in order that the perceptual rendering will be correct. Why is this, and if it is needed why did X-rites i1 match, the software I used to use, not ask for the same?
Some information about this is here (http://www.argyllcms.com/doc/iccgamutmapping.html).
Short answer - to be able to do actual gamut mapping, rather than non-specific compression or clipping.
Longer answer - to be able to precisely map one gamut to fit inside another, you need to know what the gamuts are. When you are making a display or output profile, you know what one of the gamuts is (the output), but you know nothing specific about the other. Hence the need to specify it.
I have little idea what i1 match does. Since you tell me that no source gamut is able to be provided, I can only guess that it assumes a source gamut, or does a general level of compression or clipping of an incoming color that gets close to the output gamut.
An idea that has been floated by the ICC in relation to ICCV4, and (implicitly) may be something that some profile makers have been doing for a long time, is to target some common, intermediate gamut, making use of gamut mapping in both the A2B and B2A tables. The above link covers the drawbacks of this approach. In summary - you have still lost the relationship between source and destination gamut, leaving the overall gamut mapping in the dark about what it should do, and you end up concatenating two gamut mappings, increasing the inaccuracy of the whole process.
-
All of which, with the addition of PRMG confusion, is why Perceptual Colorimetric rendering, is something I avoid. There simply is no way to guarantee that you can print something with different printers/profiles and know you will get consistent results. You might. You just don't know. For RelCol you will always get consistent results printing in gamut colors. At least if your profile is properly made.
GWGill's link explains the conundrum pretty well.
-
All of which, with the addition of PRMG confusion, is why Perceptual Colorimetric rendering, is something I avoid. There simply is no way to guarantee that you can print something with different printers/profiles and know you will get consistent results.
The whole point of how ArgyllCMS does gamut mapping, is that you know exactly what is going on. Other profile makers, not so much...
-
The whole point of how ArgyllCMS does gamut mapping, is that you know exactly what is going on. Other profile makes, not so much...
How about not at all! ;D
Any idea how Argyll's mapping of out of gamut colors is done compared to other profile vendors in BtoA1? 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.
-
Short answer - to be able to do actual gamut mapping, rather than non-specific compression or clipping.
Longer answer - to be able to precisely map one gamut to fit inside another, you need to know what the gamuts are. When you are making a display or output profile, you know what one of the gamuts is (the output), but you know nothing specific about the other. Hence the need to specify it.
Graeme - thanks , that answers my question perfectly, I had read the article in your link but your addition here has clarified it for me. I can see the difference in compression if I apply, to the same image, a profile based on conversion from sRGB to another based on conversion from ProPhoto, both with perceptual rendering.
Perceptual Colorimetric rendering
Doug - thanks for clarifying.
99% of the time I use the Relative Colorimetric intent - but there is always the odd image with colours where that does not work was well as the Perceptual intent (some flower images come to mind).
Dave
-
Perceptual Colorimetric rendering
Is that a new or made up term?
-
How about not at all! ;D
Your bias and prejudice that Perceptual rendering isn't appropriate for you has been made clear more than once. The idea that there is no merit in any perceptual renderings from all products for all users is to be kind, hogwash. Again, profiles know nothing about color in context. I asked you in another thread why photographers shouldn't be given a choice in color rendering in E6 file (Velvia vs. Ektachrome as an example) which is no different than a Perceptual mapping of colors, you ignored that question. IF you need a colorimetric reproduction, Perceptual isn't for you. Yet many image makers desire pleasing color and that's exactly what a Perceptual rendering attempts, repeat, attempts to provide and not all are created equally. If you're quest is to argue with the author of ArgyllCMS he shouldn't be providing a Perceptual rendering in his product, I'm going to sit back and really enjoy that debate. :o
-
Other profile makers, not so much...
Or not at all, at least from X-rite. You have controls to alter the perceptual rendering attributes but they make no sense and the scales used (usually a 0-100 slider) makes absolutely no sense. You're flying blind.
-
You have controls to alter the perceptual rendering attributes but they make no sense and the scales used (usually a 0-100 slider) makes absolutely no sense. You're flying blind
On the i1match software - there was not even a slider, although I did use a "hack" given by Eric Chan a few years ago that allowed 3 variations on the perceptual intent.
I am enjoying getting to grips with the Argyll CMS software and the control that it allows. It is like switching off "programmed -auto" on the camera and taking control.
Dave
-
As always one answer leads to another question.
My current workflow uses Adobe Bridge, ACR and Photoshop CS6. However I will shortly be moving to Lightroom which I understand uses a variation on Prophoto colour space but with a gamma of 1.0. Is that colorspace supplied with the software as an icc/icm file that I can use as the source for building custom printer profiles to print direct from light room?
Dave
-
When producing a printer profile in Argyll I am asked to supply a profile that the picture will be converted from (eg ARGB) in order that the perceptual rendering will be correct. Why is this, and if it is needed why did X-rites i1 match, the software I used to use, not ask for the same?
Some information about this is here (http://www.argyllcms.com/doc/iccgamutmapping.html).
Short answer - to be able to do actual gamut mapping, rather than non-specific compression or clipping.
Longer answer - to be able to precisely map one gamut to fit inside another, you need to know what the gamuts are. When you are making a display or output profile, you know what one of the gamuts is (the output), but you know nothing specific about the other. Hence the need to specify it.
When one supplies the requested picture, does the mapping software examine the gamut of colors within the image or the gamut of the color space (container for the image)? If the latter, one would not really need a picture, but merely a reference to the color space.
Thanks,
Bill
-
Is that a new or made up term?
It's made up in the sense that I use it to refer to perceptual intent rendering that is reversible or has deterministic colorimetric rendering. For instance, if I like the perceptual rendering and want to be able to reproduce that at some future time or using a different printer I'll to an AtoB using RC and save the rendered image. Then, just a simple RC print will make the same highly consistent perceptually rendered prints. Works great unless you are printing to a smaller gamut like going from glossy to matte.
-
As always one answer leads to another question.
My current workflow uses Adobe Bridge, ACR and Photoshop CS6. However I will shortly be moving to Lightroom which I understand uses a variation on Prophoto colour space but with a gamma of 1.0. Is that colorspace supplied with the software as an icc/icm file that I can use as the source for building custom printer profiles to print direct from light room?
Dave
No need. All working space gammas are converted to gamma=1 before they go to the PCS profiles use. I made a gamma=1 version of Adobe RGB(1998) and ProPhoto RGB and use it when I want to look at the RGB channels in a linear luminance sense. Mostly I use that when checking gray scale reflectance accuracy. Useful quick checking for lens glare or accidental conversion when one wanted scene referenced conversion. I.e., linear v S-curve. Not something I often use but can sometimes be handy. If I'm looking at an 18% gray I'd like it to read 18% instead of somewhere in the middle of the working range. I can't think of a use in normal situations.
-
On the i1match software - there was not even a slider, although I did use a "hack" given by Eric Chan a few years ago that allowed 3 variations on the perceptual intent.
Sorry, I wasn't totally clear. The settings I referred to were from i1Profiler.
-
It's made up in the sense that I use it to refer to perceptual intent rendering that is reversible or has deterministic colorimetric rendering.
Thanks, it's what I suspected.
-
Your bias and prejudice that Perceptual rendering isn't appropriate for you has been made clear more than once. The idea that there is no merit in any perceptual renderings from all products for all users is to be kind, hogwash. Again, profiles know nothing about color in context. I asked you in another thread why photographers shouldn't be given a choice in color rendering in E6 file (Velvia vs. Ektachrome as an example) which is no different than a Perceptual mapping of colors, you ignored that question. IF you need a colorimetric reproduction, Perceptual isn't for you. Yet many image makers desire pleasing color and that's exactly what a Perceptual rendering attempts, repeat, attempts to provide and not all are created equally. If you're quest is to argue with the author of ArgyllCMS he shouldn't be providing a Perceptual rendering in his product, I'm going to sit back and really enjoy that debate. :o
I'm not biased against Perceptual and use it all the time for printing most of the pictures I take since the printer profile maker's idea of what looks good is usually acceptable. And I don't usually care that much whether they can be reproduced exactly in the future. If I do, it's easy enough to achieve that through reverse rendering using Relative Colorimetric into Adobe RGB and saving the file for that future case.
What I don't like about Perceptual is that it is ill defined, varies between vendors and settings, and requires that extra step in the last paragraph if I want to achieve future reproducibility.
If I'm putting much work into a photo, I'd rather tweak the tone curves and colors in Photoshop and use RC.
-
My current workflow uses Adobe Bridge, ACR and Photoshop CS6. However I will shortly be moving to Lightroom which I understand uses a variation on Prophoto colour space but with a gamma of 1.0. Is that colorspace supplied with the software as an icc/icm file that I can use as the source for building custom printer profiles to print direct from light room?
That's simply the underlying processing color space. You don't have to really address it at all. In LR, Melissa RGB is provided for the Histogram and numbers, that's ProPhoto RGB primaries with a 2.2 TRC (it's actually got a slight 'bump' down in the shadows like sRGB). WHY they did this is beyond me. If the time comes you want to know the actual numbers and histogram, setup a soft proof (type S key), that's what you'll get when you render the raw into that color space.
-
What I don't like about Perceptual is that it is ill defined, varies between vendors and settings, and requires that extra step in the last paragraph if I want to achieve future reproducibility.
Well the same could be said of RelCol. I provided an example of two profiles for the same device that produced hugely different output with the RelCol table. Everyone's color engine is different. Not all profiles, tables and results are equal.
-
When one supplies the requested picture, does the mapping software examine the gamut of colors within the image or the gamut of the color space (container for the image)? If the latter, one would not really need a picture, but merely a reference to the color space.
Hi Bill - Argyll asks for a source colour space -rather than a picture - when building a profile for output.
Sorry, I wasn't totally clear. The settings I referred to were from i1Profiler.
No worries Andrew - I did get that. i1match was even more restricted.
In LR, Melissa RGB is provided for the Histogram and numbers, that's ProPhoto RGB primaries with a 2.2 TRC (it's actually got a slight 'bump' down in the shadows like sRGB).
I'll supply that to the Argyll CMS when building the profiles to print.
Thanks all - I'm learning a lot here
Dave
Dave
-
I'll supply that to the Argyll CMS when building the profiles to print.
You can easily build a variant of ProPhoto RGB with a 1.0 simplified gamma in Photoshop's Color Settings itself. But I'm not sure you need to, best get feedback from Graeme. If all his software needs is the gamut of what you'll eventually render (into ProPhoto RGB), then ProPhoto RGB should work. As to the 'colors' that don't exist in ProPhoto RGB, not sure how this will all pan out.
-
Well the same could be said of RelCol. I provided an example of two profiles for the same device that produced hugely different output with the RelCol table. Everyone's color engine is different. Not all profiles, tables and results are equal.
Yes, I've seen broken profiles too. So what. Any compliant profile renders in-gamut colors via RelCol quite well. Out of gamut colors have to be mapped somewhere to the gamut boundary that is closest in some sense but the way vendors do that varies.
The same cannot be said of Perceptual which changes tone and colors and, since most images have most of their colors in-gamut this can be an issue.
-
Yes, I've seen broken profiles too.
Broken? How would you prove that? Again, not all profiles or rendering intents are created equally. And the Perceptual rendering is fair game to use after soft proofing the image in context and deciding as the image creators, you prefer that rendering. Velvia isn't better than Ektachrome, it's different and only better IF you subjectively prefer it.
-
Broken? How would you prove that? Again, not all profiles or rendering intents are created equally. And the Perceptual rendering is fair game to use after soft proofing the image in context and deciding as the image creators, you prefer that rendering. Velvia isn't better than Ektachrome, it's different and only better IF you subjectively prefer it.
Give me a break. RI is well defined in gamut. 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. 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.
-
You can easily build a variant of ProPhoto RGB with a 1.0 simplified gamma in Photoshop's Color Settings itself
I'd forgotten you could do that :D . Must be my age - now re-learning as well as leaning !
Dave
-
Give me a break. RI is well defined in gamut. 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. 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.
IF you believe that all profiles using a RelCol intent produce the same or even similar results, you need to test more than one profile package. Here's the same measured spectral data sent to two packages (Copra and i1Profiler) and the differences in the two (using Apply Image>Subtract) from a RelCol conversion. Yes I can get more specific with dE values but the point is, not all RelCol is equal!
Which is broken?
-
IF you believe that all profiles using a RelCol intent produce the same or even similar results, you need to test more than one profile package.
What part of what I wrote do you not understand? I have pointed out that correct profiles can and do render out-of-gamut colors differently. They map those colors to gamut boundaries based on whatever they think appropriate. It's not specified by the ICC. I have also pointed out what I have determined to be a bad profile. Not just bad looking but a profile that wasn't made correctly which is defined only in AtoB1 and BtoA1, aka RelCol. My standard profiles are currently made with PM5 and I1Profiler. Both do a fine job with in-gamut colors using RelCol.
Yes I can get more specific with dE values but the point is, not all RelCol is equal!
Please do. As I said, I've seen bad, not just ugly, profiles that were not made based on ICC requirements. Of course that was looking at RelCol which is well defined by ICC for in gamut colors.
-
Here's the same measured spectral data sent to two packages (Copra and i1Profiler) and the differences in the two (using Apply Image>Subtract) from a RelCol conversion.
Please supply the two profiles and I'll tell you which is bad. It's not rocket science.
-
What part of what I wrote do you not understand?
I guess this part: AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always.
My standard profiles are currently made with PM5 and I1Profiler. Both do a fine job with in-gamut colors using RelCol.
But accurately, colorimetrically, always? I suspect not.
-
Here's a MacBeth in sRGB, the difference in RelCol between the two profiles (again, not the same).
-
Here's a MacBeth in sRGB, the difference in RelCol between the two profiles (again, not the same).
And a dE report (notice max dE?)
--------------------------------------------------
dE Report
Number of Samples: 169000
Delta-E Formula dE2000
Overall - (169000 colors)
--------------------------------------------------
Average dE: 1.07
Max dE: 3.01
Min dE: 0.04
StdDev dE: 0.63
Best 90% - (152099 colors)
--------------------------------------------------
Average dE: 0.95
Max dE: 1.93
Min dE: 0.04
StdDev dE: 0.54
Worst 10% - (16901 colors)
--------------------------------------------------
Average dE: 2.15
Max dE: 3.01
Min dE: 1.93
StdDev dE: 0.17
--------------------------------------------------
-
I guess this part: AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always.But accurately, colorimetrically, always? I suspect not.
You are wrong. 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. My prints that are in gamut match within the ability of people being able to tell that two, side by side, prints were made with different printers*. Or PM5 v I1Profiler for that matter.
*With the exception of artifacts like bronzing from specular reflection. Illuminated only at an angle that doesn't reflect back to viewer, they match. And they should match.
-
You are wrong. Accurate, reproducible color is extremely important to me. I check RelCol accuracy using a spectrophotometer
I suggest you check with your actual ICC profiles as I just did. ;)
Sorry if the reality of differences in RelCol in differing packages (from the identical spectral data) is ruining your life.
-
I check RelCol accuracy using a spectrophotometer.
What Spectrophotometer would that be, since you brought that into the discussion?
-
And a dE report (notice max dE?)
--------------------------------------------------
dE Report
Number of Samples: 169000
Delta-E Formula dE2000
Overall - (169000 colors)
--------------------------------------------------
Average dE: 1.07
Max dE: 3.01
Min dE: 0.04
StdDev dE: 0.63
Best 90% - (152099 colors)
--------------------------------------------------
Average dE: 0.95
Max dE: 1.93
Min dE: 0.04
StdDev dE: 0.54
Worst 10% - (16901 colors)
--------------------------------------------------
Average dE: 2.15
Max dE: 3.01
Min dE: 1.93
StdDev dE: 0.17
--------------------------------------------------
Obviously not the result of a spectro measurement. That would be useful to see which is most accurate.
Looks like a report of the entire gamut accuracy consistency using BtoA1 andAtoB1 processing of a print image. What print image? Was that the ColorChecker image? If so, why not just measure the printed patches with a spectro to compare the profile accuracies? The larger dE2k values cluster around the gamut boundaries. Can't tell anything other than the profiles are slightly different. Unless the White Point was shifted, which can be noticeable, I don't believe any RelCol, in gamut print with those numbers, would be very easy to discern at all.
-
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!
-
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.
-
I have a I1 Pro, and I1 Pro uv cut, and an I1 Pro 2.
Mine's better ;D
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....
-
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.
-
Mine's better ;D
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.
-
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 (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.
-
http://www.digitaldog.net/files/2014PrinterTestFileFlat.tif.zip (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.
-
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.
-
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!
-
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.
-
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. 8)
-
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?
-
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.
-
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.
-
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):
-
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.
-
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.
-
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.
-
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.
-
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 (https://en.wikipedia.org/wiki/Overfitting).
-
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.
I don't like the changes re monitors but can understand the rationale. In general people don't understand why prints, in general, have lower Dmax than monitors and this causes a lot of folks to complain about washed out looking prints compared to what they see on the screen. Perceptual intent is designed to somewhat offset this by increasing contrast.
OTOH, V4 specs do clarify RI and require it to be measurement based. Of course instrument and printer variability are significant factors limiting how close RI comes to fulfilling the goals. I've see some profiles that rendered RI to scale the black point. In some cases I've seen a dE of 10 around L30 or so between what is printed or reflected in AtoB1. Apparently V2 specs have enough wiggle room that this is allowed though most of the V2 profiles I've looked at do not do this. This makes them useless for Absolute I the clear goal of which is to render a specific color reasonably accurately so long as it is within the printer's gamut range. It's rather pathetic to see a matte patch print in Absolute that renders a requested L25 as L35. Both PM5 and I1Profiler will render it within 1 dE and usually around .5dE.
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 (https://en.wikipedia.org/wiki/Overfitting).
Ditto that. One of the functions of smoothing in generating interpolation tables is to look over many nearby patch colors and create LUTs that best re-create the desired color. This can interact with the CMM which may use something more than just a linear fit - or not. And the number of LUTs can be increased which will provide a better match using linear interpolation if the printer curves have larger second derivatives.
In fact there are some printers where the best results I've had were using a relatively small number of patches, down to 480 or so, due to very high gradient changes. Higher numbers of patches produce worse profiles on these beasts. I had to do this to get reasonable results from a laserjet. Generally much less a problem on the printers today than 10 years ago. They seem to have made significant progress in print gradient smoothness.
-
Graeme
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.
Thanks for the explanation - very helpful.
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
I agree - and I like to keep things simple. That said - I also like the idea of having the option to build something specific if faced with a really awkward image to print. As an example - I kept marine tropical fish and corals - the combination of marine LED lighting and coral colours resulted in some image colours being captured that were well outside the gamut of my printer.
All - thanks for the input and discussion - I raised the original question to enhance my understanding and the thread is certainly helping that.
Dave
-
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.
It's not better, it's far worse. After pointing this fact out to you, I'm shocked you still don't understand how flawed your methodology and thus conclusions are about all this!
I illustrated the fact that measuring isn't necessary and introduces noise into the data. That you don't have a way to build two profiles with same spectral data illustrates you don't understand all the unnecessary variables into evaluating this 'issue' that I have eliminated. So I guess I'll have to discuss this as if you're a novice: You have two profiles. Both built using exactly the same data and the ONLY difference is the software that built them. You take a set of RGB values in any RGB working space you desire. Ideally a real image something like the Macbeth but doesn't matter to clarify this simple process in your mind. You have a set of RGB values, you convert them through each profile. You get NEW RGB numbers. Still with me Doug? You produce a dE report in ColorThink Pro. This is exactly what I did to illustrate the differences (average dE over 1, max just over 3) with two profiles passing data through their RelCol tables to produce new numbers.
Now you say you want to move those pristine numbers through a driver, make ink hit paper, then measure it. And you formed the opinion this is better? Are you certain Doug? Because all I see is some desperate attempt to spend more time, introduce more noise into the data that's totally unnecessary. Maybe it will produce values you feel are closer to your unproven idea that two profiles using a RelCol conversion will produce the same results. That's wrong to believe just as your methodology to test this is wrong.
I've gone out of my way to reduce anything in the testing that will pollute the results. Sorry if you don't like the science and if so, knock the methodology, not the numbers that clearly show that the two profiles made from the same measurement data don't produce the same colorimetric values through their RelCol tables.
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.
All textual digressions that are unnecessary and will not produce any better results.
After all, it's the print that counts.
NO, it's what the profile produces that counts. Try to get that into your head. We're talking about how two profiles convert RGB values through a RelCol table, NOT what you measured after introducing false 'data' into a process!
I'm curious what color is producing the dE2k max of 3. That's outside what I normally see.
Because what you normally see is viewed though flawed testing! You can't by your own admission even build two profiles with same measurement data!
Be happy to look at how your two profiles render the CC image if you want to share them.
Until you can warp your head around sound testing, it's rather pointless. You're just wasting your time, my time and anyone else here who's considering the unproven statement (just the opposite): AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always.
-
More proof of evidence, this time using the fabric image from Gamut Test File and running that through the same two profiles built identically other than the software used.
Here's your visual dE difference thanks to ColorThink. And the dE report from a mere 220,000 colors (device values) using Extract ALL colors in CTP.
As I had said, using a Macbeth in sRGB was being kind....
Doug, think you can see a dE of 9?
--------------------------------------------------
dE Report
Number of Samples: 220000
Delta-E Formula dE2000
Overall - (220000 colors)
--------------------------------------------------
Average dE: 1.11
Max dE: 9.37
Min dE: 0.01
StdDev dE: 0.90
Best 90% - (197999 colors)
--------------------------------------------------
Average dE: 0.87
Max dE: 2.30
Min dE: 0.01
StdDev dE: 0.47
Worst 10% - (22001 colors)
--------------------------------------------------
Average dE: 3.29
Max dE: 9.37
Min dE: 2.30
StdDev dE: 0.93
--------------------------------------------------
--------------------------------------------------
-
More proof of evidence, this time using the fabric image from Gamut Test File and running that through the same two profiles built identically other than the software used.
Here's your visual dE difference thanks to ColorThink. And the dE report from a mere 220,000 colors (device values) using Extract ALL colors in CTP.
As I had said, using a Macbeth in sRGB was being kind....
Doug, think you can see a dE of 9?
--------------------------------------------------
Max dE: 9.37
Holy moley.
A dE2k of 9 is a very visible difference. Even allowing for the colors to be at the gamut boundary that's a really big difference. Something's broken. I've never gotten a print with colors that far off. It's probably one of the profiles simply has some very bad math creating the 3D LUTs. Almost certainly at a gamut edge. That's the region most interpolation algorithms have the most error. It's also possible it's something like special handling of OBs. Some profiling software "adjusts" for this differently than others but use the same spectral data. I have no idea what your profile vendors are doing.
Still a dE2k of 9 is a strong indicator something is amiss. Unless the difference can be explained by reasons stated above I wouldn't use either of those profiles because there is no way of knowing which is better and their is strong evidence that one, at the very least, is quite flawed.
Try printing the color that shows a dE of 9 using both profiles and see which one is broken. It's the only way to tell where that dE is coming from.
-
Holy moley.
A dE2k of 9 is a very visible difference. Even allowing for the colors to be at the gamut boundary that's a really big difference. Something's broken.
No, only your reaction to the data ;D
Do you realize that that is ONE patch (device value) of 200,000? Examine the report again. Examine the average, max and min dE values and consider that we're talking about one color, versus one other among 200,000! It's why colorimetry tells us one thing and viewing an image within context tells us something different. Colorimetry and the dE testing is about color perception. It is not about color appearance. It can be subjective or colorimetric (the only way we should define color accuracy in dE) or both.
I've never gotten a print with colors that far off.
You may have, you just didn't do the testing correctly as I've attempted to point out repeatedly! It's very possible that one of 200,000 or one of a million solid colors were indeed a dE of 9 off when you compare 1 sample to 1 other, which is what the report illustrated (max dE 9). You cannot measure a print and come up with that kind of data. None the less, the data is still colorimetrically sound.
Try printing the color that shows a dE of 9 using both profiles and see which one is broken
A print where 1 pixel is off or 10,000? There's a difference which is what I'm attempting again to teach you. It illustrates how your testing (printing and measuring) isn't valid expect for a difference you can see on a print. We're not talking about that, we are talking about colorimetry and differences using deltaE which is a comparison of simply two samples!
This boils down to what you're trying to test! In this discussion, it's the false concept from false testing that suggests: AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always. YOU brought up colorimetry in that sentence Doug.
Colorimetry and the dE testing is about color perception. Of one set of solid colors. It is not about color appearance. The reason why viewing a print is more valid than measuring it is because measurement is about comparing solid colors. Color appearance is about evaluating images and color in context which measurement devices can't provide. Decide which you're talking about, maybe we can come to an agreement. But in terms of colorimetry, something you brought up, suggesting the report tells us a profile is 'broken' because you've never measured a print and seen this value appear, illustrates you're talking apples and oranges. It's why I keep telling you that measuring a print when what we're debating, the Colorimetry of what a profile produces, pixel by pixel is so flawed.
It's the only way to tell where that dE is coming from
No, just the opposite! Do you now understand why? The dE of 9 is coming directly from the differences in the two profiles, something you continue to refuse to accept.
-
Do you now understand why? The dE of 9 is coming directly from the differences in the two profiles, something you continue to refuse to accept.
Of course the dE of 9 is coming from the two profiles. It's the dE between the two Lab colors that each profile, as interpolated from the 3D LUT AtoB1 tables, indicates. It's a rather large error. If a large portion of the image consisted of that color with that large a dE then images printed using each of the two profiles could look quite different. If the vast majority of image pixels had a low dE then it probably wouldn't be noticed. That's why a histogram rather than just a limited set of stats, is more useful.
-
Of course the dE of 9 is coming from the two profiles. It's the dE between the two Lab colors that each profile, as interpolated from the 3D LUT AtoB1 tables, indicates. It's a rather large error. If a large portion of the image consisted of that color with that large a dE then images printed using each of the two profiles could look quite different. If the vast majority of image pixels had a low dE then it probably wouldn't be noticed. That's why a histogram rather than just a limited set of stats, is more useful.
I give up. You still can't seem to connect the dots about colorimetry of two profiles and output to a print from the profile. Or that the idea: AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always, is incorrect. I've proven it, you can't.
-
I give up. You still can't seem to connect the dots about colorimetry of two profiles and output to a print from the profile. Or that the idea: AtoB1 tables are supposed to accurately colorimetrically represent the printed color. Always, is incorrect. I've proven it, you can't.
No, you have proven no such thing. The only thing that can be said with certitude about them is that they will soft proof that color differently with a dE2k of 9 using the two profiles made with exactly the same spectral data. If you think that's an acceptable level of soft proofing, fine, but the entire point of soft proofing is to show you on your monitor what a print, properly illuminated, will look like. You just have to hope that there aren't large numbers of colors that are over dE2k of 3 or so. I've seen far worse profiles. I try not to use them.
But let's get on to the real world, the color errors in printing your colorchecker image. The 24 patches all have identical Lab colors except for a small amount of variation, typically well under .1. It's possibly a small amount of dithering done during conversion from some other space like aRGB.
So I printed the CC image on Epson Ultra Prem. Glossy but using a 9500 II, then spot read each of the patches with PatchTool. I used I1 Pro 2, XRGA which was also what was used making the profile. Compared against the image, average dE2k was .7, max dE2k was 2.8, which was the white square. Next worse was the dark blue at dE2k of 1.2. The others were under 1.0.
-
But let's get on to the real world, the color errors in printing your colorchecker image. The 24 patches all have identical Lab colors except for a small amount of variation, typically well under .1. It's possibly a small amount of dithering done during conversion from some other space like aRGB.
That's in your imagined world of printing and measuring which isn't the same as inspecting the RGB values the profiles produced. I told you why. Graeme told you why. Again, I'm sorry the facts are ruining your reality. Got nothing to do with soft proofing, the colorimetric values I produced where from RGB values from a RelCol conversion. Those ARE the values the profiles produce, not some measured print with all nature of noise. It's kind of shocking you still don't seem to understand that fact.
So I printed the CC image on Epson Ultra Prem. Glossy but using a 9500 II, then spot read each of the patches with PatchTool.
Pointless and filled with data errors. But then as I suspected, your methodology was built to produce a result you wanted, not that was colorimetrically accurate.
-
It's possibly a small amount of dithering done during conversion from some other space like aRGB.
Nope, sorry. There's no dither in high bit images when converting. Photoshop's Color preferences clearly indicate this if you'll take the time to examine them...
-
That's in your imagined world of printing and measuring which isn't the same as inspecting the RGB values the profiles produced. I told you why. Graeme told you why. Again, I'm sorry the facts are ruining your reality. Got nothing to do with soft proofing, the colorimetric values I produced where from RGB values from a RelCol conversion. Those ARE the values the profiles produce, not some measured print with all nature of noise. It's kind of shocking you still don't seem to understand that fact.Pointless and filled with data errors. But then as I suspected, your methodology was built to produce a result you wanted, not that was colorimetrically accurate.
Utter nonsense. The process was designed to see how colorimetrically accurate my printing workflow would print your colorchecker image using my standard profiles. The results are very good, excluding the white patch. Out of gamut colors should be excluded, of course, as they will have higher dE's by definition.
How well do you print defined colors? Or do you ever?
Image (Lab): 37.65 15.58 16.57 actual print (Lab): 37.28 15.42 17.11 dE2k:0.54
Image (Lab): 61.96 35.64 61.75 actual print (Lab): 62.03 36.26 63.98 dE2k:0.63
Image (Lab): 28.61 19.61 -53.73 actual print (Lab): 29.71 18.43 -54.05 dE2k:1.24
Image (Lab): 96.08 0.52 0.50 actual print (Lab): 95.94 -0.03 3.42 dE2k:2.84
Image (Lab): 66.67 16.57 18.58 actual print (Lab): 66.88 16.56 19.22 dE2k:0.45
Image (Lab): 39.99 9.55 -42.69 actual print (Lab): 40.94 9.77 -42.10 dE2k:0.94
Image (Lab): 55.28 -38.65 33.63 actual print (Lab): 55.44 -39.36 34.43 dE2k:0.36
Image (Lab): 81.16 0.51 0.50 actual print (Lab): 81.60 0.84 1.21 dE2k:0.88
Image (Lab): 50.19 -4.50 -21.60 actual print (Lab): 50.45 -5.04 -20.40 dE2k:0.78
Image (Lab): 51.76 48.70 17.57 actual print (Lab): 51.70 49.40 18.69 dE2k:0.56
Image (Lab): 41.96 56.70 29.63 actual print (Lab): 41.99 57.66 30.18 dE2k:0.28
Image (Lab): 66.65 0.52 0.50 actual print (Lab): 66.60 0.70 0.44 dE2k:0.28
Image (Lab): 43.13 -13.55 22.60 actual print (Lab): 42.52 -13.37 21.96 dE2k:0.65
Image (Lab): 30.98 21.57 -20.59 actual print (Lab): 30.90 20.88 -19.56 dE2k:0.57
Image (Lab): 81.56 5.53 78.79 actual print (Lab): 82.08 5.26 79.53 dE2k:0.43
Image (Lab): 51.75 0.52 0.49 actual print (Lab): 51.73 0.89 0.33 dE2k:0.56
Image (Lab): 55.29 9.57 -24.62 actual print (Lab): 55.64 9.39 -23.44 dE2k:0.75
Image (Lab): 72.15 -22.59 57.73 actual print (Lab): 72.10 -22.50 57.95 dE2k:0.10
Image (Lab): 51.36 50.70 -12.55 actual print (Lab): 51.93 50.51 -13.02 dE2k:0.61
Image (Lab): 36.07 0.48 0.51 actual print (Lab): 36.21 0.64 0.34 dE2k:0.31
Image (Lab): 70.59 -31.63 0.50 actual print (Lab): 70.76 -31.69 1.27 dE2k:0.53
Image (Lab): 72.94 19.61 68.77 actual print (Lab): 72.94 20.25 68.58 dE2k:0.41
Image (Lab): 49.79 -27.59 -28.63 actual print (Lab): 50.57 -27.64 -28.22 dE2k:0.80
Image (Lab): 20.38 0.52 0.48 actual print (Lab): 20.38 0.85 -0.35 dE2k:0.95
-
Nope, sorry. There's no dither in high bit images when converting. Photoshop's Color preferences clearly indicate this if you'll take the time to examine them...
Ok, so the color patches just have small variations in them. These are tiny ones. Just surprised they are there.
-
Just surprised they are there.
Based on so many of your ideas, and the actual facts presented, I'm not surprised you are surprised! ;D
“There are two ways to be fooled. One is to believe what isn't true; the other is to refuse to believe what is true.”
-Søren Kierkegaard
-
Out of gamut colors should be excluded, of course, as they will have higher dE's by definition.
What out of gamut colors (other than white)?
More assumptions on your part, the sRGB Macbeth image fits fully inside the printer profile:
-
Based on so many of your ideas, and the actual facts presented, I'm not surprised you are surprised! ;D
“There are two ways to be fooled. One is to believe what isn't true; the other is to refuse to believe what is true.”
-Søren Kierkegaard
Did you miss breakfast or something?
I didn't add dithering so it has nothing to do with Photoshop.
The small variations in 16 bit files didn't get their by accident. Noise is intrinsic in scanning and photography but these noise levels are far below those produce by pixel shot noise. And I rather doubt they were put their pixel by pixel. It's common when a small amount of dithering is added. It's just that I didn't add it. The low noise level is in your image.
-
I didn't add dithering so it has nothing to do with Photoshop.
And I never said you did! I pointed out the facts of which you seem to have difficulty accepting or understanding that the data I provided had not a lick of dither! In fact the data provided you still can't wrap your head around are values produced by each profile without any noise or measurement errors I've tried to point out your methodology produces.
The small variations in 16 bit files didn't get their by accident. Noise is intrinsic in scanning and photography but these noise levels are far below those produce by pixel shot noise. And I rather doubt they were put their pixel by pixel. It's common when a small amount of dithering is added. It's just that I didn't add it. The low noise level is in your image.
You're going down another rabbit hole of your own creation. If you want to look into noise that affects data, it's been proven and agreed upon by another poster** that you are the one introducing the noise by measuring a print when that isn't necessary at all. The two profiles produced colorimetric values from actual pixels that were directly compared with as little variations possible! Even from the same measured data you by your own admission can't produce. Again, you're just wasting my time. Your tests are flawed, it's been pointed out too many times now. My methods are sound and you've completely failed to point out any issues with that data; you just ignore them! The two profiles produced 220,000 values that were directly compared. The results are clear. IF you don't want to accept them, fine.
**http://forum.luminous-landscape.com/index.php?topic=106407.msg875857#msg875857
I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it;but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind.
-Lord Kelvin
-
What out of gamut colors (other than white)?
More assumptions on your part, the sRGB Macbeth image fits fully inside the printer profile:
No, you are the one making assumptions. The colorchecker image's white square is outside the printer/paper gamut since the paper's white point is Lab (97.3, 1.86, -7.0).
As you fully well know but failed to consider, Epson Ultra Premium Glossy Photo Paper, which I earlier stated I used, has a great deal of OBs resulting in an large white point shift. As a result, the profile/printer/paper combination is unable to print the requested color, Lab (96.08,.52,.50) though it succeeded somewhat in more than halving the "b*."
-
The colorchecker image's white square is outside the printer/paper gamut since the paper's white point is Lab (97.3, 1.86, -7.0).
Perhaps English is your 2nd language? Read what I wrote: What out of gamut colors (other than white)?
As you fully well know but failed to consider, Epson Ultra Premium Glossy Photo Paper, which I earlier stated I used, has a great deal of OBs resulting in an large white point shift. As a result, the profile/printer/paper combination is unable to print the requested color, Lab (96.08,.52,.50) though it succeeded somewhat in more than halving the "b*.
The profile plotted and the colorimetry reports I proved are not Ultra Premium Glossy Photo Paper.
-
Perhaps English is your 2nd language? Read what I wrote: What out of gamut colors (other than white)?
When you said this:
What out of gamut colors (other than white)?
More assumptions on your part, the sRGB Macbeth image fits fully inside the printer profile:
Apparently you were referring to the image when you ran it through your two profiles. I mistook "the" to refer to a profile in the singular and presumed you were referring to my printer profile and the results I was discussing and that somehow it was inside the gamut after clipping to sRGB. I didn't convert it to sRGB.
The profile plotted and the colorimetry reports I proved are not Ultra Premium Glossy Photo Paper.
Ah, back to your two profiles that display poor profile programming. What exactly does that prove other than one or both profiles are defective? And they obviously are. If they can't run the extremely color limited sRGB clipped colorchecker image through them without getting a max dE2k of 3 from exactly the same spectral data thus eliminating instrumentation variables there is something seriously flawed between the two.
But thank you for agreeing that the white patch is out my printer/paper gamut. So that leaves the actual results, added noise and all :) , as:
Max dE2k: 1.24,
Ave dE2k: .6
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.
The real question is how well do these profiles that show a difference dE2k of 3 on a mere colorchecker image actually print it? Mine gives dE2k max of 1.24 and an average over the patches of .6. Does either of yours come close?
-
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
-
Doug, do you own a copy of ColorThink Pro?
-
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.
-
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
-
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.
-
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.
-
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
-
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 (http://www.argyllcms.com/doc/ArgyllCMS_arts_tag.html) may be of interest.
-
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.
-
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.
-
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 :D
Dave
-
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
-
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.
-
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.
-
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.
-
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