[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: