[argyllcms] Re: "Coping" with small differences in shadow details

  • From: Gerhard Fuernkranz <nospam456@xxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Sat, 21 Dec 2019 18:45:14 +0100

Am 21.12.19 um 00:47 schrieb graxx@xxxxxxxxxxxx:


Before profiling my printer, in RGB mode, I am curious how “ICC profiling” 
technology “copes” with small differences in shadow detail? Below is a link to 
a screen capture, in Excel, showing the device data and measurements taken in a 
range between  RGB=64,64,64 and 0,0,0 on my printer, in increments of 12, with 
color management turned off in the driver:

https://1drv.ms/u/s!AkD78CVR1NBqkocwROvV_85ut3F_aQ?e=9rxSb9

As you can see, once we get below RGB = 18,18,18 there is not a whole heck of a 
lot of “details” between successive tones?

Obviously, the driver stretches the dark region significantly, allowing very fine control 
with 8-bit RGB quantization steps in this region. This implies, though, that some other 
region(s) of the color space must compensate the levels "wasted" for the dark 
region, by providing only a coarser control per RGB step.

8-bit quantization is not an issue, of course, if you have the opportunity to 
send 16-bit/channel DeviceRGB data directly to the driver (w/o truncation to 
8-bit first), can you?

Can a user expect output profiles to “preserve” details down to that level?

The function you plotted is monotonic, so it can be inverted (your plot does not say anything about 
other regions of the color space, though). The lowest slope is still about 0.1 dL/dRGB units, so 
I'm pretty confident that a well-constructed profile should be be able to model these 
"details". In order to assess whether a particular *profiler* is able to generate a 
"good" profile from the data, which preserves the slope in this region, you really need 
to create the profile and check the resulting gray axis mapping with xicclu.

Granted that the profile per se happens to preserve the slope, you still need to manage 
in the fist place to "feed the profile" with input colors whose quantization is 
fine-grained enough as well. That's not a matter of the profile per se then, but rather a 
matter of the whole transformation and printing chain involved.

Also keep noise in mind. Likely you don't win too much if you can control the 
nominal output in 0.1 L* unit steps, while the printing process still adds for 
example +/-0.5 L* units random noise on top of that. Noise may also hinder the 
profiler to generate a profile which characterizes the average device response 
well enough (as said, in order to assess, create the profile and check with 
xicclu).

Perceptual intent or applying the profile with BPC is a different story, as 
they are supposed to compress the gamut, *not* preserving all details.


Other related posts: