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

Attachment: TrumpetChart!.ti3.D50white0black
Description: Binary data

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:

JPEG image

JPEG image

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.



Other related posts: