Branch White balance : auto - local - Cat02 adaptation

[Desmis]

I push a change in branch autowblocal. For me now it's work well. I don't say there is no bug or dysfunctionement. To test :)

3 main features : a) 7 methods for "auto WB" ; b) one RT-spot for local WB; C) Chromatic adaptation Cat02 - derived from Ciecam02.

I have enabled by default "White Balance", because when disabled, bad functionnement especially CIECAM02

You have 7 methods "Auto White balance" (from University research on WB) - the first "Auto grey old", is the actual "auto WB" All others methods are after demoisicing, you can or not apply a gamma sRGB (not for auto grey old). I have not managed to make the "correlation color" method work correctly, the code is present, not activated ...

It is not more abnormal to have 7 methods, than 13 for demosaicing, or multiple micro-contrast versions...its depend of image, and recall WB is a mathematically indeterminate problem.

Depending on the user's choice, we can select if necessary a smaller number, to simplify

Cat02 adaptation is avaiable for "White balance " and "white balance local" and from my point of view should always be used.

Cat02, performs a chromatic adaptation, between the chosen temperature and 5000K. Settings 90% should satisfy the majority of cases. If the absolute luminance conditions (scene or viewing) are very low, you can lower the value, if conversely they are very high you can increase the value up to 100.

For local WB, I think it is not necessary to have more than one control. This local WB allow to correct shadow, in a sunshine scene, or mixed illuminant (Sun and Tungstene) You can choose, either an elipse or rectangle selection. You have a slider transition...

jacques

[gaaned92]

RawTherapee_autowblocal_5.3-471-g6e0263c2_WinVista_64.zip

uploaded at https://keybase.pub/gaaned92/RTW64NightlyBuilds/

@Desmis I did not yet tested the new autowblocal.

While building it, I noticed some warnings

In file included from Y:/RTSOURCE/rawtherapee/rtengine/improccoordinator.cc:19: :
Y:/RTSOURCE/rawtherapee/rtengine/improccoordinator.h: In constructor 'rtengine::ImProcCoordinator::ImProcCoordinator()':
Y:/RTSOURCE/rawtherapee/rtengine/improccoordinator.h:221:11: warning: 'rtengine::ImProcCoordinator::colourToningSatLimitOpacity' will be initialized after [-Wreorder]
     float colourToningSatLimitOpacity;
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~
Y:/RTSOURCE/rawtherapee/rtengine/improccoordinator.h:144:12: warning:   'double rtengine::ImProcCoordinator::ptemp' [-Wreorder]
     double ptemp, pgreen;
            ^~~~~
Y:/RTSOURCE/rawtherapee/rtengine/improccoordinator.cc:40:1: warning:   when initialized here [-Wreorder]
 ImProcCoordinator::ImProcCoordinator()
 ^~~~~~~~~~~~~~~~~
[ 23%] Building CXX object rtengine/CMakeFiles/rtengine.dir/ipretinex.cc.obj
Y:/RTSOURCE/rawtherapee/rtengine/improccoordinator.cc: At global scope:
Y:/RTSOURCE/rawtherapee/rtengine/improccoordinator.cc:171:13: warning: 'void rtengine::calcLocalrgbParams(int, int, const rtengine::procparams::LocrgbParams&, rtengine::local_params&)' defined but not used [-Wunused-function]
 static void calcLocalrgbParams(int oW, int oH, const LocrgbParams& localwb, struct local_params& lp)
             ^~~~~~~~~~~~~~~~~~
In file included from Y:/RTSOURCE/rawtherapee/rtengine/improccoordinator.cc:29: :
Y:/RTSOURCE/rawtherapee/rtgui/md5helper.h:31:13: warning: 'std::__cxx11::string {anonymous}::getMD5(const Glib::ustring&)' defined but not used [-Wunused-function]
 std::string getMD5 (const Glib::ustring& fname)
             ^~~~~~

Y:/RTSOURCE/rawtherapee/rtengine/iplowb.cc: In member function 'void rtengine::ImProcFunctions::WB_Local(rtengine::ImageSource*, int, int, int, int, int, int, int, int, int, int, rtengine::Imagefloat*, rtengine::Imagefloat*, const rtengine::ColorTemp&, int, rtengine::Imagefloat*, const PreviewProps&, const rtengine::procparams::ToneCurveParams&, const rtengine::procparams::ColorManagementParams&, const rtengine::procparams::RAWParams&, const rtengine::procparams::LocrgbParams&, double&, double&)':
Y:/RTSOURCE/rawtherapee/rtengine/iplowb.cc:371:27: warning: unused variable 'MunsDebugInfo' [-Wunused-variable]
         MunsellDebugInfo* MunsDebugInfo = new MunsellDebugInfo();
                           ^~~~~~~~~~~~~
Y:/RTSOURCE/rawtherapee/rtengine/iplowb.cc:379:16: warning: unused variable 'av ' [-Wunused-variable]
         double ave = 0.;
                ^~~
Y:/RTSOURCE/rawtherapee/rtengine/iplowb.cc:380:13: warning: unused variable 'n' [-Wunused-variable]
         int n = 0;
             ^
Y:/RTSOURCE/rawtherapee/rtengine/iplowb.cc:381:15: warning: unused variable 'av' [-Wunused-variable]
         float av = 0;
               ^~
Y:/RTSOURCE/rawtherapee/rtengine/iplowb.cc:386:15: warning: unused variable 'dhue' [-Wunused-variable]
         float dhue = ared * lp.sens + bred; //delta hue lght chroma
               ^~~~
Y:/RTSOURCE/rawtherapee/rtengine/iplowb.cc: In member function 'void rtengine::ImProcFunctions::Whitebalance_Local(int, int, rtengine::Imagefloat*, const rtengine::local_params&, rtengine::Imagefloat*, rtengine::Imagefloat*, int, int)':
Y:/RTSOURCE/rawtherapee/rtengine/iplowb.cc:562:23: warning: unused variable 'kc ' [-Wunused-variable]
                 float kch = 1.f;
                       ^~~
Y:/RTSOURCE/rawtherapee/rtengine/iplowb.cc:563:23: warning: unused variable 'fach' [-Wunused-variable]
                 float fach = 1.f;
                       ^~~~

Y:/RTSOURCE/rawtherapee/rtengine/improcfun.cc: In member function 'void rtengine::ImProcFunctions::ciecam_02(rtengine::CieImage*, double, int, int, rtengine::LabImage*, const rtengine::procparams::ProcParams*, const rtengine::ColorAppearance&, const rtengine::ColorAppearance&, const rtengine::ColorAppearance&, LUTu&, LUTu&, LUTf&, LUTf&, float&, int, int, bool, double&, double&, int)':
Y:/RTSOURCE/rawtherapee/rtengine/improcfun.cc:1540:32: warning: 'c_' may be used uninitialized in this function [-Wmaybe-uninitialized]
             float Qredi = (4.0 / c_)  * (a_w + 4.0);
                           ~~~~~^~~~~
Y:/RTSOURCE/rawtherapee/rtengine/improcfun.cc:1540:46: warning: 'a_w' may be used uninitialized in this function [-Wmaybe-uninitialized]
             float Qredi = (4.0 / c_)  * (a_w + 4.0);
                                         ~~~~~^~~~~~

[Beep6581]

A. Same warnings here using GCC-5.4.0.

B. The new automatic white balance method "Auto edge" seems to do a really good job, better than the current auto white balance!

C. I don't understand how CAT02 adaptation is supposed to work in the WB tool. When using the CIECAM02 tool, CAT02 Adaptation is auto-detected to 83, and the image looks fine. When I set it to 83 in the white balance tool, the tones can go extreme:

1. dev, CIECAM02 enabled with CAT02=83:
2. autowblocal, CIECAM02 enabled with CAT02=83, same WB temp and tint, WB CAT02Adapt=0:
3. Same as 2 but CAT02Adapt=83:

D. Changing the "CAT02 Adaptation" slider probably shouldn't change the method combo to "Custom".

[agriggio]

Hi @Desmis, here are a few comments after having tried this (very quickly though):

• I think we should discuss the three new features as separate issues; we might decide to integrate only some of them, or to integrate some earlier than others, and so on...

• In particular, I think we should postpone the "local wb" issue until the pipeline has been refactored and we have a clearer plan for integrating locallab into dev

• Regarding the fact that having many auto wb methods is not a problem, well I disagree :-) It is true that we have a lot of demosaic options, and I personally think that we should get rid of some of them that nobody uses anymore, but the situation is very different to auto wb, for the following reasons:

  1. with demosaicing, you are limited to the options that are provided by RT, you can't have your "custom" demosaicing. With WB, the user is always free to move the sliders in whatever way she prefers.

  2. with demosaicing, there are reasonably clear guidelines as to what methods to use in which conditions, and there are trade-off in performance/quality that are also well documented. With Auto wb, it's a totally "trial and error" thing for each individual image... or maybe you have some guidelines?

• but, this is not to say that what you did is useless! On the contrary, I think it's very cool that you have been experimenting with this. I am simply suggesting that we do proper testing and then we stick with one method for Auto WB that gives the best results overall (or the more robust ones -- see below).

B. The new automatic white balance method "Auto edge" seems to do a really good job, better than the current auto white balance!

• This is not my experience, unfortunately. I just tested a couple of pictures, here's what I get with "auto edge":

For reference, here's a reasonable wb (set manually):

I don't understand how CAT02 adaptation is supposed to work in the WB tool.

• I also don't understand it, or at least I think there's some issue with "extreme" temperatures (well, not that extreme, but you get what I mean I hope). Here's the same as above, with CAT02 adaptation turned on (set to 90 as suggested):

[Desmis]

I just pushed a change that

• suppress warnings
• disables Cat02 when Ciecam02 is enabled

For the rest: I do not think we should wait for the work on "locallab". Indeed, a module "WB local + Cat02" seems to me sufficient in 99% of cases. It is as "Graduated filter" (even we can enhance this feature) You have in "locallab" a "warm-cool" module, that you can duplicated, perhaps it is not so good, but suffisant in most cases (as in Photoshop)

For memory "WB auto" and "WB local" are in a branch, even if it has been renamed (it was called "localrgb") for about 1 year. And with Hombre we have work together with "Robust WB" in 2013, but we gave up for various reasons (GUI, etc.). Few tests have been done, which leads me to (re) open an issue, to have a debate. The few comments have often been critical: why so many methods ?, what to test ? hence my remarks

Now some technical comments:

• for all the methods "WB auto", no code (or very little) is available, one finds on the University sites only the principle of the algorithms
• for each method, each site says its method (by comparison) is the best - with reference images
• the white balance is something of empirical, the one relating to the illuminant D (the best known) is really reliable between 4000K and 8000K (above ??)
• below these values we are in uncertainty, I used Planck's formula of black body radiation, which works well in photography beyond 2700K, up to 4000K
• below 2700K, it is ???: users want something, but science does not know (or bad) to answer.
• RT is one of the rare software to have Ciecam02, recently with the help of Elle Stone, we brought to Ciecam02, the notion of "symmetry". That's what I used for Cat02 "new"
• In symetric mode, I used the same values, for La (scene), La (Viewing), and for Yb (scene), Yb viewing, which explains the differences between slider cat02 and Ciecam if for example "La scene" is low.
• Indeed Cat02 is installed in RT since 2013, but reserved for unpublished uses
• Ciecam02, is always "experimental", and filled with malfunctions as soon as we are at the limits (gamut, temperature ...). I recently changed the limits to avoid crashes, but that does not hinder to have bad results.

Of course, you have to test, but be careful (see remarks above), there will be no miracles. We can found bugs (probably), GUI problems, etc.

Jacques

[Desmis]

@agriggio

Alberto could you give me a link, with images "extreme temperature", as the one you used here :) Thank you

[agriggio]

@Desmis Hi Jacques,

first, sorry if I sounded too negative -- that was not my intention! I was just expressing my opinion, probably without paying enough attention to the tone...

*I do not think we should wait for the work on "locallab". Indeed, a module "WB local + Cat02" seems to me sufficient in 99% of cases. It is as "Graduated filter" (even we can enhance this feature)

I think we should aim for a proper, generic solution that will allow to integrate local editing in a clean, efficient and maintainable manner. (Ideally, once we have that, also the graduated filter should become part of the general local adjustments, but this is getting OT here.) But that's just my opinion, of course. Again, this is not to dismiss what you have done, at all! I'm interested in hearing the rest of the crew anyway.

for all the methods "WB auto", no code (or very little) is available, one finds on the University sites only the principle of the algorithms

And this is (one of the reasons) why I think what you did was very nice. This work will be very useful for us to evaluate what is the method that works best for RT in the majority of cases, and then we can expose that to users.

That is, if the goal of RT is to produce a flexible, powerful and useable tool for RAW development. This is my personal goal at least, but I do understand that other people might have different views. If you see RT more as a tool for experimenting with various algorithms in a controlled environment, that's perfectly ok too! It's just not a direction I'm very interested in following (I do this as my daytime job, I don't want to do this also as my hobby :-), but that doesn't mean much...

below 2700K, it is ???: users want something, but science does not know (or bad) to answer.

Well, but that is a very important range for users -- or at least for me. I find that the WB computed by the camera is usually adequate unless we are in extreme conditions. Therefore, having an AutoWB tool that works well at the extreme ranges and only "ok" at more "normal" temperatures seems more useful to me than an algorithm that works excellently at normal temperatures but very poorly at the extremes.

In particular, if CAT02 adaptation doesn't work well at extreme ranges, perhaps it should be off by default. With the current value of 90, even if you set the WB to "Camera", you can see very different results from what the in-camera jpeg would produce (see the example above...).

[agriggio]

@Desmis Jacques I will search for something that I can share later tonight. If I don't find anything, I will send you the above picture privately (but in that case please keep it for yourself :-)

[agriggio]

@Desmis Jacques, you can try with these colour targets: https://filebin.net/5lbtz6cqnayo0e6w Here, CAT02 adaptation gives a yellow cast similar to what is shown above (although less extreme)

[Desmis]

@agriggio

Alberto, don't worry :) I'll test Cat02 with your images and try to find "limits"

Thank you

Jacques

[Desmis]

@agriggio

All these images are with a very low values of "La" about 3.... Normal values are about 400, 2000 or more ! If you try "Ciecam", you have the same problem, I will look how to do, to "bypass" this problematic , which can be very usefull in some cases (see the work of Elle Stone)

[Desmis]

I push a change. I think it solves the problem, for very very low values 'La' and temperature very low. For intermediates values, I put empiricals values...to verify, but it is easy to chnage values.

I add an "autochecbutton", and I calculate "La", then with an algo different from the one used in CIecam, I adjusted Cat02.

Jacques

[Desmis]

Is someone have a "submarine" photo (underwater). I have lost the one I had on my computer. For testing, at the other extermity of temperature >> 20000K

Thank you

[agriggio]

Hi Jacques (@Desmis)

I push a change. I think it solves the problem, for very very low values 'La' and temperature very low.

Thanks for the change, but it still gives me weird results:

I will take another picture in the same room later tonight (without the problematic subject :-) and send it to you.

[Desmis]

have you enabled / disabled "White balance", because at 1, CAT02 is desabled :)

[agriggio]

if I set it to 0, I get reasonable results. but at 1 it is still weird...

[Desmis]

At 1, Cat02 is desabled, I am sure :) Do you have CIecam enabled ?

But there is a bad functionnement of WB, not due to my changes In refreshmap.cc events for WBenabled" is ALLNORAW, all events WB are with DEMOSAIC

[Desmis]

I will make some changes, WBenable events, another in Whitebalnce (WBchanged()) And I also chnage cat02 1 to 0, but this has no effect...

But a question (if you know the response) , Why there is now a "button" to enabled / disabled WB, for what usage ?

[heckflosse]

@Desmis

Is someone have a "submarine" photo (underwater)?

I think I have one. Looking...

[heckflosse]

@Desmis https://filebin.net/0obifcclj4vszoaf

[Desmis]

@heckflosse

Thank you :)

I made a change to have good temp for cat02. I will look tomorrow

I think, there is a problem with management of events but where ?

[agriggio]

@Desmis here's another image that you can use for your tests: https://filebin.net/fzd9wdh5o7nn895h/DSC09464.ARW

[Desmis]

@agriggio

Thank you :)

I look at the code, and now I am sure, the problem is not due to Cat02 (except the problem of very low values, which are now solved), but to the pipeline and / or whitebablance.cc and/ or events with WB.

I had incorporated cat02 in WB for the sake of ease and ergonomics. Even if he has nothing to do with the WB settings, he's just using it (getimage)

I will create a separate "menu" (with to day only One slider), and I think all these problematic will be solved. but it will not be done in 5 minutes

:)

[Beep6581]

But a question (if you know the response) , Why there is now a "button" to enabled / disabled WB, for what usage ?

That was issue #3542 You can use this to set the white balance multipliers to 1 1 1 for raw image analysis. It could be of use to users of UniWB and cameras modified to capture IR/UV light.

[Desmis]

I push a change 46ad618 Now I think (to verify) that all runs normaly. I don't change algo Cat02, only GUI... Perhaps, it needs to refine some values for limits...

Jacques

[Desmis]

I commit a small change to take into account "enabled" for "Cat02" :)

[Desmis]

The last change, with the last merge(s)

I add a slider with an "auto button" in "Cat02 adaptation", for adjust "green". It has the same functionnality than the one in "Ciecam viewing conditions". I name it "Y tint (vewing conditions)"

This functionnality does not exist in Ciecam, but with "symetric" mode, proposed by Ele Stone, it is quasi indispensable in some cases, where "rgb green chanel White balance" is very different from 1 (one).

But for this mode, 2 particularities: 1) we are in Rawprocess - before color management, no gamma,.. no profile... 2) the conversion needs Lab, and Green channel (tint), is not usable. Instead I used Y (from XYZ).

I made an empirical calaculation of the correction based on "delta temperature", "delta green RGB", Cat02. I think it's works well in a majority of cases, principaly with "D illuminant" (in range 4000K - 8000K)

Jacques

[Desmis]

I push a change. Now default values for "local WB" are those of General WB : temperature, tint (green) and equalizer The values for "Cat02 adaptation level and Ytint" for "local WB", which are calculated with "local" value, are obviously the same (by default) are "Cat02 adaptation level and Ytint" for "general WB"

If you want to change an local area, you can unchecked, in fisrt; a) temperature b) and or "Cat02 adaptation level"

For more complex changes you can also, change "Tint (local)" and "Equalizer (local)" In all cases if you change in local, "Temperature" and keep checked "Cat02 adaptation level local", this one and Ytint wil be adapted to new values. of course you can adjusted them.

There is no shape detection for "local wb" - too complex but I think possible, to do, with Raw datas. Shape detection works fine only with Lab* values. Pending an edge-based form detection algorithm that I have temporarily abandoned, because of "uncertainties" about "Locallab"

I think as I already said that a single control "local WB raw" is really useful. It must be reserved for complex cases, for example mixtures of illuminants - although of course we can use with "warm shadows".

For the vast majority of cases, the "warm cool" slider present in "Locallab" should be satisfactory. It gives substantially the same results as similar tools in other software (Photoshop, etc.) It uses the shape detection and can be duplicated.

For "Cat02 adaptation levels" (general), I think the systeme works normally now. It works fine when "normal" conditions are used (as Ciecam02), ie a current illuminant and values of "La" and "Yb" not too extreme. Of course I take into account this cases, by reducing "cat02 levels". But I think that we must not transform special cases in general cases.

Try on images as "london_bridge_moving_1.pef" (T=7922K) or "amsterdam_moving_boat_1.pef" (T=6112K), with default "WB Camera". You will see how CAT02 works.

[agriggio]

Hi @Desmis, I tried CAT02 adaptation a couple of days ago (before your latest changes) and it worked well. It gives a subtle but visible effect. Just to clarify though:

• this is supposed to produce more "accurate" colors, right?
• how does it relate to the CAT02 adaptation slider in CIECAM02? Is this supposed to replace the other one? Or are they working together? If so, how?

Thanks!

[Desmis]

@agriggio

Thank you for testing :)

To your questions: 1)this is supposed to produce more "accurate" colors, right? Yes of course, but not only. I think RT (and perhaps others software which I don't know the code), forgot after the WB to do this quasi indispensable "adaptation" (as are done naturely by ours eyes and brain).

2) Yes and no: See the works and modifications to Ciecam02 some mounths ago with work of Elle Stone (thanks to him) In fact, there is 2 mode for Ciecam02. Normal mode, as before where you principaly uses the sliders (J, C, Q, etc.) and the curves and when you want to adjust CAM to real conditions , for example if you project images on a big screen with a projector, in a dark room... Symetric mode, whose main purpose is chromatic adaptation, without touching the sliders / curves

To actived "symetric mode" a) of course enabled CIECAM b) select in WP model : Free temp + green + CAT02 + [output] c) do not touched to Temperature and Tint, they ust be at 5000K and 1.0 (settings D50) d) let Surround on : "Average" e) put Scene absolute luminance to 400: to avoid calculation due to exposure, etc. f) put Yb (mean luminance) to 18

e) do not touched to sliders or curves

f) put Viewing absolute luminance to 400 g) let Surround to "average" h) put Yb to 18 i) set Temperature, to White Balance temperature j) adjust Tint (in reality Y tint because we are in XYZ values), it must be empirical

Of course there will be differences between what I have just implemented with "CAT02 WB" 1) due to internal calculations of "La" and "Yb": original algo of Ciecam do not reach good values (your images) with T < 2700K and La very low). I have change these calculations for "CAT02 WB"

2) due to the position in the process:

• Ciecam02 is at the end of processs
• CAT02 WB, is in RAW mode just after WB.

Jacques

[Desmis]

3 complements 1) in symetric mode, with settings above, "CAT02 adaptation scene" and "Cat02 adaptation viewing" are at 100. If you change one , you must change the 2 with same values

2) the algo used in "CAT 02 WB" is quasi the same as in Locallab "Warm cool", with a difference, It is the user in locallab which choice (whithout knowing he is doing that) the temperature "viewing conditions"

3) there will be some differences, between "Ciecam Symetric mode" and "CAT 02 WB" due to the place in process and more, no gamma, no profile, etc.

[Desmis]

An other complement 1) if you enabled "Ciecam02", "Cat02 WB" and "Cat02 Local WB" are disabled. It supposed that user know what it does :)

[Beep6581]

Just a thought in light of recent changes, maybe these CAT02 sliders would better belong in the CIECAM02 tool in the Expert tab, in a new "White balance" sub-frame at the top of the CIECAM02 tool?

[Desmis]

@agriggio

I don't think so :)

For me, CAT02 WB must be always enabled...at least in 95% cases. It is not an expert mode... Perhaps I must refine some algo in RW mode, but it is not crucial!

However, working with Ciecam in "normal" or "symetric" mode is expert mode. Perhaps is it necessary to modify "Ciecam expert module" to include a choice "normal" or "symetric"

Jacques

[agriggio]

@Desmis Jacques, fair enough, but this was DrSlony's (AKA @Beep6581) proposal, not mine :-)

[Desmis]

@Beep6581 @agriggio Oh sorry :)

[agriggio]

No problem. Anyway, I'm :+1: for the CAT02 integration (I didn't read the code though), but I would prefer to wait for the pipeline refactoring for integrating the other changes (for the reasons I exlpained in my first comment). What do the others think? Ping @heckflosse @Hombre57 @Floessie

[Beep6581]

I have two arguments for suggesting the above:

1. if you enabled "Ciecam02", "Cat02 WB" and "Cat02 Local WB" are disabled. It supposed that user know what it does :)

   This is one of those funny tool conflicts RT has. Another example is how parts of the EPD Tone Mapping tool become disabled when using a completely different tool (this might be in the newwavelet branch). Such interaction is not user-friendly and should be avoided.

   Having CAT02 in the CIECAM02 tool would avoid this funny interaction - the mutual exclusion would be clearly confined within the same tool.

2. CIECAT02 is part of the CIECAM02 model.

[Desmis]

@Beep6581

All is in all :) eg Lab is in Lab, but also Lab is in Raw, in Retinex, Denoise...

If you put "Cat02 wb" in Ciecam, by default Cat02 will be desabled....for me this means that almost no one will use this feature

