[argyllcms] Re: Profile input white not mapping to output white

From: Ben Goren <ben@xxxxxxxxxxxxxxxx>

To: argyllcms@xxxxxxxxxxxxx

Date: Tue, 27 Nov 2012 06:56:47 -0700

On 2012-11-27, at 12:14 AM, Graeme Gill wrote:
> I'm not sure I can do much more without a specific example in regard
> to the extrapolation code - ie. a .ti3 and some indication of what you
> think is wrong with it.
Use this .ti3 as a starting point:

and assign the resulting profiles to this image (currently tagged with the best
results I got):

(That's the image as it came straight out of Iliah's RPP and what I fed to
scanin, tagged with the best profile I got, using 1.4.0's colprof with no
options on the attached .ti3.)
If you run colprof on that .ti3 with no options with either current or test
code, you should get excellent results -- the same as the profile I've tagged
the above image with -- and the charts should visually be a very, very close
match to these synthetically-generated images of the charts:

If you delete the row at the bottom of the .ti3 with the ``WHT'' patch, your
results will be nowhere near as good, with either the current or test code. The
current code will still render R=G=B=255 reasonably close to what it should be
as L=100 a=-1 b=0, but the test code renders it as a decidedly dirty L=97 a=-1
b=-1. (With the WHT patch, both render as L=100 a=0 b=0.)
If you leave the ``WHT'' patch but delete the ``BLK'' patch, R=G=B=0 will map
to L=0 a=17 b=-13, but the visual change will be almost imperceptible (a slight
loss of detail). With the ``BLK'' patch, the result is L=a=b=0.
You may also wish to experiment with replacing the ``WHT'' row with this one,
which I got by measuring the scene with the i1 Pro with spotread in ambient
flash mode:
WHT 100.183453 104.100151 90.705105 100.0 100.0 100.0 0.0 0.0 0.0
The results will be better than without any additional patches, but not as good
as with the synthetic D50 patch.
I know you're opposed to adding D50 white as a patch value to the .ti3 before
processing...but, empirically, it works superlatively well. My best guess at an
explanation is that the raw processing code is already (correctly or not,
whether it should or not) forcing the data into D50 and that assuming it could
theoretically be doing something else is an incorrect assumption. Indeed,
that's the whole point of white balancing -- to equalize RGB values for samples
on the neutral axis, generally by applying a linear multiplier to each channel.
Let me know if there's anything else I can do to help...but also let me again
emphasize that, whether it *should* or not, adding D50 white to the .ti3 makes
colprof work *exactly* the way it should.
Cheers,
b&