Hand Made CGATS Chart

[Brad P]

I've resolved to make a 4000-5000 patch RGB CGATS chart to use for color profiling my printer.  Here's some guiding principles I am thinking about in order of importance.  If you have any suggestions, I'd be grateful.

1. Nail the black and white points with four 0,0,0 and 255,255,255 datapoints.

2. Quite near the black and white points, add a fair number of neutral greys and near neutrals.

3. Somewhat overpopulate neutrals and near neutrals throughout.  Doug Gray convinced me of this a while ago.

4. Somewhat overpopulate midtones (including colors) on the theory that those are more important than extreme black and white gradations.  I imagine this would be beneficial because variations in midtones seem visually more powerful (e.g., clarity and vibrance).  Likewise, in post processing, those tones are extended more so than others.

5. Somewhat underpopulate extremely saturated colors on the theory that those rarely occur and if they do, more sparcely populated data points will work OK.

6. Randomize the patches.

7. Stick with integers of 17, 15 (and 5 near the white/black points as well as along the neutrals).  I imagine there's some complex math going on in the algorithms used to generate ICC profiles.  I have no clue how those work, but I can imagine it's at least possible better results can be had by using whole integers representing whole fractions of 255.  Dunno, but I need to stick with whole integers anyway because of my setup (HPZ3200, i1Profiler, and Argyll).

8. Review the CGATS file by hand to eliminate obvious close datapoints.

I understand there are variations possible for printers, papers, inksets, ink cartridges and the like.  I'm not attempting to make any adjustments for those.  I realize this probably is a fools errand.  Maybe appropriately at the end, I'll at least have a file named bradCGATS.txt

Happy to share the CGATS file when I'm done and as I go with those who contribute. 

[Brad P]

Reading this over a bit later, I’m adding:

9. Fill in skin tone related data points in relatively blank areas.  It’s a quite narrow range, but worthwhile. 

[Mark D Segal]

What application do you intend to use for reading your chart and how can you be certain that the manner in which you design the patch set will lend itself to optimal tone and colour mapping in the profile? A relatively small number of data points is being used to create equations that will map a huge universe of colours, so the quality of that mapping would seem to be critical.

[Alan Goldhammer]

Brad,

I use Argyll to profile my Epson 3880 with an i1 Pro and have found that it does address a number of the points that you list in the first post.  Since I hand read the patches using the supplied ruler, I want reasonable size patch sets.   My approach is to do a 924 patch preconditioning profile (2 letter pages), followed by a 1848 patch final profile based on the preconditioning profile (4 letter pages).  I add a 51 step B/W patch set for the second step and use N0.6 setting to get near neutral value emphasis.  The profiles are good and the color rendition on test prints is accurate.  I do look import the final data into Excel and look to see if there are any patches that appear to be wildly off but in my experience this approach gives me a low standard error. 

[digitaldog]

My approach is to do a 924 patch preconditioning profile (2 letter pages), followed by a 1848 patch final profile based on the preconditioning profile (4 letter pages).

Post optimization which can improve the profile a tad (or not at all) but a good tactic to reduce the number of color patches needed based upon creation of the initial profile and initial patches used.
I've built profiles commercially for Epson, using 5000 patches in the days prior to post optimization and today, I'll stick with Bill Atkinson's 1729 initial patch set, I've not see more patches do anything useful compared to Bills. Then if desired by the client, a 2300 patch post optimization target I designed using lots of neutrals and very saturated colors extracted from images.

[Doug Gray]

I've found a few things optimizing patch sets for my two printers, Epson 9800 and Canon 9500.

These two have very different native responses. In particular the 9800 has a very lumpy response along the neutral axis and this is where accuracy is most critical. The near neutrals are very sensitive to small hue/saturation errors. The perceptual sensitivity along the neutrals is as much as 6 times the sensitivity in more saturated areas. So I have focused a lot of effort on improving the 9800. It's paid off. The 9800, in spite of the lumpy native response, produces more repeatable results than the 9500 which drifts more over the life of it's ink cartridges.

So, my 9800 requires a lot of neutrals and near neutrals in order for the profile to best print these. The 9500, OTOH, has a far smoother near neutral response.

Both of these printers benefited from the second, optimizing pass in I1Profiler.

Once you have a good, performing, patch set for a printer, the same set can be used for all papers of the same rough type. So, for each printer, I have one set for glossy/luster/semigloss  and another for matte.

For both the 9800 and 9500 I start with the i1sis default patch set for letter size (957 patches) then do an optimizing pass generating another 957 patches. This is sufficient for the 9500. For the 9800, I add a large set (another 957) of near neutral patches.

One major gripe I have about all this is the tools extant for evaluating profile accuracy are essentially non-existent. The standard approach is to compare the profile target's spectro measured Lab values with those calculated from the generated profile. Since the profile was generated from those same patches the results are self referential and they do not correlate very well as a result. Worse, one can have overfitting which will show a lower dE error on the target patches but a much higher error on another set. Getting a useful metric on profile accuracy requires printing a set of colors that are independent of the colors used when creating the profile. I use custom Matlab functions to do this and evaluate the results. While it solve my needs, there is a real need for commercial tools that do this in a consistent way that could be applied by many to a variety of printers.

[digitaldog]

One major gripe I have about all this is the tools extant for evaluating profile accuracy are essentially non-existent. The standard approach is to compare the profile target's spectro measured Lab values with those calculated from the generated profile. Since the profile was generated from those same patches the results are self referential and they do not correlate very well as a result. Worse, one can have overfitting which will show a lower dE error on the target patches but a much higher error on another set. Getting a useful metric on profile accuracy requires printing a set of colors that are independent of the colors used when creating the profile. I use custom Matlab functions to do this and evaluate the results. While it solve my needs, there is a real need for commercial tools that do this in a consistent way that could be applied by many to a variety of printers.

Forgive the copy and paste but this is how Bruce Fraser taught me to do this although I find printing images (Roman 16's certainly) provide more 'useful' data for me personally:

Bruce's profile tests:

But here's a way to test the differing tables (it's kind of complicated). We'll use a target we call 216pixel_RGBs.tif as an example, use the iStar or whatever patch set you wish.
So there are a number of ways to tackle this depending on what you're looking to judge.
One simple way is to simply compare the reference values that created the target to the measured values of the target run through the printer. But that only provides an overall accuracy report, not specifics. But the idea is, you've got an RGB value that's a reference and an RGB value from the measurement of the target itself. Conduct a dE report in ColorThink.
But here's a way to test the differing tables (it's kind of complicated). We'll use a target we call 216pixel_RGBs.tif as an example, use the iStar or whatever patch set you wish where 1 pixel is one color patch:
1. Open the “216pixel_RGBs.tif file in Photoshop. This file needs to be kept exactly as it is (individual pixels). Duplicate the file. Size the image using Nearest Neighbor to an appropriate print size. Call this “Reference Print File”. You'll print this out and measure.
2. Print this file out to the profiled printer. (You're sending the RGBs in the file to the printer.)
3. Let the print stabilize, and then measure it and save the data as “Reference Labs.txt”. The 216 RGB.TXT file (a reference file that built this target) needs to be installed for MeasureTool or PatchTool or whatever software you'll use to access access the data. This data measured is the bottom line -- what happens when you send these RGBs to this device.
4. Now you need to create predicted Lab files from the RGB. You need two versions -- one in pixels to compare in ColorThink, one upsampled to print -- for each profile.
5. Take the RGB pixel file and Assign the printer profile. Convert Abscol to Lab. Save the results with the profiling package somehow identified in the filename (eg “i1P 288 Luster/Predicted”).
I suggest saving the pixels versions as ProfilePackageName Predicted Labs.
6. Take the upsampled RGB file. Assign the printer profile. Convert Abscol to Lab. Convert from LAB to printer profile being tested using absocl and print.
7.Let the print stabilize and measure the results. Save the measurements as ProfilePackageName Roundtrip Labs (“i1p 288 Luster Round Trip”).

You now have three things to compare for each package:
A. The Reference File (“Reference Labs.txt”). The Predicted Labs (“i1P 288 Luster”). The Roundtrip Labs (“i1P 288 Luster Round Trip”).
B. Reference-to-Predicted (“Reference Labs.txt”/“i1P 288 Luster”) shows you the accuracy of the AtoB Colorimetric table.
C. Predicted-to-Roundtrip (“i1P 288 Luster”/“i1P 288 Luster Round Trip”) shows you the accuracy of the BtoA Colorimetric table.
Reference-to-Roundtrip (“Reference Labs.txt”/“i1P 288 Luster Round Trip”) gives you a decent measure of the overall profile accuracy.
You'll typically see that the AtoB and BtoA errors tend to cancel each other somewhat because they go in opposite Directions-Reference-to-Roundtrip shows that nicely.

[Doug Gray]

Forgive the copy and paste but this is how Bruce Fraser taught me to do this although I find printing images (Roman 16's certainly) provide more 'useful' data for me personally:

Bruce's profile tests:

But here's a way to test the differing tables (it's kind of complicated). We'll use a target we call 216pixel_RGBs.tif as an example, use the iStar or whatever patch set you wish.
So there are a number of ways to tackle this depending on what you're looking to judge.
One simple way is to simply compare the reference values that created the target to the measured values of the target run through the printer. But that only provides an overall accuracy report, not specifics. But the idea is, you've got an RGB value that's a reference and an RGB value from the measurement of the target itself. Conduct a dE report in ColorThink.
But here's a way to test the differing tables (it's kind of complicated). We'll use a target we call 216pixel_RGBs.tif as an example, use the iStar or whatever patch set you wish where 1 pixel is one color patch:
1. Open the “216pixel_RGBs.tif file in Photoshop. This file needs to be kept exactly as it is (individual pixels). Duplicate the file. Size the image using Nearest Neighbor to an appropriate print size. Call this “Reference Print File”. You'll print this out and measure.
2. Print this file out to the profiled printer. (You're sending the RGBs in the file to the printer.)
3. Let the print stabilize, and then measure it and save the data as “Reference Labs.txt”. The 216 RGB.TXT file (a reference file that built this target) needs to be installed for MeasureTool or PatchTool or whatever software you'll use to access access the data. This data measured is the bottom line -- what happens when you send these RGBs to this device.
4. Now you need to create predicted Lab files from the RGB. You need two versions -- one in pixels to compare in ColorThink, one upsampled to print -- for each profile.
5. Take the RGB pixel file and Assign the printer profile. Convert Abscol to Lab. Save the results with the profiling package somehow identified in the filename (eg “i1P 288 Luster/Predicted”).
I suggest saving the pixels versions as ProfilePackageName Predicted Labs.
6. Take the upsampled RGB file. Assign the printer profile. Convert Abscol to Lab. Convert from LAB to printer profile being tested using absocl and print.
7.Let the print stabilize and measure the results. Save the measurements as ProfilePackageName Roundtrip Labs (“i1p 288 Luster Round Trip”).

You now have three things to compare for each package:
A. The Reference File (“Reference Labs.txt”). The Predicted Labs (“i1P 288 Luster”). The Roundtrip Labs (“i1P 288 Luster Round Trip”).
B. Reference-to-Predicted (“Reference Labs.txt”/“i1P 288 Luster”) shows you the accuracy of the AtoB Colorimetric table.
C. Predicted-to-Roundtrip (“i1P 288 Luster”/“i1P 288 Luster Round Trip”) shows you the accuracy of the BtoA Colorimetric table.
Reference-to-Roundtrip (“Reference Labs.txt”/“i1P 288 Luster Round Trip”) gives you a decent measure of the overall profile accuracy.
You'll typically see that the AtoB and BtoA errors tend to cancel each other somewhat because they go in opposite Directions-Reference-to-Roundtrip shows that nicely.

Yep, with a separate set of patches from those the profile was generated from this can give a good metric of profile quality as well as providing some info on the consistency of the AtoB and BtoA tables.

Using matlab I would, given an rgb set, type:
MakeIsisPatches2(rgb, 'ProfileTest');

This generates a time stamped, labeled, 16 bit tif file if the RGB values have fractional components otherwise an 8 bit file. It's formatted to i1Sis specs and can be printed w/o color management then scanned. It also saves a reference CGATs file for loading into the I1Profiler. When the measurements are saved, all the RGB data as well as Lab, XYZ, and spectral data are saved together.

The same process is used for Lab or even RGB values in a colorspace. I have a set of Lab values that evenly span the gamut of both my printers and are inside the gamut of both. These are doubled up and randomized. Then, to test a profile I do this:

MakeIsisPatches2(ProfileConvert(labref, 'printerprofile', 'f', 3), 'PrinterLabTest')

This creates an i1Sis ready chart and CGATs file. When scanned the Lab data is compared to the reference Lab data. The advantage of this approach is that the quality of a profile can be evaluated for different printers using the same color set which has evenly spaced colors across the printer's gamuts. Since the colors are printable by both printers, it's a good way to check both the profile quality (ave dE) and the printer's ability to print consistently (variance between the duplicated colors).

[GWGill]

7. Stick with integers of 17, 15 (and 5 near the white/black points as well as along the neutrals).  I imagine there's some complex math going on in the algorithms used to generate ICC profiles.  I have no clue how those work, but I can imagine it's at least possible better results can be had by using whole integers representing whole fractions of 255.  Dunno, but I need to stick with whole integers anyway because of my setup (HPZ3200, i1Profiler, and Argyll).

This really depends on your workflow and the profiling tools. If your workflow rounds to 8 bit, then ideally you should only use 8 bit test value. But if your workflow is 16 bit, there is no need to round to 8 bit.

Note that if you have an 8 bit workflow then using ArgyllCMS tools you can:

* Round to 8 bits using the printtarg -Q8
* or emulate a 16 bit workflow by using dithering using printtarg -t -D

ArgyllCMS's profiling code is all floating point, so it has no requirement relating to 8 bit values.

As an aside, I've found that using regular grids of test values is generally a bad idea, as it encourages less constrained interpolation within the grid cells. Having more stratified or random samples that do not leave systematic "tunnels" through the color space are better. (ArgyllCMS's default OFPS distribution is sufficiently random to avoid these sorts of problems.)

[Brad P]

Thanks Graeme, that makes sense.  I've done a little bit of work already, but may actually scrap what I've done and pursue randomized patches with targen for the reasons you state.  Additionally, I'm realizing the method I'm slowly pursuing -- adding data points by theme -- is problematic in how I manage for duplication and near misses.  It can be done, it just feels a bit ad hoc as I'm doing it.

Ironically I was looking at targen earlier today thinking about how I might use that instead.  I'm going to sleep on it, but I think I'm going to scrap my spreadsheet and instead start with a 6,000 or 7,000 patch randomized targen data set.  Then instead of adding regular integers, I'd work backward toward a 4000 patch set by deleting samples.  I'm pretty sure sorting integers and using some absolute value metrics in Excel I can (a) delete samples skewing the deletions more heavily in the shadows and highlights -- being sure to preserve at least four 0,0,0 and 255,255,255 and nearby datapoints as anchors as well as probably most anything with a 0 or 255), then (b) delete samples skewing the deletions further away from the midtones.  Through the deletions I'd reintroduce regular integers and/or math, but that would at least be obscured by the original random datapoints and I could try to make it more obscure as I can as I go.

Today I’ve reread several times an interesting post by Ethan Hansen here.  Ethan’s considerable work there suggests a few additional things people reading this might want to consider.

1. At least so far, i1P patchsets seem to include (a) a regularly spaced integer grid together with (b) a near neutrals data set.  See the two charts in Ethan's post. 

2. i1P's near neutrals data set appears to fan out from a narrow range in the blacks to a wider dispersion in the whites range.  See the second chart.  Why that is done?  Does it serve a purpose or would a more even dispersion from black to white be better?

3. Ethan’s measured and subjective results suggest equal numbers of R, G and B data sets.  Maybe some math within i1P doesn't recognize the overall imbalance and correct for it?  Dunno about Argyll or other color engines, but maybe as a precaution that's something important I will control for.  That also suggests screening for R, G and B biases in the data, and moving around -- not adding -- datapoints in the skin tone zone to make sure it's well covered.

BTW, my spectrophotometer is in my HP Z3200ps printer.   It’s i1P based hardware with mostly unknowable software.  Although we've found ways to hack into it pretty well, I do know it limits me to 8 bits and minimal statistics.  I'll publish what I can but it will be pretty cursory.

[Rhossydd]

2. i1P's near neutrals data set appears to fan out from a narrow range in the blacks to a wider dispersion in the whites range.  See the second chart.  Why that is done?

I would have thought that pretty obvious. The eye differentiates slight colour casts in near whites easily, but doesn't see the same colour shifts in near black.

[Mark D Segal]

.............  It can be done, it just feels a bit ad hoc as I'm doing it................

You have so far chosen to ignore what I asked you in Reply #2 above, but it was a serious question in hope of a serious answer from any one reading this thread. I may be mistaken, but I don't think a colour management engineer or scientist would go about designing a patch set this way. There must be some manner of principles or theory or lessons of experience that would help guide one in choosing how to design a patch-set fit for purpose. And if any of that exists, it would seem likely that those principles, theories, lessons of experience have already been designed into how existing colour management applications configure patch sets, subject to user-selected parameters. That doesn't mean as individuals we shouldn't try to be creative on our own, but it strikes me as sensible to start from a reliable procedural basis and that is what I seeking to learn more about. With that in hand, one has a framework within which to evaluate ideas and options.

[GWGill]

2. i1P's near neutrals data set appears to fan out from a narrow range in the blacks to a wider dispersion in the whites range.  See the second chart.  Why that is done?  Does it serve a purpose or would a more even dispersion from black to white be better?

The thing about neutral patches, is that you don't know what device values will produce those patches until you've made a profile (Catch 22). One way around that is to do a profile and then use that to generate neutral patches for a second profile. The most basic single pass approach is to use a set of patches that are likely to encompass the neutrals.

[GWGill]

And if any of that exists, it would seem likely that those principles, theories, lessons of experience have already been designed into how existing colour management applications configure patch sets, subject to user-selected parameters.

Yep. ArgyllCMS OFPS (Optimised Farthest Point Sampling) is my best attempt at a way of creating such patch sets.

[Mark D Segal]

Thanks Graeme.

[Doug Gray]

Yep. ArgyllCMS OFPS (Optimised Farthest Point Sampling) is my best attempt at a way of creating such patch sets.

Graeme, I really need to compare it to what I1P does and an approach I briefly explored before transitioning into trying to find the best way to deal with the gross, nonlinearities on the neutrals that afflicts my 9800. Wound up using a lot of extra near neutrals clustered around the problem areas. The I1P grid spacing at 37^2 did a good job and produced very slightly better neutrals that Argyll with the -qh option. The -qh level works very well generally though. As good as the I1P even with its finer grid. Didn't try the ultra though. Argyll makes good use of shaping curves which I1P does not so I1P requires more grid points for the same quality. However, the problematic 9800's sharp gradient (along L*, and b* especially) changes in the neutrals benefits more from the smaller grid spacing.

This is what I explored on the I1P side:

Some time back I did an experiment where I made a profile using a 11x11x11 grid, which is fractional, printed from a 16 bit tif (Photoshop dithers nicely, even printing w/o color management to 8 bit drivers). Then, I interpolated grid points that were spaced 2 apart and compared that to the actual grid points. An additional patch set was made around the points with the largest error, on a 21x21x21 grid filling up the 1331 patch set to the 1914 patches that fit nicely on 2 letter sheets. This produced good results with the average dE00 on about 400 independent, in gamut colors, dropping from around .6 to .45. However, I got the same results letting I1Profiler generate additional colors so I didn't pursue it further. Possibly, printing a smaller grid spacing of, say a couple thousand patches only around the points of maximum deviation, would produce a very printer specific set of patches. The grid spacing I1P uses in high quality mode consists of 50k points so no risk of hitting a tunnel on the AtoB side.  The BtoA side has bigger issues since there is always a sharp gradient change at the gamut boundary and that shouldn't exist for the AtoB side unless the OEM's screwed up the driver design.

[Doug Gray]

The thing about neutral patches, is that you don't know what device values will produce those patches until you've made a profile (Catch 22). One way around that is to do a profile and then use that to generate neutral patches for a second profile. The most basic single pass approach is to use a set of patches that are likely to encompass the neutrals.

Yep, The maximum RGB spread along the actual, neutral axis of RelCol turned out to be about 11 with a max deviation from the average of the two non-outliers, was about 7. This is a bit inside the near neutral spread I made for the gross gradient changes along the 9800 neutrals. The spread on my 9500 was smaller and doesn't have significant gradient shifts. Unfortunately, the 9500 suffers considerably more variation from other effects. In particular a sort of history effect where the colors it has recently printed on a line impact others in the same line. As much as 1 dE76. The 9800, even with it's abrupt gradient shifts, is much more consistent and doesn't suffer this weird history effect.  No idea how other printers compare to these two but I don't want to clutter my space up with more printers to find out.

[Brad P]

What application do you intend to use for reading your chart and how can you be certain that the manner in which you design the patch set will lend itself to optimal tone and colour mapping in the profile? A relatively small number of data points is being used to create equations that will map a huge universe of colours, so the quality of that mapping would seem to be critical.

Hi Mark.  Apologies for not replying earlier.  Neither my equipment nor my profiling experience is as good or extensive as yours to be sure, and I do respect your opinion on these things even if I haven’t replied. 

I’m presently constrained to using the spectrophotometer embedded in a 6 year old HPZ3200, which is marketed as an i1P device, and the software that it uses is embedded as best as I can tell in a black box admixture of HP and i1P collaborative efforts. The process it uses was exposed (“hacked” is maybe too strong a term) a year and a half ago by Geraldo Garcia and Mark Lindquist in a post here.   That basically opened up an opportunity for Z3200ps owners to experiment with other profiles (not only the limited menu embedded in the Z3200ps), such as those generated by i1P, ArgyllCMS’s tangen, other software manufacturers or otherwise available, and then process the txt data results in various applications, most commonly Argyll CMS but others too. 

My own experience can be benchmarked as nearly 50 years of off and on experience as an enthusiast gear head photographer, the last 6 years full time, 12 years of medium and large format printing and working with prefabricated profiles, and 1 1/2 years playing around occasionally with deeper dives into printer profiling.  Geraldo’s post marks the time when I became interested in experimenting with various profiles and color engines out there and also reading a bit about the process.  I’m humbled a bit and a fan of everyone here who has replied to this thread and have read more of what you’ve written than you probably want to know.  I think now I can even comprehend half of what Graeme writes nowadays. 

I appreciate that much has gone on before by much more studied people, there is great work out there that can be just plugged in, and there is much about the color sciences that I’ll never know.  I also appreciate that it’s not a concluded science, and that there is room for experimentation, possibly even in the way I am proposing here.  In any event, my post here was inspired partly by a standing desire to take a hand at making my own profiles just because I can, partly by just having migrated from an Apple to a PC (and setting up the color workflow again in Windows (sheesh)), but mostly by my experience with a post and profile generated by Doug late last year seeking a smaller, more optimum profile. 

In that post, Doug shared his work with his 9800 that included a huge sample of near neutrals with a smaller color grid.  Doug stated there that his primary aim was to correct for imbalances he measured with near neutrals in that printer.  There was also some discussion I believe in that post (but I believe I’ve read it elsewhere as well) that getting the hues aligned along the neutral axis was critical to the perceived quality of a profile.  This makes sense to me in the sense that reds and yellows in an otherwise blue/neutral zone of a picture could be distracting.  I loaded up Doug’s patch set and tried it out on a set of problematic pictures I had been printing at the time and at least to my eye and with my printer I saw improvements. 

That experience made me appreciate that more heavily sampling neutrals could lead to better neutrals.  The question it left me with was, what else?  That what else is what I am currently exploring.  In my own photography, I can be pretty brutal in post, using luminosity curves and the like to exploit areas of photographs that I think need it. Soft proofing such areas can assist in the violence that our modern tools can do to pixels nowadays.  The midtones appear to my eye to be more important in that respect than extreme highlights and shadows.  Thus, I wonder if oversampling the midtones might be helpful too.  Likewise, to my eye differences in heavily saturated colors seem to blend into each other more so than subtle, less saturated gradations.  And in the heavily saturated colors of a heavily processed file sometimes reside imaginary colors that simply don’t visually make sense.  When those are brought into a saturation levels with our tools that should make more sense, it would be nice to see and print those better.  Likewise, skin tones. 

Anyway, I’m using the term “oversampling” a lot here, because I have been thinking about this in the context of an already large patch set.  My intention in the large patch set is to have enough in the background (the lesser sampled colors) that it would still be reasonably good. 

Anyway, typing all this out makes me agree with you that it probably is helpful to at least understand where I’m coming from and what I maybe still foolishly intend to do. 

[samueljohnchia]

The I1P grid spacing at 37^2 did a good job and produced very slightly better neutrals that Argyll with the -qh option. The -qh level works very well generally though. As good as the I1P even with its finer grid.

Hi Doug, one issue I've not been able to overcome with i1Profiler is that working space black (RGB 0,0,0) does not map to printer black 0,0,0 in device space. Early versions of i1Profiler attempted to aggressively neutralize blacks which several users complained about, and later versions would neutralize printer max black less to retain better dmax. What we really need is a switch to turn it off, and only turn it back on if one really desires neutral blacks, which I seem to recall some of the photolab printers have trouble producing. ArgyllCMS correctly maps black to 0,0,0 in printer space. CoPra gives you the option during the profile build stage on whether you want to neutralize dmax or not, which is nice, but for profiling the inkjet printers most photographers use for fine printing, we could care less that dmax is slightly non-neutral. Especially so when printing on matte media - we need all the dmax we can get for a really solid feeling in the print.

I did an investigation a while back comparing a 52 stepwedge (RGB 5 point increments from 0 - 255), measured on my iSis XL for profiles generated by i1Profiler V1.6.3 and ArgyllCMS V1.8.3. I've not tested later versions of i1Profiler since but I do know that later versions of ArgyllCMS renders the grayscale the same. The printer is a Canon iPF8400 and paper is Epson Hot Press Natural. Both profiling software do quite well in maintaining neutrality in the grayscale, as you can see in the a* and b* graphs in the attachment, with ArgyllCMS actually being slightly better, especially the Perceptual.

I feel the all-round best a* and b* curves for the best looking result, assuming that paper white isn't too far from a neutral tint, is to remain at that a* and b* value until about L*30, then smoothly and gradually curve towards wherever the dmax is, without neutralizing the dmax.

Also, unfortunately, i1Profiler's Perceptual L* tonality is S-curve shaped (contrast setting during the profile build was set to 0, which is already lower than the default), causing midtones to get lightened way too much, destroying the tonal relationships so carefully designed during the post processing part of the workflow. The ideal tone curve for Perceptual rendering should be what we get for RelCol with BPC applied. I regard the Perceptual rendering intent as vital for printing all kinds of regular photographs because of the importance of mapping the out of gamut colors properly into printer gamut. None of the current available profiling software today does it correctly, and despite the ability of ArgyllCMS to perform "smart" mapping by having the user define the source gamut, we still do not have total control over what kind of mapping occurs (luminance vs saturation tradeoffs). There is also the wrong idea that in-gamut colours must be shifted to accommodate out-of-gamut colours for Perceptual mapping because most people wrongly try to evaluate their profile's mapping with synthetic gradients. Rather than drive this completely off-topic, if you are interested in a longer treatise of this, here's the link to my post on the ArgyllCMS list.

Graeme, I really need to compare it to what I1P does and an approach I briefly explored before transitioning into trying to find the best way to deal with the gross, nonlinearities on the neutrals that afflicts my 9800.

Perhaps since my iPF8400 is quite smooth in its behaviour throughout its gamut, I've noticed that ArgyllCMS OFPS (Optimised Farthest Point Sampling) has zero benefit in my investigations. Perhaps for a non-linear printer like yours with kinks in the gamut, it could prove to be more useful. However, i1Profiler's mapping algorithm, according to Ethan Hansen, is not as capable of handling patch sets which are equidistant and balanced in orthogonal measure (equidistant in RGB space rather than printer space). Graeme has mentioned to me that ArgyllCMS fares slightly less well with equally spaced data, though my experiments have not been able to reveal this on my printer. Thus I've stuck with my original 2808 custom patch target with its visually ordered patches. I like visually ordered patches as it makes it very easy to spot printing issues before measurement even takes place, though this only works with iSis measurements. If measuring with an i1Pro 2 in scan mode, for i1Profiler versions later than V1.3.2, visually ordered patches measurements are thrown off by the new patch detection algorithm, causing patches further down the line to be increasingly "polluted" by greater and greater contribution of prior patch measurements. Only the early versions of i1Profiler work well when scanning visually ordered patches with the i1Pro.

The thing about neutral patches, is that you don't know what device values will produce those patches until you've made a profile (Catch 22). One way around that is to do a profile and then use that to generate neutral patches for a second profile. The most basic single pass approach is to use a set of patches that are likely to encompass the neutrals.

I'm getting ready to profile a HP Indigo press, which probably might be able to benefit visibly from ArgyllCMS OFPS patch distribution. For CMYK profiling it's even harder to guess where the neutral spine is than for RGB. Argyll's ability to be able to specify a source profile's gamut in which to sample in device space for a "fitted" patch set seems ideal in this situation. If only the Perceptual mapping could be even better.

Edit: add attachment

[samueljohnchia]

Thanks Graeme, that makes sense.  I've done a little bit of work already, but may actually scrap what I've done and pursue randomized patches with targen for the reasons you state.

Today I’ve reread several times an interesting post by Ethan Hansen here.  Ethan’s considerable work there suggests a few additional things people reading this might want to consider.

1. At least so far, i1P patchsets seem to include (a) a regularly spaced integer grid together with (b) a near neutrals data set.  See the two charts in Ethan's post. 

Hi Brad, Ethan is correct in relation to how i1Profiler works. It's math is not as sophisticated as Argyll's and in fact does work better when the patches are balanced in orthogonal space. Regularly spaced RGB steps. Otherwise, you might notice smoothness issues and kinks in the profiles it generates. Graeme is correct in relation to how his ArgyllCMS works. So you have to design the optimal target for not just your printer, but also for your profiling software of choice.

2. i1P's near neutrals data set appears to fan out from a narrow range in the blacks to a wider dispersion in the whites range.  See the second chart.  Why that is done?  Does it serve a purpose or would a more even dispersion from black to white be better?
I would have thought that pretty obvious. The eye differentiates slight colour casts in near whites easily, but doesn't see the same colour shifts in near black.

I would have thought that pretty obvious. The eye differentiates slight colour casts in near whites easily, but doesn't see the same colour shifts in near black.

Like youself I've puzzled over that for a while, and I think Rhossydd's thinking is incorrect. In fact that would be the precise reason for wanting finer sampling in near-whites since we would be more sensitive to shifts in hue there. I believe the primary reason is that it's very difficult for printers to build colour hues near white. You start with paper white and the printer only allowed to put a tiny amount of transluscent ink to get different colours. It is easier to get subtle hues in heavily inked areas. When I made up custom patch sets with the near neutrals spaced evenly 3 points out from neutral (equal value) RGB, the lightest colours could not be measured reliably by the i1Pro 2 nor the iSis XL. Frequently they are being read as the same spectrally, which causes kinks in the profiles built, crushing the highlights resultantly. Usually spectrometers face greater problems measuring dark colours because of noise, but in this case with ultra light colours, I think that it is because the ink and paper is not opaque at the surface, so due to the measurement geometry, a significant amount of the light measured is passing under the ink dot, through the paper fibers and out again, making it difficult to measure very subtle hue shifts in light colours.

However, I do think that the default spread by i1Profiler is much too wide in the highlights and actually much too close in the shadows. It deviates by 1.22 constantly for the i1Profiler smart patch generator. I use a formula which gives me near neutrals which are equally spaced out from the neutral spine for the shadows, while introducing a more gradual spread towards paper white.