New automatic white balance - Itcwb

I have merge the branch “autowb”

This branch contains a new automatic white balance process.
I named it “Itcwb” - Iterative temperature correlation white balance"

It’s a totaly new process, not based on grey, but on color.
Sommary, this new process, compare 20 to 50 color in the image, with 20 to 50 colors predefined among 200 (spectral datas between 350nm and 830nm).

The comparison is made in xyY, on the one hand from the colors of the image to which I apply the principles which change the RGB values as a function of T, and on the other hand to the spectral values of the among (200) colors to which the mathematical principles are applied (for each pixel : matrix color, matrix illuminant, matrix standard observer)

This comparison is made first for green / magenta then for red blue, by optimizing a student corellation.

For this to work, the illuminant must be with a CRI (Color Rendering Index) close to 100 (Daylight, blackbody)

I maintained the old “WB auto” (grey) for compatibility reasons and for cases where “Itcwb” cannot work, for example underwater

jacques

9 Likes

This is great, I can’t wait to try it out!

1 Like

I haven’t used this for some time. Here is some feedback. I tested it on à contre-jour, late afternoon at the Waterfront, Cape Town.

1 I find that it isn’t a set it and forget it auto. When I adjust other modules, I have to set this again.

2 Sometimes, I get a student value of 1000. Workaround is to switch back to camera and then back to itcwb.

3 AWB bias is finicky. As I go up or down using -/+, the values from the colour dropper could go back and forth until a sufficiently high or low value.

PS I haven’t verified whether items 1 and 3 are specific to itcwb or other modes as well.

@afre
Thank you for this report :slight_smile:

But as I say in another thread, there is no “miracles”. In principle in a wb-auto, there are more unknowns than equations, so the result will always be uncertain.

What i can say is that of all the WBauto systems i have created or tested this is by far the best (or the least bad).

With Daylight, or Blackbody it works well in a majority of cases. I think that for correctly exposed photos, with a correct illuminant, it will improve the “camera” rendering.

You can use “bias”, but that’s what the algorithm does (better), moreover it also does for tint.
But of course, nothing prohibits to use it, if the user finds a gain.

When you adjust others modules, they can interact with Itcwb, and if color are changed, algorithm is restarted.

Sometimes, me also, I have a “student” out…I have tried to fixe, but it seems random. The algorithm is realy very complex.

But, what is missing - in some cases - is a chromatic adaptation after white balance. I am working on a new manner, different from branch cat02wb that I wanted simple, which does not always give the results I expect , with the same algorithm using Ciecam02. Probably I will post a Pull Request tomorrow, with a cat02, directly from ciecam with minimal user intervention

Jacques

2 Likes

@jdc which modules affect it?

@Morgan_Hardwood

all modules, before WB

Yes, this can be random; but I am reporting a different (potentially related) issue.

After adjusting another module, it either doesn’t re-initiate or doesn’t work as expected. What I have to do is switch to camera and itcwb again. Only then does itcwb work as expected. I would have to do this as the last step to make sure the WB adjustment is correct.

Looking forward to it. Appreciate your work as always. :slight_smile:

@afre
it’s the same problem, but seems to concern WB auto in general, and I don’t have the solution

I just created a pull request : cat02preset - use simplified ciecam02 preset to generate Chromatic adaptation cat02.

I changed, compared to the “cat02wb” branch, the way of realizing cat02 automatic. Indeed the version in the “cat02wb” branch was at another place in the process. The algorithm is the same, but the results seem better now. The only consequence is at the GUI level where you have to look for the check box at the start of Ciecam, instead of just after WB.

jacques

Please open an issue in GitHub and provide the steps to reproduce and the RT build version (commit hash) you reproduced it in.

Sorry, ATM, I don’t feel confident enough to open an issue yet. It may come later. The good thing is that @jdc seems to know what I am talking about. :roll_of_toilet_paper:

Although I am active here, my mind is elsewhere and life is too taxing for me to be coherent. Case in point: all of my PhotoFlow related feedback. :blush: @Carmelo_DrRaw seems to appreciate it, so I will continue. I have also been giving @XavAL feedback on RawPedia for a while in PMs. Vague again but he seems to appreciate it as well.

1 Like

OF COURSE!!! :slight_smile:

That’s the thing, I think there’s a misunderstanding, as J seems to be referring to the problem of unknowns while you’re referring to the WB calculation event failing to fire after manipulating a tool earlier in the pipeline (procevents), if I understood you correctly. No worries, I’ll try to reproduce later and open an issue if I succeed in the latest dev.

1 Like

The behaviour of “autowb Itcwb” is the same (I think…perhaps to verify) as “auto RGB grey” in “dev” and the same as in “Auto” before.

If you don’t change “temperature” or “tint”, WB stay in “auto”, the only change to “auto” who recalculate “auto” are “bias” and “blue/red equalizer”. And it seems (to verify) that it’s always been like this. I think to avoid recalculation an gain time (1)

Of course we can change this behavior, but if we mixed with (1), it will be necessary to determine when and why to recalculate, but is it necessary ?

jacques

The changes who interfere with “autowb” are all processing upstream of wb which can have an incidence, often very low, for example:

  • black and white point
  • green equilibration
  • demoisaicing
  • Retinex
  • rebuild highlight
    *…

Thanks for understanding my situation. It could be a number of things: failing to fire, algorithm failing or something in between or entirely different. Could be the preview. Maybe going insane. :stuck_out_tongue: It is hard to tell without debugging and making objective comparisons.

Yes, I was activating upstream modules. I rarely do anything more than the bare minimum, so I wasn’t aware of this until now.

I’ve tried the new itcwb algo a bit and it seems to do quite a nice job. I have noticed it suddenly flipping and having 1000’s of students all of a sudden. Not figured out what triggers it yet and not sure the white balance itself was changed.

Not very helpful but just pointing out that it does a good job but seems to for some reason get lost later on.

There is some random behaviour in Itcwb which I’m just trying to fix…

Some informations on the algorithm, and Student Itcwb display

  • when for various reason in general due to pipeline conception of White-balnace in RT - to minimize recalculation - recalculation of WB auto is not done Student display 1000
    Student = 1000 is not a dysfonction but means that recalculation is not done, previous result are used.
    For the other WBauto - AutoRGB grey, the behavior is the same, but of course no dispaly of Student

  • when you use “Bias” the behavior is different from “AutoRGB grey”, in fact the algorithm take another Temp to begin the algorithm, recalculate first green, then recalculate temperature, and calculate Student. For low values of Bias, the results are quite not changes,. For me “bias” should only be used with caution because in fact it will bypass the use of the algorithm

  • when you use “Blue red equalizer” same remark as “Bias”, but in this case we can think the user wants something…In this case, ItcwB is not changed, but we change, after, Temp and Tint. But as the use of this case is generally “underwater” (underwater does not work with Itcwb), I recommand to not used.

I have change 2 things in the last commit

  1. The tooltip for Itcwb - student - says for “Student = 1000” ==> not calculate, use previous results
  2. if you use “console” (with verbose), I have enable “BENCHMARK”, you can see when algorithm is used and time used

@heckflosse

Of course you can optimize, thank you

jacques

Other remark

If the result after Itcwb, you are not completely satisfied, rather than changing “bias”, ask yourself the question: “what do my eyes see and what interpretation does my brain make of it”

In fact in most cases, when calculate Temp is different from 5000K, for example 4300 will give a “cool” appearance, and other example 7000K will give a “warm” appearance. In this case you can use Ciecam02 - preset to “warm” or “cool” the result.

if there are no objections, I will merge the pull request "Cat02preset - use simplify Ciecam preset to generate chromatic adaptation cat02 " tomorrow

This allow you (with the simplify settings)

  1. realize whithout change a chromatic adaptation which should be relevant in a majority of cases
  2. change if need percentage of chromatic adaptation
  3. change if need , Temperature and Tint

And by entering in Ciecam02 take into account others parameters as “scene conditions” or “viewing conditions”

jacques

1 Like

I have update Rawpedia in french for
https://rawpedia.rawtherapee.com/White_Balance/fr

and for cat02 adaptation
https://rawpedia.rawtherapee.com/CIECAM02/fr#Mode_normal_ou_sym.C3.A9trique_et_CAT02_adaptation_White_Balance

In addition, Ingo @heckflosse is in the process of completing various optimizations (thanks to him) which should be merged soon

jacques