Luminous Landscape Forum

Raw & Post Processing, Printing => Colour Management => Topic started by: Brad P on December 15, 2017, 04:07:53 pm

Title: Choices Between Printer Color Profiling Engines
Post by: Brad P on December 15, 2017, 04:07:53 pm
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

Title: Re: Choices Between Color Profiling Engines
Post by: digitaldog on December 15, 2017, 05:22:11 pm
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!
Title: Re: Choices Between Color Profiling Engines
Post by: Brad P on December 16, 2017, 11:07:57 pm
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).
Title: Re: Choices Between Color Profiling Engines
Post by: Iliah on December 17, 2017, 09:49:17 am
  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
Title: Re: Choices Between Color Profiling Engines
Post by: digitaldog on December 17, 2017, 11:18:19 am
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
Title: Re: Choices Between Color Profiling Engines
Post by: digitaldog on December 17, 2017, 11:19:47 am
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.
Title: Re: Choices Between Color Profiling Engines
Post by: Brad P on December 17, 2017, 12:22:36 pm
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. 
Title: Re: Choices Between Color Profiling Engines
Post by: digitaldog on December 17, 2017, 12:50:15 pm
Just emailed to Digital Dog.  Thanks Andrew.
Just sent the profile made with Copra's 'default' settings.
Title: Re: Choices Between Color Profiling Engines
Post by: Brad P on December 17, 2017, 07:45:45 pm
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.
Title: Re: Choices Between Color Profiling Engines
Post by: GWGill on December 17, 2017, 07:59:26 pm
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 (http://www.argyllcms.com/doc/colprof.html#g).

For the smoothest possible result, a device link workflow is superior (http://www.argyllcms.com/doc/Scenarios.html#LP1) to linking ICC device profiles in the CMM.
Quote
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.
Quote
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.
Title: Re: Choices Between Color Profiling Engines
Post by: digitaldog on December 17, 2017, 10:01:58 pm
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.
Title: Re: Choices Between Color Profiling Engines
Post by: Brad P on December 17, 2017, 10:54:41 pm
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 (http://www.argyllcms.com/doc/colprof.html#g).

For the smoothest possible result, a device link workflow is superior (http://www.argyllcms.com/doc/Scenarios.html#LP1) 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.
Title: Re: Choices Between Color Profiling Engines
Post by: Alan Goldhammer on December 18, 2017, 08:29:33 am
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 (https://www.ludd.ltu.se/~torger/photography/argyll-print.html#toc0) but it's more for the novice and not what you are after.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Ethan Hansen on December 18, 2017, 05:26:22 pm
Brad: Here is a high-level overview (http://forum.luminous-landscape.com/index.php?topic=120582.msg999718#msg999718) 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).
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Iliah on December 18, 2017, 05:38:08 pm
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 ;)
Title: Re: Choices Between Printer Color Profiling Engines
Post by: GWGill on December 18, 2017, 05:56:43 pm
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.
Quote
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.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Doug Gray on December 18, 2017, 07:15:43 pm
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.
Quote
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.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Ethan Hansen on December 18, 2017, 07:19:53 pm
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.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: GWGill on December 18, 2017, 08:29:35 pm
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.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Doug Gray on December 18, 2017, 09:25:32 pm
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.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: digitaldog on December 18, 2017, 09:31:57 pm

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.
That's where Device Links profiles come in so handy; no PCS necessary/conversions can be direct such as CMYK to CMYK. A device link is like two profiles hardwired into one. There is no Source and Destination methodology with device links because they are built as a one-way street, allowing only a very specific, fixed type of conversion.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Doug Gray on December 18, 2017, 10:22:16 pm
That's where Device Links profiles come in so handy; no PCS necessary/conversions can be direct such as CMYK to CMYK. A device link is like two profiles hardwired into one. There is no Source and Destination methodology with device links because they are built as a one-way street, allowing only a very specific, fixed type of conversion.
True! And I always just thought of device link profiles as something the CYMK peeps did for their advantage in controlling inking. I just never thought of using device link profiles to go from, say sRGB or Adobe RGB to the printer directly. But there are obvious advantages. Especially for sRGB photos with perceptual mapping where you know the source profile was sRGB and can map into the printer's profile to create more attractive prints than are possible when using standard profiles. Also, all but the largest RGB colorspaces should produce significantly less error in colorimetric conversions. OTOH, going from a space like ProPhoto would increase the distance between LUT grid points. It isn't clear to me that a ProPhoto RGB link to a printer would be better than going through the standard ppRGB->PCSLAB->printer. Would be interesting to create and test device link profiles against standard profiles when using wide RGB working spaces.

EtoA: I just tried making a device link profile with I1Profiler RGB->RGB and it only allows source profiles that are printer type devices.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Ethan Hansen on December 18, 2017, 10:42:21 pm
True! And I always just thought of device link profiles as something the CYMK peeps did for their advantage in controlling inking. I just never thought of using device link profiles to go from, say sRGB or Adobe RGB to the printer directly. But there are obvious advantages. Especially for sRGB photos with perceptual mapping where you know the source profile was sRGB and can map into the printer's profile to create more attractive prints than are possible when using standard profiles. Also, all but the largest RGB colorspaces should produce significantly less error in colorimetric conversions. OTOH, going from a space like ProPhoto would increase the distance between LUT grid points. It isn't clear to me that a ProPhoto RGB link to a printer would be better than going through the standard ppRGB->PCSLAB->printer. Would be interesting to create and test device link profiles against standard profiles when using wide RGB working spaces.

EtoA: I just tried making a device link profile with I1Profiler RGB->RGB and it only allows source profiles that are printer type devices.

i1Profiler's devicelink implementation isn't particularly useful. THere isn't much control and, as you discovered, there is no way to link dissimilar profile types.

If your source image is in a huge color space such as PP RGB, the way to make best use of device links is via Argyll's ability to create bespoke, image-specific DL's. This is something we do with regularity when working with the wonky printers and substrates used for building wraps or architectural mesh. A 30 story tall image can easily highlight transition lines or banding. Making a devicelink based on the actual color values in the source image helps considerably.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Doug Gray on December 18, 2017, 11:05:06 pm
i1Profiler's devicelink implementation isn't particularly useful. THere isn't much control and, as you discovered, there is no way to link dissimilar profile types.

If your source image is in a huge color space such as PP RGB, the way to make best use of device links is via Argyll's ability to create bespoke, image-specific DL's. This is something we do with regularity when working with the wonky printers and substrates used for building wraps or architectural mesh. A 30 story tall image can easily highlight transition lines or banding. Making a devicelink based on the actual color values in the source image helps considerably.

I don't have a need like that. Generally I want to convert colorimetrically from some arbitrary RGB space, often ppRGB, to printer RGB. I would like to do it accurately.

I'm coming to the conclusion the simplest way, at least for me, would be to use the A2B tables and do a steepest descent search for the RGB values that produces the desired LAB. Alternately, just read in the RAW target RGB/LAB values and do some 3D interpolation in Matlab.

One thing I recently discovered is that the printer's repeatability is considerably higher with matte papers than it is with glossy types. Not sure why that is but it's been highly repeatable in experiments I've been doing the last week with similar results from both printers. So reproducing colors on matte paper would likely benefit from using a more refined technique that just depending on the B2A tables.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: GWGill on December 18, 2017, 11:08:53 pm
So you are suggesting bypassing the PCS and going directly from, say Adobe RGB or one of the larger spaces that encompasses printable colors?
Some sort of PCS is always going to be used in the linking process when the input to the process is ICC device profiles. But there is no necessity to use the B2A table.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: GWGill on December 18, 2017, 11:19:04 pm
I'm coming to the conclusion the simplest way, at least for me, would be to use the A2B tables and do a steepest descent search for the RGB values that produces the desired LAB.
One of many possible approaches if it's an RGB profile. A numerical non-linear equation solver would be another.
More complicated if it's CMYK and one wishes to discover the whole locus of possible solutions though :-)
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Doug Gray on December 18, 2017, 11:36:25 pm
One of many possible approaches if it's an RGB profile. A numerical non-linear equation solver would be another.
More complicated if it's CMYK and one wishes to discover the whole locus of possible solutions though :-)
Yes. glad I'm using RGB. Finding the full set of 4+ variables that map to a 3D LAB value sounds painful. Though, for people minimizing ink use or improving some other metric perhaps related to the screen or diffusion pattern, it's of significant interest.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Brad P on December 19, 2017, 01:14:18 am
Tracking along.  Thanks for all the links. Surprisingly I read or tried to read all those links before posting.

The one thing I’d add is that ProPhoto 16 bit seems to be the image processing space of the day.  I’ve profiled two cameras from RAW to 16 bit ProPhoto 5 and 3 years ago.  I gave that up when I started converting RAW to 16 bit ProPhoto TIFFs in Phocus about 6 months ago.  I tried Lab in PS, was excited for a while, but concluded that on that platform anyway it didn’t seem ready. Maybe I should go back to creating camera profiles and following it through start to finish. Maybe not  Part of this is aesthetics. 

For now, converting a very well done 16 bit ProPhoto TIFF to printer space, yanking it around in the meantime (see Tony Kuyper’s luminousity curve PS plugins for a yanking image processing example), is at least what I am in this post trying to drill down on. 

I guess collink may not be the right way for me if it means processing images in my NEC monitor space (measured much better than Adobe RGB and advertised) and outputting through that space.  I had mistakenly thought earlier that was a guide to Argyll in rendering the original TIFF file to print, if that makes sense. 
Title: Re: Choices Between Printer Color Profiling Engines
Post by: GWGill on December 19, 2017, 06:40:46 am
I had mistakenly thought earlier that was a guide to Argyll in rendering the original TIFF file to print, if that makes sense.
None at all I'm afraid. Perhaps you should be more explicit as to the workflows you are referring to.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Iliah on December 19, 2017, 09:50:28 am
I always just thought of device link profiles as something the CYMK peeps did for their advantage in controlling inking.
Film "looks" and simulations we use in RPP and elsewhere are "device links". Some are RGB-RGB, some are Lab-Lab. Turned out, it is a superior method compared to just film "profiles", gets closer to the desired look, with negligible artifacts and very predictable behavior.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: digitaldog on December 19, 2017, 10:31:44 am
The one thing I’d add is that ProPhoto 16 bit seems to be the image processing space of the day.
There's another potential  benefit to very large RGB working space color gamuts like ProPhoto RGB when your goal is printing.

Simple matrix profiles of RGB working spaces when plotted 3 dimensionally illustrate that they reach their maximum saturation at high luminance levels. The opposite is seen with print (output) color spaces. Printers produce color by adding ink or some colorant, while working space profiles are based on building more saturation by adding more light due to the differences in subtractive and additive color models. To counter this, you need a really big RGB working space like ProPhoto RGB again due to the simple size and to fit the round peg in the bigger square hole. RGB working spaces have shapes which are simple and predictable and differ greatly from output color spaces. Then there is the issue of very dark colors of intense saturation which do occur in nature and we can capture with many devices. Many of these colors fall outside Adobe RGB (1998) and when you encode into such a color space or smaller gamut, you clip the colors to the degree that smooth gradations become solid blobs in print, again due to the dissimilar shapes and differences in how the two spaces relate to luminance. So the advantage of ProPhoto isn't only about retaining all those out-of-gamut colors it's also about maintaining the dissimilarities between them, so that you can map them into a printable color space as gradations rather than ending up as blobs. 


Here is a link to a TIFF that I built to show the effect of the 'blobs' and lack of definition of dark but saturated colors using sRGB (Red dots) versus the same image in ProPhoto RGB (Green dots). The image was synthetic, a Granger Rainbow which contains a huge number of possible colors. You can see that the gamut of ProPhoto is larger as expected. But notice the clumping of the colored red vs. green dots in darker tones which are lower down in the plot. Both RGB working space were converted to a final output printer color space (Epson 3880 Luster).

http://www.digitaldog.net/files/sRGBvsPro3DPlot_Granger.tif (http://www.digitaldog.net/files/sRGBvsPro3DPlot_Granger.tif)
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Brad P on December 26, 2017, 08:21:08 pm
Sorry for the delay, but in the interim I had to order and replaced a printhead.

Attached are the results of a 4257 patch test in Argyll, DropRGB, and Copra for comparison.  I have not tested i1P as it's now apparent I need to purchase the hardware.

Here's a list of some assorted thoughts and preliminary conclusions.  Feel free to comment yourself.

1. These results are particular to printing on a Z3200ps.  It has a somewhat smaller gamut (though more archival inks) than competing models from Canon or Epson, and the results on those machines would be interesting to see in comparison.  If you have another printer you probably should conduct your own tests.  Even maybe if you have another Z3200.  Probably different results apply across papers too.  Here I used Ilford Gold Fibre Gloss which has no OBAs, high Gamut and D-max

2. I used a 4537 patch chart that dried 3 days before scanning it and creating the icc profile.  It could have been improved by using a more perfect patch set described by Doug here (http://forum.luminous-landscape.com/index.php?topic=121939.msg1016442#msg1016442).  I will follow that process hopefully next time.  But for visual purposes, I believe the consensus there was it doesn't matter.

3. Very few differences exist in the in gamut colors across all software platforms.  Significant differences, however, exist in how out of gamut colors print across the software platforms as well as between rendering intents.  If you're printing prints with significant out of gamut colors, the findings here appear at least to me to be significant.

4. Perceptual generally did better than Saturation, which did better then Relative Colorimetric.

5. Overall, on an equally weighted, blended basis, DropRGB appears to my eye to be the winner, followed closely by Argyll, then Copra.  If you weigh Perceptual much more heavily, however (as I do), then Argyll appears to me to be the winner.  DropRGB is extremely close and I had thought I liked that more at first, but I realized that Argyll performed more truly on the luminance scale in the Granger Rainbow test and that seems more important to me.  It's debatable I guess and I'd be interested in what others see in these images.

Absent some new and noteworthy i1P information, I think I'm going to use Argyll for the intermediate future anyway.  Not solely because of its Perceptual rendering, but it's customization and I'm actually excited to try out its image to print profile capabilities (discussed above).
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Brad P on December 26, 2017, 08:22:34 pm
. . . and the Saturation pics.

I converted these to sRGB.  If anyone wants the ProPhoto or an Adobe RGB file, let me know.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: aaronchan on December 26, 2017, 10:46:32 pm
. . . and the Saturation pics.

I converted these to sRGB.  If anyone wants the ProPhoto or an Adobe RGB file, let me know.

Thanks for your great test.
If you want to, you can send me the measurement CGATS and I can generate an icc profile with i1P for you.

Thank you
Aaron Chan
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Brad P on December 26, 2017, 10:59:53 pm
Thanks Aaron.  That would make it complete.  I'll PM you.

Title: Re: Choices Between Printer Color Profiling Engines
Post by: aaronchan on December 26, 2017, 11:24:23 pm
Thanks Aaron.  That would make it complete.  I'll PM you.

please check pm
thx
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Brad P on December 27, 2017, 03:21:55 am
Thanks again Aaron.  I printed up the i1P samples and am going to let them dry overnight and shoot them tomorrow alongside the other samples, and will post the results.  For the moment though, Argyll remains the most impressive with the Z3200, followed by DropRGB.

Andrew, if you’re still around, I’m getting darker blue balls with i1P than I expected.  You might want to check that out in my pics tomorrow.  Not as dark/black as Copra, but much darker than those in your video, particularly in the darker ball.  I suspect it’s more likely a result of the inkset used by the Z, or possibly that we used i1P’s default settings, than an error in color management as I’ve been over the latter’s pipeline quite a few times.  But very interested in your take on that.  I’ll get a little better light on the final shot too because there is clear gradation in the i1P blue sample that’s not at all so clear in Copra’s and the darks in all of them simply need more light in the shots. 
Title: Re: Choices Between Printer Color Profiling Engines
Post by: digitaldog on December 27, 2017, 01:46:04 pm
Andrew, if you’re still around, I’m getting darker blue balls with i1P than I expected.  \
But not black right?
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Doug Gray on December 27, 2017, 02:34:31 pm
Thanks again Aaron.  I printed up the i1P samples and am going to let them dry overnight and shoot them tomorrow alongside the other samples, and will post the results.  For the moment though, Argyll remains the most impressive with the Z3200, followed by DropRGB.

Andrew, if you’re still around, I’m getting darker blue balls with i1P than I expected.  You might want to check that out in my pics tomorrow.  Not as dark/black as Copra, but much darker than those in your video, particularly in the darker ball.  I suspect it’s more likely a result of the inkset used by the Z, or possibly that we used i1P’s default settings, than an error in color management as I’ve been over the latter’s pipeline quite a few times.  But very interested in your take on that.  I’ll get a little better light on the final shot too because there is clear gradation in the i1P blue sample that’s not at all so clear in Copra’s and the darks in all of them simply need more light in the shots.

Hi Brad,

This is a topic worth further discussion as it shows some of the risks using a large colorspace that extends to imaginary colors and the "blue" ball on the bottom right of Andrew's Gamut_Test_File_Flat.tiff image represents the most extreme, and imaginary, RGB blue. Load the file in Photoshop, bring up the info panel, and select Lab as the colorspace to show. Move the cursor to different parts of the blue ball. Notice the L* stays below 1 (.1 actually - even for max blue) which is a luminance below all printable blacks. The ICCLAB value of ProPhotoRGB(0,0,255) is L*=.08, a*=90, b*=-128. (ICCLAB clips CIELAB at -128, Actual CIELAB b*=-172).

So why does even ProPhotoRGB(0,0,255) look blue at all on a monitor if it's so dark?

The answer is that ProPhotoRGB colors are converted to displayable colors. Taking the specific cases of displays that are close to sRGB and those close to Adobe RGB, here is what we get: Both displays will attempt to display RGB(0,0,255). An sRGB like display will show LAB=30,68,-112 while Adobe RGB wiil do LAB=30,69,-114. These are close because the "blue" of Adobe RGB and sRGB are the same. They are also well defined since ICC specifies the math to be used when converting matrix profile colorspaces.

But what color should a printer make? These are way beyond printable gamuts. Generally, profile software in Perceptual tries to preserve hue or hue and luminance. In the latter case the printer will print black. This is what causes the big differences between how profiles handle these colors. And a printer profile operates only on ICCLAB values.

My 9800 glossy profile converts ProPhoto(0,0,255) to  LAB(16,18,-56), a printable blue but much darker than what my monitor shows. Is that the "right" color? Who knows?

So this brings up the more general issue of what colors should we be working with. I generally put these in several categories from the narrowest set, those that the printer can print, to increasingly larger gamuts.

These are stimulus colors. Colors are perceived based on context. That is what stimulus colors surround them and what adaptation has occurred.

1. Colors that are actually printable. By definition, these colors are within the printer's gamut.
2. Colors that can exist, theoretically at least, on a surface. These are the set of all colors with completely arbitrary spectral reflectances, and are bounded by the MacAdam limits. They are more limited than all possible visible colors because they are formed by subtraction of wavelengths. In a sense, these might be considered the limits of a "perfect" printer with an infinite set of inks.
3. Colors that exist and can be created by mixing all possible wavelengths of light. These require emissive sources. Think mixing light from a large number of lasers, each with a slightly different visible wavelength and adjustable magnitudes.
4. Finally, there are the imaginary colors. These are colors with xy coordinates that are outside the stimulus gamut. They don't exist because there are no combinations of wavelengths at any magnitude that produce them. These are the ones outside the classic CIEXY horseshoe gamut most often encountered in ProPhoto RGB where the Green and Blues are imaginary.

When evaluating a profile, my criteria varies. It's most critical for in printer gamut colors. There shall be no visible banding or other anomalies for these. Next, are Mac Adam colors that are outside the printer's gamut but physically realizable. These should be rendered smoothly and be pleasing though they will not be accurate. Then there are colors that are real but not possible on a surface. How they are rendered is not something I care about too much though my preference is that hue be maintained. These, can't ever be printed but can appear in photographs with things like red LED Christmas lights . I expect the luminance and saturation to drop but the hue to remain close.

Andrew's profile stress test image is particularly useful as it contains a variety of all of these. The photos are near what printer gamuts can reproduce and the synthetics push things out further past MacAdam and imaginary color limits. He has a good video of this showing how to edit real, but saturated images pushing the printer's gamut to recover blocked colors.

By way of example I've attached a down sampled color coded mapping of Andrew's stress test image showing the colors that are in each of these 4 categories.

The color assignments are:
1. pale cyan: Colors inside the printer's gamut. This varies of course, I used my 9800 with an Epson Prem. Glossy for this.
2. blue: Colors that are physically realizable on a surface (within MacAdam limits) but not printable with my printer.
3. red: Colors that physically exist (within the human gamut) but only with emissive sources like lasers, leds, etc.
4. black: Imaginary colors. They don't exist but are useful mathematical constructs.


Title: Re: Choices Between Printer Color Profiling Engines
Post by: Brad P on December 27, 2017, 11:28:56 pm
Attached are the complete charts.  Imperfectly lit but good enough for present purposes.  To observe the dark color gradations, you'll really need to click on the file and zoom in.  The darks are more colorful than they appear in the smaller thumbnails (and in person).  The i1P blues and gradations are distinctly better in person than the photos here might reveal, even in Perceptual.

Andrew, Doug, Graeme, Aaron and really all, thank you for your thoughts.  I'm quite grateful as I'm sure others are.  Doug, your last post I'm going to need to mull over a bit and play around in Lab before fully digesting and responding. 

For now, I want to get this benchmarking up for anyone interested in that to see.  I'm beginning to think the real answers here are more complicated than I had thought.  But for people working in ProPhoto space like me (so far), there's 1000 words in every picture.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Brad P on December 27, 2017, 11:30:17 pm
. . . and saturation.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: aaronchan on December 28, 2017, 12:30:17 am
Thanks again Aaron.  I printed up the i1P samples and am going to let them dry overnight and shoot them tomorrow alongside the other samples, and will post the results.  For the moment though, Argyll remains the most impressive with the Z3200, followed by DropRGB.

Andrew, if you’re still around, I’m getting darker blue balls with i1P than I expected.  You might want to check that out in my pics tomorrow.  Not as dark/black as Copra, but much darker than those in your video, particularly in the darker ball.  I suspect it’s more likely a result of the inkset used by the Z, or possibly that we used i1P’s default settings, than an error in color management as I’ve been over the latter’s pipeline quite a few times.  But very interested in your take on that.  I’ll get a little better light on the final shot too because there is clear gradation in the i1P blue sample that’s not at all so clear in Copra’s and the darks in all of them simply need more light in the shots.

Hi Brad,

I have done a simliar test as you did before.
But mind was using different target patches and generate the icc in i1P
Like what Ethan said on the other post
One of my client use 1600 patches target to generate his icc profile which produce similiar blue as your, pretty dark in perceptual.
And I have made an icc profile with Ethan's method, 2371patches, the blue comes out a lot more "blue" compare to his.
So, I guess each profile generator has it's own algorithm which you need to find it's best target size to make an optimal icc profile.

aaron
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Brad P on December 28, 2017, 09:26:10 pm
So this brings up the more general issue of what colors should we be working with. I generally put these in several categories from the narrowest set, those that the printer can print, to increasingly larger gamuts.

These are stimulus colors. Colors are perceived based on context. That is what stimulus colors surround them and what adaptation has occurred.

1. Colors that are actually printable. By definition, these colors are within the printer's gamut.
2. Colors that can exist, theoretically at least, on a surface. These are the set of all colors with completely arbitrary spectral reflectances, and are bounded by the MacAdam limits. They are more limited than all possible visible colors because they are formed by subtraction of wavelengths. In a sense, these might be considered the limits of a "perfect" printer with an infinite set of inks.
3. Colors that exist and can be created by mixing all possible wavelengths of light. These require emissive sources. Think mixing light from a large number of lasers, each with a slightly different visible wavelength and adjustable magnitudes.
4. Finally, there are the imaginary colors. These are colors with xy coordinates that are outside the stimulus gamut. They don't exist because there are no combinations of wavelengths at any magnitude that produce them. These are the ones outside the classic CIEXY horseshoe gamut most often encountered in ProPhoto RGB where the Green and Blues are imaginary.

When evaluating a profile, my criteria varies. It's most critical for in printer gamut colors. There shall be no visible banding or other anomalies for these. Next, are Mac Adam colors that are outside the printer's gamut but physically realizable. These should be rendered smoothly and be pleasing though they will not be accurate. Then there are colors that are real but not possible on a surface. How they are rendered is not something I care about too much though my preference is that hue be maintained. These, can't ever be printed but can appear in photographs with things like red LED Christmas lights . I expect the luminance and saturation to drop but the hue to remain close.


Thanks for this explanation, Doug.  This, Andrew's chart, and actually seeing how the out of gamut colors are rendering in my test prints are challenging a perhaps tribal-like belief I've carried for a while that ProPhoto is the best image processing work space. 

I have been assuming in this post that if I regularly push ProPhoto RGB image data well out of printer and display gamut when processing, then try to pull it all back into print gamut, I'm likely to see image degradation in those out of print gamut colors.  And I've been assuming that the degradation can be seen particularly with problems printing out the charts in this post.  I've also been assuming that the smoothest OOG rendering profile (here to my eye Argyll perceptual) would do the best to minimize the negative affects of post processing manipulations.  If that's not correct, please correct me.

Thinking about your explanation and looking at this chart (https://goo.gl/images/dfpNwg) together with the Granger Rainbow/Bills Balls results, it appears that the largest problem areas in the charts I printed might be the imaginary colors in ProPhoto RGB.  It seems like the imaginary colors are the ones hardest to map to human vision and, for the reasons you state, excluding those in a working space might lead to better results.  Why would we want to include those imaginary colors in a processing work space? 
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Doug Gray on December 28, 2017, 11:14:14 pm

Thanks for this explanation, Doug.  This, Andrew's chart, and actually seeing how the out of gamut colors are rendering in my test prints are challenging a perhaps tribal-like belief I've carried for a while that ProPhoto is the best image processing work space. 

I have been assuming in this post that if I regularly push ProPhoto RGB image data well out of printer and display gamut when processing, then try to pull it all back into print gamut, I'm likely to see image degradation in those out of print gamut colors.  And I've been assuming that the degradation can be seen particularly with problems printing out the charts in this post.  I've also been assuming that the smoothest OOG rendering profile (here to my eye Argyll perceptual) would do the best to minimize the negative affects of post processing manipulations.  If that's not correct, please correct me.

Thinking about your explanation and looking at this chart (https://goo.gl/images/dfpNwg) together with the Granger Rainbow/Bills Balls results, it appears that the largest problem areas in the charts I printed might be the imaginary colors in ProPhoto RGB.  It seems like the imaginary colors are the ones hardest to map to human vision and, for the reasons you state, excluding those in a working space might lead to better results.  Why would we want to include those imaginary colors in a processing work space?

The basic problem is that RGB colorspaces are additive while printer spaces are subtractive. As a practical matter if you want to have a gamut that can print all possible printable colors ProPhoto RGB is the only game in town. One just needs to be a bit careful with it.

I do think there is value in having profiles that produce reasonable looking results, even with extreme OOG colors. Fortunately, you don't need to make prints to do this. Soft proofing will show almost all the effects of extreme color mapping. It's quite accurate only failing when the printed color itself is outside the monitor's gamut.

Also, even sRGB has a lot of colors that can't be printed just like it clips a lot of colors that can be printed. There are about the same number of both. Adobe RGB has far more colors that can't be printed but still has many that can be printed but are outside the Adobe RGB gamut.

See this topic for details and examples:
http://forum.luminous-landscape.com/index.php?topic=107015.0
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Brad P on December 28, 2017, 11:35:46 pm
Thanks, but let me state my question a little differently.  Seeing in Lab the imaginary blue color's luminosity, it was easier to understand why the blue balls turned out so dark and why the different color engines resolve them differently.  Looking at ProPhoto against CIE XY, I can see the imaginary colors in ProPhoto are the blues, and to a lesser extent the greens and even lesser still yellows.  I'm extrapolating (but didn't look in Lab) that one would have the same difficulty bringing those into any visible light colorspace. 

I get the fact that additive and subtractive light color spaces are different and why, but intuitively (and maybe my intuition is quite wrong) in a visible additive and subtractive workspace, it seems as you wrote an easier job to modify saturation, luminance then hue to bring the color closer to "fitting in" a printed gamut.  With the blue colors at least in Lab, I just don't get how one would do that other than playing wth luminosity, and seems like it would be pretty destructive to what the color really is imagined to be anyway.

So actually for the last hour I've been looking for the color space that most closely approximates human vision, which I'm surprised to see turning up in google searches still is 1931's CIE XY, is that right???  I was thinking of toying around with whatever color space I find and granger rainbows that I can make in PS to see how it prints with Argyll using that colorspace as the reference colorspace in the line item command.  Does that make sense?   
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Doug Gray on December 29, 2017, 12:25:40 am
Thanks, but let me state my question a little differently.  Seeing in Lab the imaginary blue color's luminosity, it was easier to understand why the blue balls turned out so dark and why the different color engines resolve them differently.  Looking at ProPhoto against CIE XY, I can see the imaginary colors in ProPhoto are the blues, and to a lesser extent the greens and even lesser still yellows.  I'm extrapolating (but didn't look in Lab) that one would have the same difficulty bringing those into any visible light colorspace. 

I get the fact that additive and subtractive light color spaces are different and why, but intuitively (and maybe my intuition is quite wrong) in a visible additive and subtractive workspace, it seems as you wrote an easier job to modify saturation, luminance then hue to bring the color closer to "fitting in" a printed gamut.  With the blue colors at least in Lab, I just don't get how one would do that other than playing wth luminosity, and seems like it would be pretty destructive to what the color really is imagined to be anyway.

So actually for the last hour I've been looking for the color space that most closely approximates human vision, which I'm surprised to see turning up in google searches still is 1931's CIE XY, is that right???  I was thinking of toying around with whatever color space I find and granger rainbows that I can make in PS to see how it prints with Argyll using that colorspace as the reference colorspace in the line item command.  Does that make sense?

1931 CIEXY isn't the best and it is, to some degree a simplification of human vision but it is the basis for all the colorspaces in current use. Adobe RGB, ProPhoto RGB, CIELAB are all based on 1931 CIEXYZ. and there are precise conversions between each. The use of negative numbers allows any RGB colorspace to cover the entire CIEXY and there have been efforts to extend sRGB to do so. The Academy of Motion Picture Arts and Sciences has done a great deal of work extending both gamut and dynamic range with RGB spaces and has published a lot of open source material to facilitate people working in that biz.

Another thing to consider is that printer profiles don't know about RGB colorspaces. They work in a truncated version of CIELAB called ICCLAB where the a* and b* are limited to +-128. Lots of colors in ProPhoto RGB are clipped when converted to ICCLAB. Still, there are many colors in ICCLAB that also are imaginary. There are also colors that exist but exceed ICCLAB. It can be messy.

But at least all printers (that I have heard about) have gamuts that are inside ICCLAB.

I generally work in ProPhoto RGB unless I know the image gamut fits in a smaller space. But I soft proof and find that's the best way to work and avoid the more peculiar things that can occur with large spaces. But I still soft proof even with sRGB. Lots of colors visible on an sRGB capable monitor that won't print without some shifting.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Brad P on December 29, 2017, 03:18:30 am
Well I’ve spent the night googling and reading to find an RGB color working space best approximating human vision (stimulus colors, no imaginary colors) and the best I could find appears to be CIE RGB.  That ICC profile is in my ColorSync directory so that’s readily accessible.  If there’s a significantly better one I’d appreciate any steers.

Interesting point about the printer workspace, ICCLAB. I imagine that the paper ICC profile would reflect the clipping that ICCLAB would do. If so, that part of the puzzle might be solved in software before the image data is sent to the printer.

I created two granger rainbows in PS both in ProPhoto and ColorSync and, just because it’s getting late, soft proofed them using the Argyll-generated, ProPhoto linked ICC profile.  I was somewhat stunned to see the differences, particularly in hue. The luminance banding did appear to be moderately reduced in the CIE RGB file.  Tomorrow I’ll do a more proper experiment and create an Argyll paper profile linked to CIE RGB and print out the two sets of rainbows for comparison, each printed using the appropriate printer profiles. 

I remain a bit concerned that CIE RGB may not be the right colorspace to be using to approximate stimulus colors. Mapping it out in ColorSync against ProPhoto RGB, although it looks like it may be clipping the correct dark blue colors in ProPhoto RGB (and the greens/yellows), the gamut volume rendered in 3D is roughly only about 2/3rds that of ProPhoto RGB, and from what I’ve been reading tonight and seeing in 2D renderings, I would have expected something more like 90+% overlap.  Hmm.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Doug Gray on December 29, 2017, 11:09:04 am
Well I’ve spent the night googling and reading to find an RGB color working space best approximating human vision (stimulus colors, no imaginary colors) and the best I could find appears to be CIE RGB.  That ICC profile is in my ColorSync directory so that’s readily accessible.  If there’s a significantly better one I’d appreciate any steers.

Interesting point about the printer workspace, ICCLAB. I imagine that the paper ICC profile would reflect the clipping that ICCLAB would do. If so, that part of the puzzle might be solved in software before the image data is sent to the printer.

I created two granger rainbows in PS both in ProPhoto and ColorSync and, just because it’s getting late, soft proofed them using the Argyll-generated, ProPhoto linked ICC profile.  I was somewhat stunned to see the differences, particularly in hue. The luminance banding did appear to be moderately reduced in the CIE RGB file.  Tomorrow I’ll do a more proper experiment and create an Argyll paper profile linked to CIE RGB and print out the two sets of rainbows for comparison, each printed using the appropriate printer profiles. 

I remain a bit concerned that CIE RGB may not be the right colorspace to be using to approximate stimulus colors. Mapping it out in ColorSync against ProPhoto RGB, although it looks like it may be clipping the correct dark blue colors in ProPhoto RGB (and the greens/yellows), the gamut volume rendered in 3D is roughly only about 2/3rds that of ProPhoto RGB, and from what I’ve been reading tonight and seeing in 2D renderings, I would have expected something more like 90+% overlap.  Hmm.

Refer to the CIEXY chromaticity chart show here
https://en.wikipedia.org/wiki/Gamut

There is no RGB colorspace that approximates the CIEXY gamut. It's always a compromise. The RGB colors can all be real colors but they will always leave out some colors outside the triangle they make. RGB colorspaces made from real colors are largest when composed of 3 points on the CIEXY horseshoe. These three points each have only a single wavelength of light. Since all others have zero magnitude any possible print with colors at the corners will be black. This is because only that single wavelength is reflected. Since an illuminant is a continuum, the reflected light will be zero. Colors at these points are only possible with emissive sources such as lasers.

So colorspaces like ProPhoto RGB expands the gamut by introducing imaginary colors. While these don't exist, the larger space allows us to create real, printable colors that otherwise would not be representable in a RGB  colorspace defined only by real colors.

It might be useful to examine the discussion of the CIE 1931 colorspace and how XYZ values are derived from spectral data.

https://en.wikipedia.org/wiki/CIE_1931_color_space
Title: Re: Choices Between Printer Color Profiling Engines
Post by: digitaldog on December 29, 2017, 11:51:41 am

Color, is a perceptual property. So if you can't see it it's not a color. Color is not a particular wavelength of light. It is a cognitive perception, the excitation of photoreceptors followed by retinal processing and ending in the our visual cortex, within our brains. As such, colors are defined based on perceptual experiments.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: digitaldog on December 29, 2017, 11:53:46 am
As a practical matter if you want to have a gamut that can print all possible printable colors ProPhoto RGB is the only game in town.
On the other hand, no printer can produce all of sRGB.
It's a lot about fitting square holes in round pegs.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Brad P on December 29, 2017, 12:46:20 pm
On the other hand, no printer can produce all of sRGB.
It's a lot about fitting square holes in round pegs.

Exactly.  And square holes are probably what I'm knowingly attempting.  Anyway Don Quixote marches on.   

Here's a snapshot of CIE RGB from one of the wikipedia posts Doug sent showing CIE RGB within CIEXY.  What I imagine is there's a bigger RGB workspace that someone smart has drawn within the CIEXY chromaticity diagram that has been thoughtfully optimized to contain the broadest array of colors while still containing no imaginary colors.  I saw earlier suggestions of Don RGB and Beta RGB.  Anyway, I'm going to try one of them of CIE RGB later today.

This all may be a fools errand.  But in the prints here I can visibly see problems likely at least exacerbated by imaginary colors in ProPhoto RGB.  It may well be that those colors rarely or even never will be touched in a normal image processing workflow, but I can imagine in very dark blacks there's some blue.  And I know how I can destroy data in files with pretty powerful tools we have. It very well may be that loosing a larger gamut working space to gain purity in these areas is a trade not worth making.  Certainly that seems to be the opinion of people smarter than me about these things.  But at least it helps me understand a little more about the terms of the trade.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Doug Gray on December 29, 2017, 02:50:08 pm
Exactly.  And square holes are probably what I'm knowingly attempting.  Anyway Don Quixote marches on.   

Here's a snapshot of CIE RGB from one of the wikipedia posts Doug sent showing CIE RGB within CIEXY.  What I imagine is there's a bigger RGB workspace that someone smart has drawn within the CIEXY chromaticity diagram that has been thoughtfully optimized to contain the broadest array of colors while still containing no imaginary colors.  I saw earlier suggestions of Don RGB and Beta RGB.  Anyway, I'm going to try one of them of CIE RGB later today.

This all may be a fools errand.  But in the prints here I can visibly see problems likely at least exacerbated by imaginary colors in ProPhoto RGB.  It may well be that those colors rarely or even never will be touched in a normal image processing workflow, but I can imagine in very dark blacks there's some blue.  And I know how I can destroy data in files with pretty powerful tools we have. It very well may be that loosing a larger gamut working space to gain purity in these areas is a trade not worth making.  Certainly that seems to be the opinion of people smarter than me about these things.  But at least it helps me understand a little more about the terms of the trade.

Brad,

Download the zip file attached to this post:
http://forum.luminous-landscape.com/index.php?topic=114653.msg998229#msg998229

It contains LAB circles every L* 5 from 5 to 95. It's in LAB colorspace so when you view it in proof mode with a printer profile you can see what LAB color gets printed for pretty much any LAB color. It's also useful to see what colors are printable by using the view proof mask which masks out OOG colors. Good way to compare printer profiles.

You can also use it to see where the various RGB color spaces clip by selecting one in soft proof mode and using the gamut mask. It will give you a good idea where printers diverge from RGB colorspaces.
Title: Re: Choices Between Printer Color Profiling Engines
Post by: Brad P on December 31, 2017, 06:03:45 pm
Thanks for that file Doug.  I spent an hour monkeying around with it and all types of profiles, old and new, on my computer.

I got to the point of printing Granger Rainbows in CIE RGB, ProPhotoRGB and a few others except for pressing the print button, feeling economic.  Instead that started me off reading color science materials and assorted web pages about Argyll.  I've decided to skip that step of very good, but still generic print spaces, and pursue as Graeme suggested directly producing TIFF specific profiles using tiffgamut, collink, and cctiff (the latter to embed the profile in the files, then later print in noncolormanaged work flow).  That looks like by all accounts what will get me at least very close to an optimal printing workflow. 

I'm happy with the generic Argyll icc printer profile generated earlier and that should work well for noncritical images.  I still have yet to produce my first print that way, but am working on a set of commands now in a mac textedit file (thanks Alan) today and hope to make my first in a few hours. 

After that, I'll probably use the targen program assuming I get the print workflow worked out and regenerate a smoothed out test patch kit.

One interesting twist on all this is I shoot with Hasselblad and do my raw development in Phocus.  They have their own proprietary workspace they call Hasselblad RGB and Hasselblad L* which, according to their marketing literature approximate Adobe RGB and ProPhoto RGB.  They only approximate those spaces in size, looking at them with ColorThink, and are actually very different.  The Hasselblad L* is missing a lot of suspect dark blue colors (I'm suspecting imaginary colors) in ProPhoto RGB and differs a little in greens and some yellows . . .  I've decided in the interim to bring that colorspace into Photoshop as my working space and see how that works out.  It's probably more geared toward my raw processing too.

Assuming I actually get a print after all this, I guess I'll have to make the donation to Argyll!