And if you enabled "Cat02 Wb", it will be necessary to disable all others Ciecam fonctionnality

Sure we can, by defaut have Ciecam enabled with "Cat02 WB enabled", and disabled all others functions. But is it more intuitive ? Other advices ?

Jacques

[Beep6581]

All is in all :) eg Lab is in Lab, but also Lab is in Raw, in Retinex, Denoise...

Yes, but that is not what I meant. Enabling Noise Reduction does not disable L*a*b* Adjustments, but enabling White Balance CAT02 will disable CIECAM02... if I understood the explanation correctly. And CIECAM02 includes CAT02, which is 'same same but different'... confusing?

And if you enabled "Cat02 Wb", it will be necessary to disable all others Ciecam fonctionnality

Please correct me if I'm wrong, but this is already the situation in the autowblocal branch, is it not? So if that is the case, then the user needs to see this in a clear way - a flip-flop switch - and what better way than to have this happen within the same tool?

[Desmis]

For me, I think realy it s not a good solution to put "Cat02 Wb" in Ciecam...

More, when you want to adjust, after changing WB, you must go to Ciecam

More, in RT "conflicts", when you enable Ciecam, you change EPD and some others tools. Are users knowing that ? Sure they will see the result...

[agriggio]

Hi,

my two cents. First, I find these two statements a bit contradictory:

It supposed that user know what it does :)

More, in RT "conflicts", when you enable Ciecam, you change EPD and some others tools. Are users knowing that ? Sure they will see the result...

If we assume that users should know what they are using -- and I agree that this is ok -- then why do we need to disable the tools explicitly? The users will see that having both "CAT02 in WB" and "CAT02 in CIECAM02" leads to weird results, and since they know what they are doing, they will react accordingly (that is, turn off what they don't want). I find this much better (from the point of view of UI) than having some tools alter the state of some other tools, especially if they are not located next to each other.

Then, partially unrelated:

For me, CAT02 WB must be always enabled...at least in 95% cases. It is not an expert mode... Perhaps I must refine some algo in RW mode, but it is not crucial!

If the recommendation is to have it always on, and the "automatic" mode works reasonably well, perhaps we can simplify this even further and only have a checkbox in the WB tool "enable automatic CAT02 adaptation"? Either you accept the auto computation, or you turn it off (and use the more advanced CIECAM02 controls for achieving similar things). How does this sound?

[heckflosse]

I tested the new wb methods a bit.

1) in my tests the auto edge method gives better results than the old auto method 👍

2) even auto edge can still go crazy, for example on http://www.rawtherapee.com/shared/test_images/tracteur.dng

[agriggio]

even auto edge can still go crazy

Unfortunately, in the majority of my tests auto edge produces a very visible green cast, like in the example you linked :-(

[Desmis]

@agriggio All is possible, for "automatic Cat", "yes", but also "no"... In actual White Balance you have "auto-wb" and after multi correction possible :)

I can also, I think easy to do, when Ciecam is enabled, the 2 sliders "Cat02 adaptation level = 0" and Ytint =1.

@heckflosse Thanks for testing :) Actually the result with "tracteur.dng" is curious. I recall that an automatic WB is an indeterminate mathematical problem. All methods work pretty well when there is a good distribution of the 3 channels R, G, B

[Desmis]

@agriggio See also, the first reaction of DrSlony 9 days ago

[agriggio]

@agriggio See also, the first reaction of DrSlony 9 days ago

Ah, ok. "Ubi maior, minor cessat". Understood...

[Desmis]

All this to say that "Cat02 WB" is only one of all possible combinations in RT: emplacement, auto / manual

It is the same discussion than the other issue #4298 , and it is not easy to found the "good" compromize :)

[Desmis]

it would be nice if we spoke in an old language (Latin), instead of English (I don't speak Latin) :)

[Desmis]

I push a little change When Ciecam is enabled : a) cat02 = 0, Ytint=1 b) a label is display : Ciecam enabled

When Ciecam disabled a) cat02 and Ytint = calculated values b) a label is display : Ciecam disabled

:)

[heckflosse]

I still remember the first latin sentence I learned: Lucius est rusticus.