Color management myths and misinformation video

[MHMG]

I hesitate to wade into the whole "my color space is bigger than your color space" debate, but here goes: Color management is deeply rooted in CIEXYZ or CIELAB as the underlying backbone of color translation. I have no problem with that at all. However, image reproduction quality when comparing original source color to output color is also overwhelmingly expressed in terms of various flavors of delta E, and delta E is of course a vary useful metric for many types of color discrimination tasks like matching paint or textile colors. However, both delta E and total color gamut estimations fall flat on their faces when it comes to properly characterizing tone reproduction fidelity.  A large part of the reason is that delta E lumps lightness with hue and chroma discrimination and therefore works well only when evaluating relatively small differences in total color value (i.e hue, chroma, and lightness).

Because lightness changes are being combined with hue and chroma and a before and after comparison is being made only in the same spot on the image, delta E gives no merit to changes in visual contrast. Try this following exercise in any color space of your choice. Take a monochrome image with full gray scale, and with the PS info tool set to a LAB readout and the curve selection tool put a "kink" in the curve such that the L* values get compressed or expanded by about 5 units in a small region of the curve. That move will create an induced delta E maximum error of 5 in the image. Now take the same image and rather than making a kink in the middle of the curve, make a gentle curve change that also induces a max L* value change of 5 anywhere along the curve. So, both image "corrections" cause similar Delta E error and none are huge in terms of delta E.  Which image retains the original image quality best? Are they comparable as the delta E numbers would suggest.  If you try this test, you will soon figure out that bunching up tones in an image, even when relatively small in terms of delta E variations (and when all affected values were never out of gamut or taxing total color gamut in any way) can play havoc with overall image quality, but delta E evaluations cannot tell you that.  A print's visual contrast is critical to image quality, and thus it's very important to realize that all of the color spaces, sRGB, aRGB, pro photo RGB, etc encompass exactly the same tonal range. Though the tone ramps may differ the total range from black to white is the same. Hence, all of the RGB working spaces are equally capable when it comes to mapping the critical visual contrast range in the final output.

Similarly, delta E rates color for color sake only. It does not properly weight color errors for color in context of image information. Hence, high chroma color errors are treated as if they are as important as low chroma color errors which is true only if we consider color for color's sake. Yet in a true photographic image the low chroma colors rather than the high chroma colors'  accuracy in the final reproduction dictate how we perceive color balance in the image. The human observer subconsciously identifies low chroma areas in the scene to evaluate scene lighting conditions and adapt to them. Hence, gray and near gray color accuracy needs to be much more precise than high chroma color accuracy, and thus even lowly sRGB is capable of representing hue and chroma of those critical color values in the image.  So, compressing or even clipping the high chroma colors is not nearly as awful as it sounds, unless of course the remapped color values screw up...wait for it... the lightness values in a way that then messes up tonal contrast relationships in the image.

Color balance and tonal contrast are thus so essential to perceived image quality in the reproduction and yet incorrectly tracked or not tracked at all with delta E metrics.  This realization took me time to arrive at and a few years of research to come up with a color and tonal accuracy metric that worked better for real images as opposed to mere color matching exercises that work fine in other paint and textile applications for example. I invented a new metric I call the I* metric (I* standing for information content)). There is information about it on my website and it was published as open source several years ago in an IS&T technical conference proceedings (the published article is available on the AaI&A website). All that said, I thought by now that other color scientists, especially those working on graphic arts industry print quality standards would find some interest in this research. Hasn't happened yet. Maybe never , but the principles embodied in the I* metric  are fundamental ones that must be accounted for even if someone else ultimately arrives at a better metric. Delta E is not it.

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

[Manoli]

If you have any aspirations to improve your photos and do any post processing on them, eg cropping, adjusting colour balance/exposure/generally getting the best from your camera, you're going to have to use some sort of image editor. Once you choose to do that you might as well just use RAW in the first place, then pass everything though a package like Lightroom/Aperture/Capture One and let that handle resizing and colourspace issues for online use ..

You can go bigger gamut to smaller but it is pointless to go the other way. Think of it as starting with a gallon container holding water. You can pour that into a quart container. But pouring a quart of water into an empty gallon container doesn't give you a gallon of water. So I would render from raw to the highest resolution your camera can produce, widest gamut (ProPhoto RGB), 16-bit, do all the work on that as your master image archive. Then you can size down the resolution and gamut for output to other needs like posting to the internet, slide shows etc.

• Always shoot RAW
• Get a wide-gamut monitor and a calibration system and use the latter at least 1x/month
• In software, always work in ProPhoto
• Make sure you have the right profile for your printer and paper
• Apply the profile in software or at the printer, never both
• Softproofing is your friend

Andrew,

Can't think of a more succinct explanation or better advice for a 'newb' than the above three posts.  If you want to succeed in getting your message across, keep it as simple and direct as possible - don't get drawn into the minutiae (if you're addressing the wider public).

Edit:
Apologies to Mark - this was typed just before I saw your post and was typed purely as a suggestion regarding the 'Gary Fong' thread. Not to be taken as a comment on your post above.

[Jim Kasson]

Color management is deeply rooted in CIEXYZ or CIELAB as the underlying backbone of color translation. I have no problem with that at all. However, image reproduction quality when comparing original source color to output color is also overwhelmingly expressed in terms of various flavors of delta E, and delta E is of course a vary useful metric for many types of color discrimination tasks like matching paint or textile colors. However, both delta E and total color gamut estimations fall flat on their faces when it comes to properly characterizing tone reproduction fidelity.  

Bravo, Mark!

I read An Introduction to the I* Metric. Revelatory. Do you have Matlab code available?

Jim

[MHMG]

Bravo, Mark!

I read An Introduction to the I* Metric. Revelatory. Do you have Matlab code available?

Jim

No, I don't have MatLab code for the I* metric, but it can be relatively easily programmed in Excel. Excel is how I generate the Aardenburg Lightfastness test reports. Yet I have never made a basic Excel spreadsheet for I* calculations available to others, in part because I'm duly embarrassed by my own Excel programming expertise (I get the calculations right, but the programming itself is far from clean and elegant), and in part because no one has ever asked. I did make some effort a few years back to peak the interest of other graphic arts professionals (i.e, some of those working on all the FOGRA and Gracol 7 stuff), but got absolutely no responses. Thus, no need arose to make a basic I* calculator available at the time. Perhaps it's time now.

I'll think about rewriting my light fade template to a more streamlined "before and after" I* calculator. It wouldn't take very long, and a simple I* calculator program in Excel would allow others to check some of these color gamut conversion theories with a more objective means of comparing source to destination color and tone fidelity. That said, it might also require perhaps some training on how to use I* in conducting these types of studies, and it's at that point where my further ability to evangelize I* starts to run into a time and money crunch.

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

[Rand47]

Andrew,

Can't think of a more succinct explanation or better advice for a 'newb' than the above three posts.  If you want to succeed in getting your message across, keep it as simple and direct as possible - don't get drawn into the minutiae (if you're addressing the wider public).

+1  Well said, Manoli.

[digitaldog]

Great post Mark. In terms of dE, and in the context of this discussion, is it useful in terms of evaluating what is and thus isn't visible when trying to decide if one color space with a fixed image does or doesn't contain more colors than the other? Or is it simply fruitless to even go there? Do you suppose ColorThink is using this metric in any way to produce the extraction of unique colors in the reports Bill and I produced?

[Jim Kasson]

No, I don't have MatLab code for the I* metric, but it can be relatively easily programmed in Excel. 

Mark,

Can I just use the formulae in this paper: http://wilhelm-research.com/ist/WIR_IST_2004_11_MMG_HW_DS.pdf

or is there something newer?

Thanks,

Jim

[MHMG]

Great post Mark. In terms of dE, and in the context of this discussion, is it useful in terms of evaluating what is and thus isn't visible when trying to decide if one color space with a fixed image does or doesn't contain more colors than the other? Or is it simply fruitless to even go there? Do you suppose ColorThink is using this metric in any way to produce the extraction of unique colors in the reports Bill and I produced?

Well, not to disparage delta E and software like Colorthink that have nice gamut volume functions and 3d color space graphing in any way because these tools can serve certain useful process control purposes, but what they don't do is graphically show how the PCS remapping and rendering intent choices affect the visual contrast relationships in the reproduction, and this is critical to how we perceive color and tone fidelity. Think of the color count and precision question this way: Take a printer that wants RGB input and internally converts to multi channels which generates the final color value calculations for that printer driver/ink/media combination and thus the total combinations of differentiable colors that this printer setup can produce. If we were to feed it an untagged RGB 8bit image containing every single RGB triplet of numbers (all 16million of them) in patches big enough to be read by our spectrophotometers (that's a lot of patches!) and also arranged in a nice visually appealing gradient field (some of Bill Atkinson's targets come to mind) we'd get "all she wrote" in terms of the unique printable colors for that system. Human observers would perhaps be able to distinguish up to 1 million of them at best as being perceptually different and probably far less than that due to the precision and gamut limitations of the printer. Note you could retry the experiment in 16 bit, and the observer might now see a few more differentiated colors but I'd wager other previously printable colors would get lost so the visually discernible total count would still probably end up about the same. Now assign sRGB and print through the newly generated printer profile. Hit the print button. then again but with the image assigned prophoto RGB.  If, hypothetically, the sRGB was ever so slightly bigger in every hue plane and along the entire L plane as the printer's output can produce and the printer profile was perfect, you'd again print every discernible color the printer can print. Ditto for prophotoRGB, but the visual shape of the color field would look greatly different between the two prints because the profoto tagged image would be forcing more patches toward the color plane boundaries of the printer. The images would thus look visually very different even though they would contain the same total number of discernible colors. More importantly, applying different rendering intents would change the shape or pattern of the color field, but again the printer would have printed the same discreet total number of different colors, merely higher counts of some colors over others, but total reproducible number of colors would be the same.

I hope I'm painting a clear picture here In this hypothetical instance we'd be making the same total number of visually discernible colors but more of some color values and less of others due to the remapping, hence the visual shape of the test pattern would look different. I* can track the tone and color accuracy and thus objectively quantify how visually different the overall pattern appearance was from the source file's visual color pattern, but delta E and gamut plots would not reveal this visual impact. Delta E would indicate that lots of errors were occurring and that if you separated all those colors so each before and after color pair could be individually observed side by side and thus out of the context of the image's actual visual pattern, then delta E would yield some estimate of individual color errors but the quantified result would have nothing to do with how we react to those color errors within the context of the color and tonal pattern geometry we expect in the reproduction when compared to the source image.

I just cited above a theoretical case where sRGB just enveloped the printer's total color space very neatly. In reality, neither sRGB nor aRGB fully envelop a printer/ink/media color space. sRGB will force some colors to be remapped harder while aRGB will force other colors to be remapped harder into the printer color space. Again, it comes down to how the choice of rendering intent combined with what colors and tones in the image are being remapped more aggressively in order to judge the fidelity of the reproduction. One absolutely needs a metric that can track visual contrast between neighboring image elements in the reproduction and also weight low chroma errors with more emphasis than high chroma color errors in order to begin to assess the perception of image quality.  Delta E wasn't designed for this task nor do potential color gamut volume calculations do this.

best,
Mark

[MHMG]

Mark,

Can I just use the formulae in this paper: http://wilhelm-research.com/ist/WIR_IST_2004_11_MMG_HW_DS.pdf

or is there something newer?

Thanks,

Jim

That's the one. There is a minor error in a part of one of the branching equations that will result in incorrect values when tone values go negative (ie. falsely inverted tonality). An absolute value sign was required in one part that got over looked despite myriad technical reads by colleagues and myself before publication. Anyway, by the time this absolute value needs to kick in to the actual calculation, the image reproduction is in such huge trouble that this math error in the published paper is of academic interest only.  Practically speaking, if you program the equations in that paper as they were published you will have a reasonably well behaved I* calculator, so I never bothered to republish. That said, contact me offline if you like, and I can point out where that absolute value sign is needed so you will end up with the a calculator that works like I calculate I* color and tone values today.

What the paper doesn't go into too much detail about is how to do good frequency sampling of an image to make better use of the power of the I* metric when the number of patches used in the calculation is limited, i.e. when to use lower sampling frequencies and when to use higher sampling frequencies and also how to practically make printed output to generate the necessary comparison color patches when trying to analyze printed output. If all one is doing is sampling digital input versus digital output, as in this discussion on RGB working spaces then image sampling to obtain the reference (before) versus comparison (after) LAB values is very easy. In fact, a good I* app could just as well sample every single color pixel in the image before and after the image editing or conversion process. That's not really possible with Excel due to row and column limitations. I don't use Matlab, so I don't know its capabilities, but I bet the Adobe guys and other savvy programmers could probably implement I* with total imaging processing power right down to the pixel level if they were motivated to do so.  I won't hold my breath for that, especially given the current level of industry interest in I* even though, all modesty aside, I personally feel the I* metric and this published paper is an important technical contribution to the field of color science. It sets forth key image appearance fundamentals for image quality that often times color scientists and color difference models totally overlook.


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

[MHMG]

In terms of dE, and in the context of this discussion, is it useful in terms of evaluating what is and thus isn't visible when trying to decide if one color space with a fixed image does or doesn't contain more colors than the other? Or is it simply fruitless to even go there? Do you suppose ColorThink is using this metric in any way to produce the extraction of unique colors in the reports Bill and I produced?

Hey Andrew, Sorry I answered your question before with a view towards the larger issue of usefulness of sRGB versus aRGB from a perspective of adding in the impact of printer output as well, but now that I've had another cup of coffee, I see you are asking about just the discernible differences that can exploited within these working color spaces. I don't know how Colorthink makes it's "unique color" calculation, but I think a simple experiment would tell you whether it is just summing up the total number of numerically different LAB values associated with all RGB triplets in the chosen image or if it's using combination theory to count how many pixel pairs actually generate a threshold delta E value greater than 1, for instance. Try taking your all white image, for example, that would generate only one unique color even if the image had, say, a total count of 100 all white (RGB =255,255,255) pixels in it. Next, take just one of those white pixels and change it's RGB triplet value by a large enough amount to generate a new LAB value that differs by 1 unit or more in any of the L*, a*, b* values returned in the info tool. That now guarantees the image has two unique colors whether counted in RGB or LAB numeric calculations by Colorthink, so Colorthink should return a unique count of two no matter what. Lastly, make a change to one more white pixel by an RGB triplet value  set to RGB=254,255,254. The ps info tool or the color pallet will show that L* a* b* is still the same 100,0,0 triplet meaning that the delta E difference in this RGB triplet from pure white is below a threshold of 0.5 delta E, thus not rounding off to a different LAB integer triplet value in PS. However, internally higher precision is being carried and Colorthink should pick up the numeric LAB difference. If Colorthink returns three unique values then it's simply counting unique numeric math values in the pixel RGB to LAB transformation without any regard for a delta E threshold. If it still returns only two unique colors, then it is probably using combination theory and looking for a delta E threshold value probably set to 1.0 which color difference theory says is a perceivable difference between two side-by-side colors. Would be cool if Colorthink allowed you to set your own threshold for this type of "unique color" analysis. Does it?

If I had Colorthink, I'd try this little test myself, but I don't, so I can't If Colorthink is indeed counting unique values with combination theory and a delta E threshold, then I think it's a fair way to assess the potential of an image in sRGB, aRGB, or ProPhoto to represent x number of uniquely discernible colors, but the arrangement of those colors and tones in each image and subsequent faithfulness to the original colors cannot be evaluated in this way, so all in all, it does become somewhat of an academic exercise that more often than not will get overshadowed by the quality of the image edits and the choice of the color field surrounding the image on display.

Actually, as I think about it more, if sRGB is vastly inferior to aRGB in terms of visual quality of the final rendered image, we should see major differences when exporting RAW image files that have been prepped on a wide gamut monitor to sRGB for use on a Web page, but I seldom see much of a color and tone hit to image quality. Typically, the surround image color the image will reside against has a much bigger impact on visual appearance than whether the image got rendered to aRGB versus sRGB.

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

[digitaldog]

Try taking your all white image, for example, that would generate only one unique color even if the image had, say, a total count of 100 all white (RGB =255,255,255) pixels in it. Next, take just one of those white pixels and change it's RGB triplet value by a large enough amount to generate a new LAB value that differs by 1 unit or more in any of the L*, a*, b* values returned in the info tool. That now guarantees the image has two unique colors whether counted in RGB or LAB numeric calculations by Colorthink, so Colorthink should return a unique count of two no matter what.

Great idea! I'm not sure if the test I just did is valid, I've had a few glasses of wine with dinner  .
In Photoshop I made a two pixel document IN Lab.
One pixel is Lstar 100/0/0. The other is Lstar 99/0/0.
ColorThink extracts two unique values which is kind of expected.
What is interesting is the Lab values it provides which is a tad different than Photoshop and may be a clue to what is going on with the report.

#1 100.00/-0.00/0.00 
#2  99.12/-0.00/0.00
ColorThink has more precision in the values than Photoshop.

Now I make a similar 2 pixel document in ProPhoto RGB. One pixel is 255/255/255, the other is set for 254/254/254. I use the pencil tool set for one pixel and click on that 2nd pixel.
ColorThink reports the white pixel as we expect, Lstar 100. The pixel that was set for 254/254/254 is reported as Lstar 99.73

Lastly I repeat the test but use a new 2 pixel document in sRGB. Again, with sRGB, I ask for 254/254/254, Photoshop reports that as Lstar 99.
ColorThink reports the white pixel as we expect, Lstar 100. The pixel that was set for 254/254/254 is reported as Lstar 99.65

Would be cool if Colorthink allowed you to set your own threshold for this type of analysis. Does it?

I see a preference for Unique Color Extraction: Ignore white (255/255/255) and Ignore Black (0/0/0) they are both off. There are options for different dE formula but only when comparing two color sets, they don't alter the extraction of the colors (altering dE formula doesn't update the reported values above).

[MHMG]

Great idea! I'm not sure if the test I just did is valid, I've had a few glasses of wine with dinner  .
In Photoshop I made a two pixel document IN Lab.
One pixel is Lstar 100/0/0. The other is Lstar 99/0/0.
ColorThink extracts two unique values which is kind of expected.
What is interesting is the Lab values it provides which is a tad different than Photoshop and may be a clue to what is going on with the report.

#1 100.00/-0.00/0.00  
#2  99.12/-0.00/0.00
ColorThink has more precision in the values than Photoshop.

right, but note the delta E is less than 1.0 between these two pixels, hence delta E theory says you have only one uniquely discernible color, not two. The LAB triplets according to Colorthink are not a big enough color difference to be "just noticeable" even in the very simple side-by-side viewing condition needed for the observer to detect a perceivable difference according to delta E theory. Hence, this simple test  and your second test (see below) proves the hypothesis that Colorthink is simply reporting unique numeric LAB values, not unique values based on combination theory that would compare all combinations of Lab triplet pairs against a Just noticeable difference (JND) threshold such as delta E = 1 to prove that the observer can actually perceive two unique colors.

Now I make a similar 2 pixel document in ProPhoto RGB. One pixel is 255/255/255, the other is set for 254/254/254. I use the pencil tool set for one pixel and click on that 2nd pixel.
ColorThink reports the white pixel as we expect, Lstar 100. The pixel that was set for 254/254/254 is reported as Lstar 99.73

Yes, interesting that you chose RGB triplets with equal values so that L* is the only value showing movement. Keeping in mind that some sRGB profiles use simple matrix math with gamma 2.2 tone curve which matches aRGB but not ProPhoto while true sRGB has flare compensation in the low end of the RGB scale so L* calculations can differ from aRGB in the low end, and of course, ProPhoto is gamma 1.8, so converting between these color spaces is bound to generate different numerically unique color values depending on how many shadow versus highlight tones are represented in the image and even if the image is a perfectly neutral gray monochrome RGB image. Since Colorthink is merely looking for unique math values (which is more possible with higher significant digits than is shown in PS into tool) the analysis of an image in sRGB versus aRGB is bound to differ, but not necessarily in a visually significant way since combination theory is not being used to rule out pairs with Delta E below any rational JND like 1.0. In other words, the fact that Colorthink claims two pixel values are unique because one has L*= 99.73 and the other has L* = 100.0 proves again that Colothink is looking at the calculated numeric values but not rounding them as much as PS info tool and not checking against a JND threshold to verify that the calculated difference can rationally be perceived by the human observer.

A simple but elegant test. I like 'em that way. Thanks for running it. So, now, how many angels danced on the head of that pin? Inquiring minds want to know!
 
best,
Mark
http://www.aardenburg-imaging.com

[MarkM]

Great post Mark. In terms of dE, and in the context of this discussion, is it useful in terms of evaluating what is and thus isn't visible when trying to decide if one color space with a fixed image does or doesn't contain more colors than the other? Or is it simply fruitless to even go there? Do you suppose ColorThink is using this metric in any way to produce the extraction of unique colors in the reports Bill and I produced?

If you take the 2-pixel image I attached earlier (I'll attach again) and extract the color list,  Colorthink will identify both colors even though they are very close together. They are separated by about 0.02 ∆E that should be well below the threshold for distinct visual colors. This would suggest ColorThink doesn't really attempt to identify visually distinct colors and is using some other metric.
 

[MHMG]

If you take the 2-pixel image I attached earlier (I'll attach again) and extract the color list,  Colorthink will identify both colors even though they are very close together. They are separated by about 0.02 ∆E that should be well below the threshold for distinct visual colors. This would suggest ColorThink doesn't really attempt to identify visually distinct colors and is using some other metric.
  

Hi MarkM, I haven't read all eight pages in this thread as closely as I should have. With digital dog's help, we have independently arrived at the same conclusion. Colorthink's "unique color" analysis is counting numerically unique LAB values but not perceptually unique LAB values  Nice when agreement is reached like this independently, but shame on me for not picking up on your earlier contribution to this discussion

best,
Mark
http://www.aardenburg-imaging.ocm

[digitaldog]

If you take the 2-pixel image I attached earlier (I'll attach again) and extract the color list,  Colorthink will identify both colors even though they are very close together. They are separated by about 0.02 ∆E that should be well below the threshold for distinct visual colors. This would suggest ColorThink doesn't really attempt to identify visually distinct colors and is using some other metric.
 

Ops, I missed that too, sorry.

[MarkM]

Here's another image that's illuminating when opened in ColorThink. This image is a 256 x256 slice of the RGB space where the blue value is zero. ColorThink seems to limit its color list to 10000 points and it seems to decide this by tossing values at set RGB value intervals (culling more in the shadows and fewer in the highlights).   I think it's safe to assume the color list is not a good indication of the number of discernible colors in a file.

[Jim Kasson]

Andrew, I think one of the issues you'll have to wrestle with when you construct your video is what level of mathematical skills to assume on the part of your viewers. You can probably teach them all the psychology they need to know (without referencing the experiments, which would make the video really long) assuming nothing other than that they have something close to "normal" human vision. You can assume some basic photographic skills. But your audience's math skill are likely to be all over the map.

It could be a shorter video if you assumed familiarity with:

High school algebra, including the "See Spot run" linear algebra that's taught in high school. Then they'd know what a column vector is and how to multiply matrices, which would help a lot. You'd probably have to remind them what constitutes a linear transformation.
The concepts of precision and accuracy in mathematics and experimental science.
Cartesian and cylindrical coordinates. That assumes a little trig.
How to work with binary coded unsigned integers.
How to read two-dimensional graphs of three dimensional objects, sets, and surfaces.

I've probably left some things out, but you get the idea.

However, it's not clear to me that you can assume any of the above. Teaching much of it would take too long and probably bore your viewers anyway, especially the ones that know it already. So you are left with teaching just enough of it so that your viewers can understand precise explanations, and presenting the rest with useful, but imprecise and possibly inelegant substitutions and analogies.

Not an easy thing to do. I guess that's why we pay you the big bucks.

Jim

[digitaldog]

I think it's safe to assume the color list is not a good indication of the number of discernible colors in a file.

Excellent, I'm happy we went down this route and came to this conclusion. ColorThink was one tool that I used for analysis to determine if Adobe RGB had more colors than sRGB, it told me it did, that threw me for a bit of a loop. Since we appear to agree that the number of colors have to be discernible to be valid, I can forget this analysis. Hopefully Bill who also conducted similar CT tests is seeing all this too. He also had a good explanation why using CT for this analysis wasn't effective in answering the original question: does Adobe RGB (1998) have more colors than sRGB.

I do want to point out that I don't think ColorThink was designed for this task anyway. As Mark (MHMG) asked, is there a way to control this process so the report would create visibly discernible colors and I don't think there is for this reason. The feature is to produce a color list. I've used this feature in the past to build actual targets to measure and for that task, I do want the tool to build the list this way, which can easily be edited in Excel if necessary. Case in point was when I wanted to build a patch target from the Roman 16 images. I sampled them way down using Nearest Neighbor to 300x300 pixels, then used CT to extract the unique colors which allowed me to build a target of patches from the image. I could then print the 300x300 pixel target though the profile and compare those reference values to a measured value from the custom target. The patches were built from an actual image in an actual RGB working space which was necessary for a test being done rather than use say a ECI2002 or similar 'profile target' who's colors didn't 'fit' within the original Roman 16's working space. I point this out only to suggest that CT is a fantastic tool and that the unique color extraction probably wasn't intended for analyzing 'number of colors' in a working space.

 

[digitaldog]

Andrew, I think one of the issues you'll have to wrestle with when you construct your video is what level of mathematical skills to assume on the part of your viewers.

Like me, virtually none (I'm quite mathematically challenged).

[Alan Goldhammer]

It might also be nice to post the link to the X-Rite/Pantone Hue Color Test that viewers can take.  This really highlights how we all see and perceive color.