Choices Between Printer Color Profiling Engines

[Brad P]

I have hopefully a few quick questions -

As background, I've been making my own profiles for about 6 months using them for print (mostly color, some B/W).  I'm not a color scientist or guru like many here.  I've been comparing only a few test prints from Argyll, i1P and Basiccolor's DropRGB.  I'm developing a pretty firm view that before I spend another $1K or so on lenses, I'd be better off spending some part of that on a good color profiling software system.

Questions:

1. Assuming I often process photos very heavily in ProPhoto RGB (sometimes heavily manipulating luminosity, hue and saturation), is it right to assume that the OOG color banding I see printing out Bills Balls and Granger Rainbows is directly relevant to which choice between the different engines?  Here, I'm currently operating with a working hypothesis that however those colors are generated and brought into print gamut, I'll be doing that and would want to purchase or use the software that does the best job there.

2. I've seen Doug Gray's excellent post on differences he's observed between i1P and Argyll on this forum, as well as read less detailed but experienced observations and opinions from many others whose views I respect.  Is there anywhere anyone could point me to more broadband scientific (or aesthetic) evaluations of the different profiling engines?  Or must I print them all out and do the evaluations myself?

Any thoughts appreciated.  Thanks

[digitaldog]

1. Assuming I often process photos very heavily in ProPhoto RGB (sometimes heavily manipulating luminosity, hue and saturation), is it right to assume that the OOG color banding I see printing out Bills Balls and Grainger Rainbows is directly relevant to which choice between the different engines?

Yes!

[Brad P]

Thanks Andrew.  From you I take that as gospel. 

I've not found any way to demo Copra and actually print out color samples.  I've read their website, and they don't apparently let ICC samples out of the cage.  If anyone knows something contrary to that, please let everyone know.

So far I have tested BasICColor DropRGB with a 4357 patch set.  DropRGB is basically a $350 dumbed down version of their "Print" printer profiling software.  Unlike Print, DropRGB doesn't allow adjustments for light sources, OBAs etc. or CYMK profiling.  Otherwise I’m assuming it’s about the same and going on. 

I'm headed tomorrow to process the scanned patch set with Argyll.  To do that, I plan on using the following command line: colprof -v -qh -S ProPhotoRGB.icm -cmt -dpp FILENAME, which is borrowed from Geraldo's post under Printing, Papers and Inks.  I've used that seemingly successfully for about 6 months, but I'm uncertain about a few things.  If anyone pretty familiar with Argyll could validate that I'd be grateful.

If that command line is wrong, the things I'm most concerned about are from other posts mostly on other websites.  Some people I've read suggest AdobeRGB instead of ProPhoto, but I'm pretty sure that's only true if all images printed are from Adobe RGB.  I guess I can worry about AdobeRGB, sRGB, posters and other things I print in narrower colorspaces, but that's not color critical to me anyway.   Second I've read posts suggest using a colorspace ending in ".icc" instead of ".icm".  I've searched my own computer and don't see any color reference files ending in "icc", so I'm assuming the formula as written (Geraldo's formulation) and that a number of people (including me) have been using is correct.  Finally, I see one person throwing in the following: "-r1.0", "-D", and "<description>".  I looked these up in some of the Argyll documentation and suspect all these are either outdated or unnecessary unless one wants to generate error logs etc.  Anyway, my goal here is to massage images in ProPhoto all the time and print.  I want to make sure a cLUT table gets set up and prints correctly in RelCol, Perceptual and Saturation.  From what I know and can figure, that'll do it in Argyll tomorrow.  If anyone can save me another headache or two that would be great.

I've attached an imperfect but hopefully useful to some outdoor iPhone pic of some of the areas that I'm focusing on with BasICColor’s DropRGB.  From bottom to top (or left to right if you click on it), Saturation, Perceptual and RelCol. 

DropRGB is super easy to use, and at least in daylight, looking at the test images it does very well with in-gamut colors.  More specifically, there are some visible differences, but they are surprisingly close with the ColorChecker Digital image (checking against my ColorChecker), most wouldn't notice the difference without staring closely and then it's only a few boxes.  I’ve worked with ColorChecker for about 5 years and these are what I’d call very good and very minor.  DropRGB also does very well, visibly again, with in gamut color ramps and BW ramps.  My spectrophotometer is embedded in my Z3200, so that's as accurate as I'm going to get with in gamut colors without rescanning a patch set.  However, I've noticed that when mapping OOG inputs to the printer, there remain banding issues as revealed in the Granger and Bills Balls tests, much more so with RelCol than Saturation or Perpetual, and slightly more in Saturation than Perceptual.  There is a major color shift in Saturation in the Cyan OOG colors, lesser so in the magentas to reds, in the BBs test relative to the RelCol and Perceptual intents that is somewhat concerning.  Although the in-gamut test images look terrific with all three intents, because I often do process my files so heavily, I am keenly interested to see what the different mapping engines do to the out of gamut colors. (This exercise is also teaching me to be very careful heavily manipulating colors in ProPhoto).

[Iliah]

  I'm headed tomorrow to process the scanned patch set with Argyll.  To do that, I plan on using the following command line: colprof -v -qh -S ProPhotoRGB.icm -cmt -dpp FILENAME

Try using generic printer profile for gamut limitation when using targen https://argyllcms.com/doc/targen.html#c
and
collink with -G src.gam https://argyllcms.com/doc/collink.html#G for conversion

[digitaldog]

Thanks Andrew.  From you I take that as gospel. 

It was short, maybe not so sweet. But this video shows the differences in two color engines:


Not all ICC profiles are created equally

In this 23 minute video, I'll cover:
The basic anatomy of ICC Profiles
Why there are differences in profile quality and color rendering
How to evaluate an ICC output profile
Examples of good and not so good canned profiles and custom profiles on actual printed output.

High resolution: http://digitaldog.net/files/Not_All_Profiles_are_created_equally.mp4
Low resolution (YouTube): https://www.youtube.com/watch?v=TNdR_tIFMME&feature=youtu.be

[digitaldog]

I've not found any way to demo Copra and actually print out color samples.  I've read their website, and they don't apparently let ICC samples out of the cage.  If anyone knows something contrary to that, please let everyone know.

Send me the measurement data, I'd be happy to make a 'demo' profile using Copra. Then you can test it with others.

[Brad P]

Send me the measurement data, I'd be happy to make a 'demo' profile using Copra. Then you can test it with others.

Just emailed to Digital Dog.  Thanks Andrew. 

[digitaldog]

Just emailed to Digital Dog.  Thanks Andrew.

Just sent the profile made with Copra's 'default' settings.

[Brad P]

Try using generic printer profile for gamut limitation when using targen https://argyllcms.com/doc/targen.html#c
and
collink with -G src.gam https://argyllcms.com/doc/collink.html#G for conversion

Thanks Iliah.  I've already generated an ICC profile using the command line I mentioned earlier (colprof -v -qh -S ProPhotoRGB.icm -cmt -dpp FILENAME) and it actually seems to be significantly better re OOG colors (if not just about everything) than two others I've made so far using DropRGB and Copra's defaults, particularly in the Perceptual and Saturation intents.  I'm guessing that's because it's mapping from ProPhoto and not a smaller colorspace judging from the significantly less banding.  Just a guess.

I've read through the links you sent -- several times.  That looks exactly like what I want to do.   Honestly it will take me quite a while to digest all the code and put together the formulation you're suggesting.  Do you think that's going to produce better results than what I'm seeing now? 

If you do know the code offhand to map ProPhoto RGB through to RelCol, Perpetual and Saturation, I'd be extraordinarily happy to copy your homework (and if Argyll turns out to be the winner, I'll make an appropriate donation).

I'm working on hopefully resolving a possible issue I'm having printing up samples with Copra and once I struggle with that a bit more I'll take a pic of the interim results so far.

Thanks to both you and Andrew for your input.

[GWGill]

I'm headed tomorrow to process the scanned patch set with Argyll.  To do that, I plan on using the following command line: colprof -v -qh -S ProPhotoRGB.icm -cmt -dpp FILENAME, which is borrowed from Geraldo's post under Printing, Papers and Inks.  I've used that seemingly successfully for about 6 months, but I'm uncertain about a few things.  If anyone pretty familiar with Argyll could validate that I'd be grateful.

If your intention is to do artificial bench marking using images that fully utilize the ProPhoto gamut, then this is a good place to start. Note though, that it's not typically appropriate for real images encoded in ProPhoto.

The disadvantage of large gamut encodings is that they give no indication of the contents gamut, unlike smaller gamut encodings (i.e. sRGB), where images are likely to have been rendered so as to fully occupy the encoding spaces. So to get the best for real images, an image gamut should be supplied. See here.

For the smoothest possible result, a device link workflow is superior to linking ICC device profiles in the CMM.

Second I've read posts suggest using a colorspace ending in ".icc" instead of ".icm".

.icm is the convention on MSWindows systems, .icc is the convention on OS X and Linux/Unix. The file contents are identical, the extension is just a convention.

I looked these up in some of the Argyll documentation and suspect all these are either outdated or unnecessary unless one wants to generate error logs etc.

The defaults are intended to be a good place to start. You can then wander off that path when you have a reason to do so, or want to explore.

[digitaldog]

If your intention is to do artificial bench marking using images that fully utilize the ProPhoto gamut, then this is a good place to start. Note though, that it's not typically appropriate for real images encoded in ProPhoto.

Agreed. Like a Granger Rainbow, Bill's Balls are a torture test not based on photographic reality. But it is interesting to see how profiles behave with such subjects.

[Brad P]

If your intention is to do artificial bench marking using images that fully utilize the ProPhoto gamut, then this is a good place to start. Note though, that it's not typically appropriate for real images encoded in ProPhoto.

The disadvantage of large gamut encodings is that they give no indication of the contents gamut, unlike smaller gamut encodings (i.e. sRGB), where images are likely to have been rendered so as to fully occupy the encoding spaces. So to get the best for real images, an image gamut should be supplied. See here.

For the smoothest possible result, a device link workflow is superior to linking ICC device profiles in the CMM..icm is the convention on MSWindows systems, .icc is the convention on OS X and Linux/Unix. The file contents are identical, the extension is just a convention.The defaults are intended to be a good place to start. You can then wander off that path when you have a reason to do so, or want to explore.

Thank you for this explanation Graeme.  It's only today becoming clear to me after reading Iliah's references this morning and your explanation now that Argyll is a different type of animal -- capable of doing what they do (seemingly better for now), but also allowing for much more tailored approaches.  I am especially interested in the image gamut to printer mapping capabilities and the device link (collink) workflow, both of which I was ignorant of earlier today.  That could be exactly what I'm ultimately looking for (and will subscribe if so!).

I did some amateurish command line work part time over thirty years ago at about the same time I was taking French, so reading through the materials now is very much like trying to read the latest scientific papers in French.  If there's any more plain english rendering of these materials any pointers to that, it would be great.  Otherwise, I suppose that's what Google is for.

Anyway, my intention here is to visually benchmark the capabilities of the various platforms focusing particularly on the out of screen/print gamut renderings.  To use Andrew's metaphor, I like to torture my ProPhoto files in very rational ways so that parts at least of Granger rainbows and BB's seem relevant to me.  What I'm aiming to find is to find a methodology to bring all that back into print gamut in the most rational way possible.   Anyway, I'll finish this exercise soon and take proper pictures of the results so people can at least have a handle on those visuals -- probably in a few days time as I have a few busy days ahead.

[Alan Goldhammer]

I did some amateurish command line work part time over thirty years ago at about the same time I was taking French, so reading through the materials now is very much like trying to read the latest scientific papers in French.  If there's any more plain english rendering of these materials any pointers to that, it would be great.  Otherwise, I suppose that's what Google is for.

One time saving comment if you are a sometimes sloppy typist as I am.  I keep a Notepad file (Windows; I assume there is a similar feature on MacOS) with all my Argyll commands edited and proofed.  I can then copy and paste the line into the command prompt, hit enter and let the computation begin without getting the error screen saying invalid entry.

Anders Torger who has developed camera profiling software has a simple Argyll tutorial HERE but it's more for the novice and not what you are after.

[Ethan Hansen]

Brad: Here is a high-level overview I made of various i1Profiler alternatives.

A point Graeme alluded to is critical when evaluating out-of-gamut color rendering. Relative colorimetric conversions tend to be more similar between profiling applications. A strict implementation would give nearly identical results as relative colorimetric clips out-of-gamut colors to the closest in-gamut value. It's in the definition of "closest" that the differences lie. There are variations in how hue angle shifts resulting from use of LAB as an intermediate space are handled (e.g. preventing reds from turning orange or blues heading towards purple). Some profiling codes cheat here slightly, trading mathematical accuracy for aesthetics.

Perceptual rendering is an entirely different beast. Not only does each vendor have differing ideas about what constitutes "perceptually appealing" but there is the matter of what source color space is assumed. The goal of perceptual rendering is to preserve the relationships between colors during the process of cramming the source gamut into the destination color space. Defining how overall color relationships work makes an implicit assumption about the difference between source and the profile gamuts. What these assumptions are is not published by commercial vendors.

Using a device link profile as Graeme recommends allows for more efficient conversions (as you explicitly specify the source gamut)and, if you make them on a per-image basis, the gamut mapping can fully utilize the color range in that image.

I see two issues with evaluating profile performance based on ProPhoto RGB images. First, only 87% of PP RGB values correspond to real-world colors or can be represented using valid LAB range values. The most out-of-gamut colors have no actual, physical equivalents. Worrying about how these appear rendered through a profile is meaningless.

A second, potentially more serious issue is what device will you use to evaluate the profiles with? Even the highest gamut monitor reproduces less than 50% of the PP RGB gamut. When you see artifacts are they the result of the profile or your monitor? If you are only judging the print rendering rather than an on-screen soft proof this is less of a factor.

Instead I would choose source color spaces that (1) either completely fits within the LAB encoding volume or comes close and (2) you have some hope of judging the soft proof performance. For on-screen evaluations I would choose either Adobe RGB or, for a slightly larger gamut, NTSC RGB. For evaluating printed output only I would not use a color space larger than Don RGB 4 (99% of colors reproducible within LAB).

[Iliah]

For evaluating printed output only I would not use a color space larger than Don RGB 4 (99% of colors reproducible within LAB).

I'm very satisfied with BetaRGB

[GWGill]

Relative colorimetric conversions tend to be more similar between profiling applications. A strict implementation would give nearly identical results as relative colorimetric clips out-of-gamut colors to the closest in-gamut value. It's in the definition of "closest" that the differences lie. There are variations in how hue angle shifts resulting from use of LAB as an intermediate space are handled (e.g. preventing reds from turning orange or blues heading towards purple). Some profiling codes cheat here slightly, trading mathematical accuracy for aesthetics.

Yes - it turns out that many users expect something other than strictly minimum delta E behavior for colorimetric clipping.
A geometric aspect of "closest distance" that (perhaps) isn't widely appreciated, is that when gamut surfaces are concave, this leads to rather non-smooth and abrupt shifts in hue and other traits as one travels through the out of gamut space.

Using a device link profile as Graeme recommends allows for more efficient conversions (as you explicitly specify the source gamut)and, if you make them on a per-image basis, the gamut mapping can fully utilize the color range in that image.

Not so much efficient, as higher quality. In creating a conversion from one device space directly to the other, there is the opportunity to determine the output devices values more accurately by using the A2B table, rather than the derived B2A table which has accuracy limited by the cLUT PCS grid resolution.

[Doug Gray]

Yes - it turns out that many users expect something other than strictly minimum delta E behavior for colorimetric clipping.
A geometric aspect of "closest distance" that (perhaps) isn't widely appreciated, is that when gamut surfaces are concave, this leads to rather non-smooth and abrupt shifts in hue and other traits as one travels through the out of gamut space.

Indeed. This is a somewhat bigger problem with additional color inks such as the red and green ones used in my 9500 II as well as many newer printers.

Not so much efficient, as higher quality. In creating a conversion from one device space directly to the other, there is the opportunity to determine the output devices values more accurately by using the A2B table, rather than the derived B2A table which has accuracy limited by the cLUT PCS grid resolution.

Unfortunately, this is unavoidable since the B2A tables are used for printing. But a good device link profile can at least minimize this media to media conversion since it is after the initial B2A conversion.

[Ethan Hansen]

I'm very satisfied with BetaRGB

Very similar spaces. Don RGB pushes farther into highly saturated yellows. Newer Epson inks can edge to or slightly beyond BetaRGB in yellow. Otherwise, it's a push.

[GWGill]

Unfortunately, this is unavoidable since the B2A tables are used for printing.

Not so - in creating a device link there is the opportunity to directly invert the A2B, and ignore the B2A.

[Doug Gray]

Not so - in creating a device link there is the opportunity to directly invert the A2B, and ignore the B2A.

Interesting. So you are suggesting bypassing the PCS and going directly from, say Adobe RGB or one of the larger spaces that encompasses printable colors? This would lock in a working space but yeah, it should work better than going through the PCS. I think of device link profiles as gamut mapping from one output device to another output device but yeah, no reason it couldn't go from RGB tri color working spaces to a printer colorimetrically.