White balance depends on image source... non-standard code

[GrahamByrnes]

There isn't a "help, I don't understand" category. I'm trying to debug the preview_downsampling code (calling @bastibe) and there is something peculiar going on in white balance.

I have two images:

• one is a photo with the usual camera white balance options.
• the other is a scan of a colour chart (mostly a grid of coloured squares).

With preview_downsampling set to 1.0, both react as you expect to using "spot" in whitebalance. With preview_downsampling set to 0.25, the first one reacts as you'd expect. The second appears to do an initial default-area colour change. But if I make a little sampling area entirely inside a coloured square, ... nothing happens.

Random thoughts:

• scans are made up of specific RGB triplets that are not those of the eye, and something can go weird if you try to do usual colour balancing when reading in the tif. Maybe this screws up the black-body temp estimators... but why does it work when the downsampling=1.0?
• changing preview_downsampling screws everything up... but why does it work for a camera-derived image?
• maybe sampling a chromatically uniform square screws things up... but why does it work at 1.0, and why doesn't it work for even small deviations from grey?

Ping to @johnny-bit and @jenshannoschwalm since they've both worked recently on colour temps and WB sampling areas... even if you could just point me at the bit of code that takes the sample and constructs a global adjustment from it.

Thanks, Graham

[johnny-bit]

in temperature.c function _iop_color_picker_apply - it simply calculates coefficients trying to normalize average color to pure gray.

[jenshannoschwalm]

Could your observation just be related to scaling at other places because the image sizes are vastly different?

[GrahamByrnes]

So yes, eventually calls XYZ_to_temp(), which is just a bisection method inverter of temp_to_XYZ()... which calls spectrum_to_XYZ() which makes use of the colour matching functions in cieXYZ blah blah...

[GrahamByrnes]

@jenshannoschwalm Not sure... it would depend on how these colour functions assign a temp to a single colour. And maybe the real extent of the sampling box. I need to put in some debug fprintf's to see what is being passed around. Thanks folks :-)

[bastibe]

With large downsampling factors, picker areas can become zero-width, with various and entertaining consequences depending on application. Also, downsampling averages pixels, and can result in incorrect colors near strong transients.

[GrahamByrnes]

I've just loaded a computer-generated colour checker from Bruce Lindbloom's site (the standard McGretag card), so big uniform areas of colour. I think I see what is happening: if I select four squares in the upper left, it works. If prv_down = 0.5 I can also pick them nearer the centre, if Prev_down=1, anywhere. So it's scaling to the coordinate reference, which in this case seems to be the upper left, while picks from the lower-right are out of bounds. Still strange that it happens differently for the colour-picker itself.

[GrahamByrnes]

Ok, that works :-) I'm gradually returning @bastibe's code :-)

I think the disappearing width and so on was largely taken care of by @jenshannoschwalm's debugging of the colorpicker 12 days ago.

Remaining issue (that I'm aware of) is the inability to control keystoning in crop & rotate.