Printer profile construction

[rasworth]

I'd like to know the basis for the size of the CLUT tables in i1Profiler generated printer profiles.

I use the high quality settings in i1Profiler, and the BtoAx tables are always generated the same.  Using ICCProfileInspector (attached image) I can see three inputs, L* - a* - b*, each has 37 entries.  I'm assuming L* goes 0 -100, an a* and b* -128 to +128 (127?) with 18 being the 0 point.

In the image I have set all three sliders to 18, should represent L* = 50, a* = 0, b* = 0, the output RGB seems about right.  The tag contains 340,00 bytes, which I can rationalize as 37 x 37 x 37 x 2(16bit entries) x 3 channels = 304,000 plus some sort of overhead.

So why 37 for the CLUT dimension?  Seems like a strange choice.

Richard Southworth

[Doug Gray]

I'd like to know the basis for the size of the CLUT tables in i1Profiler generated printer profiles.

I use the high quality settings in i1Profiler, and the BtoAx tables are always generated the same.  Using ICCProfileInspector (attached image) I can see three inputs, L* - a* - b*, each has 37 entries.  I'm assuming L* goes 0 -100, an a* and b* -128 to +128 (127?) with 18 being the 0 point.

In the image I have set all three sliders to 18, should represent L* = 50, a* = 0, b* = 0, the output RGB seems about right.  The tag contains 340,00 bytes, which I can rationalize as 37 x 37 x 37 x 2(16bit entries) x 3 channels = 304,000 plus some sort of overhead.

So why 37 for the CLUT dimension?  Seems like a strange choice.

Richard Southworth

It's fairly arbitrary. The grid point spacing on the a* and b* is 256/(37-1) which is about a spacing of 7. For L* it's 100/(37-1) or a bit under 3 L* spaces. Assuming the printer driver response is reasonably linear at these increments, this works well for L* but a* and b* suffer from a kind of scalloping at the gamut edges where a* and b* hit their limits. This is rarely visible since dE00 is less sensitive on more saturated colors.

[rasworth]

Doug,

I assume most of the values in L*a*b* space are out of gamut - is the gamut tag used in conjunction with the btoax tags to identify OOG?  I notice the gamut tag appears to return 0 for in gamut, and non-zero for OOG?

Thanks,

Richard Southworth

[Doug Gray]

Doug,

I assume most of the values in L*a*b* space are out of gamut - is the gamut tag used in conjunction the btoax tags to identify OOG?  I notice the gamut tag appears to return 0 for in gamut, and non-zero for OOG?

Thanks,

Richard Southworth

The OOG tag isn't used my CMEs for determining the device colors to print, it may be used by some apps for flagging gamuts as it requires only one lookup direction. For soft proofing one just converts from LAB space to device RGB which determines what gets printed. All device RGB numbers map to a PCS (usually Lab) color which is a good estimate of what gets printed. Typically, OOG colors are mapped to the closest point on the D gamut but there is no rule requiring it. Some prefer to map to the closest point while retaining hue angle and/or luminance. It's up to the profile software maker and is not spec'ed by the ICC.

And that's for Rel. Col. and Abs. Col. Perc. is a whole different can of worms as there is no notion of being out of gamut. Soft proofing is the only useable technique in using Perceptual. OOG masking is essentially meaningless in that mode.

[rasworth]

Doug,

Thanks, and here is my flight of fancy - it would seem there is enough "information" in a normal printer profile to engineer a group of rgb values that are close to the CLUT points.  One would have to interate L*-a*-b*, check the resulting rgb values for oog or not, and include them in the target patches if in gamut.  The goal would be increased accuracy because the rgb values map in printer color space nearer the final CLUT points, with a smaller patch count.

Sort of a three dimensional version of your neutrals training.

Richard Southworth

[rasworth]

Back to profile innards.

I examined the BtoA1 tag, the colorimetric CLUT.  To my surprise, if I set a* and b* to 0 (18 in the CLUT) and moved the L* lever from 0 to 36, the rgb values ranged from 36-36-36 to 219-219-219.  Confusing, what happened to the blacks and highlights the printer is able to render?

Then I looked at the output channel curves (attached) - they are constructed to expand the restricted rgb space back out to 0-0-0 to 255-255-255.  WHY does i1Profiler do this?  Hard to make any sense out of it.

Richard Southworth

[Doug Gray]

Back to profile innards.

I examined the BtoA1 tag, the colorimetric CLUT.  To my surprise, if I set a* and b* to 0 (18 in the CLUT) and moved the L* lever from 0 to 36, the rgb values ranged from 36-36-36 to 219-219-219.  Confusing, what happened to the blacks and highlights the printer is able to render?

Then I looked at the output channel curves (attached) - they are constructed to expand the restricted rgb space back out to 0-0-0 to 255-255-255.  WHY does i1Profiler do this?  Hard to make any sense out of it.

Richard Southworth

It makes the math easier and prevents underflow/overflow with 16 bit unsigned values that actually represent signed values that are offset. If you want to see something interesting, look at the pre and post curves from an Argyll profile. They use curves to reduce the need for more grid points and the curves are generated depending on the printer characteristics. This is essential when using XYZ as the PCS. Higher grid counts allow linear curves and are (or can be) faster for the CME to compute.