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

  • From: Ben Goren <ben@xxxxxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Wed, 28 Nov 2012 08:34:41 -0700

On 2012-11-27, at 5:21 PM, Graeme Gill wrote:

> I think there is a conflict in intent here.

I don't think the conflict is in intent so much as that Argyll is doing 
something (determining the white and black points and acting accordingly) that 
other software earlier in the pipeline has already done. Specifically:

> In general I would have thought that each photo needs to be assessed
> and it's white point chosen to suite that photo, and the software
> used to do this is then able to treat (ie. clip) values beyond the
> white point in an appropriate manner.

That's what the RAW software already does, but Argyll is unaware that it's 
happened and basically attempts to re-apply that same process. Furthermore, RAW 
software is designed to align the channels such that everything that's 
spectrally flat should when it's done already have equal RGB values, at least 
for whatever's lit by the (impossible-to-guess-after-RAW-development) 
illuminant the RAW software used for the scene.

(At least, that's how I understand what's going on...I could certainly be 
worng.)

I'll be the first to admit that my understanding of the theory behind all this 
is quite lacking.

However, I can state with great confidence from empirical testing that adding 
the synthetic black and white points to the .ti3 and handing it off to the 
latest official release of colprof with no processing options results in a 
profile that's both as close to colorimetrically correct as I think it's 
possible to get and visually most pleasing as well. For the proof, see my 
previous post with the four images, and do a blink comparison. The appearances 
of the synthetic charts and the photographed version with the D50 white and 
black patches are almost indistinguishable. Remove the D50 lines from the .ti3 
and the charts are instantly discernible even in side-by-side comparisons.

So...on the one hand, the ``right'' answer would be for Argyll to do its magic 
on the RAW camera data, but that would mean you'd have to get into the business 
of Bayer demosaicing and all the rest -- not something I think you're 
interested in. (But if you are, I'll *really* get excited!)

On the other hand, however it works, whatever it short-circuits or whatever, 
just adding those lines to the .ti3 causes colprof to do exactly what one 
expects / hopes it would do, and it does that spectacularly in superb fashion.

That's why I still think the least-worst answer would to be to add a switch to 
colprof that says, ``the input is from a typical modern DSLR that's been 
through RAW processing and thus is already white balanced and clipped, so 
assume that the endpoints of the gray axis are already where they should be.''

If you're still opposed to adding such a switch, I think it would be only fair 
to add something to the documentation letting users know that .ti3s generated 
from DSLR captures may benefit greatly from this type of modification. I know 
that it's going to be part of my workflow with the current version of colprof 
and any future ones that behave the same way as today.

Cheers,

b&

Other related posts: