I'd like to preface this post by saying that I don't want to reimplement the old, destructive high_precision_wb(), but that we should probably change the algorithm we use to calculate the user_wb on the second RawPy image open to make lighting results more consistent.
This is a pretty crippling white balancing error for images with large light spore packets or bright notecards, that causes minor to very large brightness fluctuations between images. This may have something to do with the camera settings, but we've checked the settings and they are seem all the same with what was found in the digitization protocol.
My theory for the cause is that the RAW image sensor values are actually very dim - mainly because of the fact that the orange notecard is so bright & large. And the "compensation algorithm" we're using to fix them is probably not correct because we assume a linear relationship to brightness, but it's actually not linear from my testing.
Below images are a comparison of all of the white balancing techniques, including my very old high_precision_wb() function that "destructively" changes the derivative RGB array values.
Unfortunately, high_precision_wb() has very inconsistent results in its old implementation against images that do not have this radiant notecard, or a large light brown spore packet. In my pursuit of trying to fix this, which would be to make high_precision_wb() more consistent against all images with or without a large, bright object, it seems that we need to properly create an algorithm based on how dark the actual CRC white point values are to a base reference luminance point. What I think we're doing currently is assuming that the brightness/luminance relationship is more "linear," but I have found this to be somewhat false when trying to fix high_precision_wb(). Here is the algorithm I created:
...where the reference luminance point (how bright I want the white part of the CRC image to be) is RGB(200, 200, 200) represented by the 200 above. This algorithm isn't meant to be used as a replacement to user_wb but is specific to high_precision_wb(). What I wanted to highlight in the above algorithm is the non-linear curve this algorithm would create.
The most true to life colors is found in the high_precision_wb() image below, mainly because the underlying sheet is bond paper (and as such shouldn't have a warm tone to it). The orange notecard is also the proper hue and saturation, and the images were assessed on a DCI-P3 calibrated display with true-tone enabled (iPad Pro 11 2018).
If you would like to inspect the images, I urge you to look at them in a new tab/by themselves. It looks a little unnatural in the post preview themselves, and the too-cool looking hue and unnaturalness found in the post-processed image with high_precision_wb() isn't something I encountered on my DCI-P3 calibrated iPad.
Original CR2 Camera Whitebalance
Current HerbASAP Master
HerbASAP with high_precision_wb() and luminance_factor
@CapPow Proof-of-concept work now in dax-dev-hpwb branch. Some tuning still needed for shadow crushing but for the most part output is much, much better on the fungi collection here at UTC.
I'd like to preface this post by saying that I don't want to reimplement the old, destructive
high_precision_wb()
, but that we should probably change the algorithm we use to calculate theuser_wb
on the second RawPy image open to make lighting results more consistent.This is a pretty crippling white balancing error for images with large light spore packets or bright notecards, that causes minor to very large brightness fluctuations between images. This may have something to do with the camera settings, but we've checked the settings and they are seem all the same with what was found in the digitization protocol.
My theory for the cause is that the RAW image sensor values are actually very dim - mainly because of the fact that the orange notecard is so bright & large. And the "compensation algorithm" we're using to fix them is probably not correct because we assume a linear relationship to brightness, but it's actually not linear from my testing.
Below images are a comparison of all of the white balancing techniques, including my very old
high_precision_wb()
function that "destructively" changes the derivative RGB array values.Unfortunately,
high_precision_wb()
has very inconsistent results in its old implementation against images that do not have this radiant notecard, or a large light brown spore packet. In my pursuit of trying to fix this, which would be to makehigh_precision_wb()
more consistent against all images with or without a large, bright object, it seems that we need to properly create an algorithm based on how dark the actual CRC white point values are to a base reference luminance point. What I think we're doing currently is assuming that the brightness/luminance relationship is more "linear," but I have found this to be somewhat false when trying to fixhigh_precision_wb()
. Here is the algorithm I created:...where the reference luminance point (how bright I want the white part of the CRC image to be) is RGB(200, 200, 200) represented by the 200 above. This algorithm isn't meant to be used as a replacement to
user_wb
but is specific tohigh_precision_wb()
. What I wanted to highlight in the above algorithm is the non-linear curve this algorithm would create.The most true to life colors is found in the
high_precision_wb()
image below, mainly because the underlying sheet is bond paper (and as such shouldn't have a warm tone to it). The orange notecard is also the proper hue and saturation, and the images were assessed on a DCI-P3 calibrated display with true-tone enabled (iPad Pro 11 2018).If you would like to inspect the images, I urge you to look at them in a new tab/by themselves. It looks a little unnatural in the post preview themselves, and the too-cool looking hue and unnaturalness found in the post-processed image with
high_precision_wb()
isn't something I encountered on my DCI-P3 calibrated iPad.high_precision_wb()
andluminance_factor