Hello Silvio
Thank you very much 
jacques
RawTherapee_Beep6581_whitebalanceopt_win64_release (5.9-366-gf178f39fd) tested with a couple of CR3 files on my Win 11 computer… colors are great, easiest edits I’ve made on these photos to get good color, BUT… the processing is extremely slow compared to all the earlier releases by a factor of 3 or 4. Is it possible that OpenCL somehow got disabled in this release?
Opencl is always disabled in RT. Perhaps these test builds have flags or compile settings making them slower? I’ve not noticed much of a slowdown of my self compiled builds on Linux.
Unless you are referring to versions from more than 1 month ago, where the processing time was indeed significantly shorter (about 4 times), there is little change in processing time.
For 1 month, everything I have added to improve the process, increases the processing time:
- median 3x3, 2 passes, to reduce noise
- 407 spectral colors instead of 201
- in some cases 2 passes
- larger patch in volume, necessary (looped) to optimize spectral colors / patch
- “patch chroma”, optimization
- etc.
In the code that was optimized by Ingo 3 years ago (except the added parts) there are few “OMPs”, we are essentially in complex matrix calculations( never OPENCL)
I’m not saying that we can’t optimize a bit (maybe gain 10 or 20%, but not sure at all).
For comparison I tested on a Nikon Z 9 file on my machine
Last week : 1 pass 250 ms, 2 passes 480ms
Last version : 1 pass 252ms, 2 passes 475ms
That is approximately the same processing times
Jacques
More info: 42 meg NEF files were ok, 85 meg RAF files were ok. The 50 meg CR3 files were the only ones I tried that were this painfully slow. I didn’t try the CR3’s with the earlier predev builds but I don’t remember these files being slow with the older regular dev builds.
Sorry for the vague, imprecise/incomplete reporting.
But the new predev builds are doing good things to the colors! Thanks!!
In fact the size of the Raw file is relatively unimportant, except for the processing of denoise. Once this is done we have a constant system with 237 colors (images) and 406 spectral colors.
Raw file size affects about 10-15% of processing time, perhaps more 20 or 30%
Jacques
@jdc , Thanks for all of your hard work.
I had a chance to play around with the latest build and noticed some interesting behavior / bug.
When [] Use custom temperature and green is checked I set the AWB temperature bias, the temperature changes as expected. But when I click the reset button on the slider, the overall temperature only moves slightly and does not go back t where it started.
The problem is exactly the same with “Green refinement”.
As I explained the GUI of “whitebalance” is complex, and coexisting an automatic process (with AWB bias, etc.) and a manual process (custom) is very complex at the GUI level (at least for me). I solved the problem by preventing when “Custom temperature and green” is selected, the use of “AWB temperature bias” and “Green refinement”.
If someone wants to tackle this GUI problem I see no problem…
To show the time spent by each major phase of the process, I have marked the algorithm with markers, if you compile, and activate “Verbose=true” you will be able to see for 7 parts of the algo, the respective times.
It allowed me to find where the time spent was important. I made an optimization by limiting the scope of the temperature scan (I attach a copy of the console)
“Fourth: from third recalculate spectral: 3283 nsec.”
With this change processing times are roughly divided by 2 or 3 (no OMP, no OPENCL completely useless in this case).
https://github.com/Beep6581/RawTherapee/releases/tag/pre-dev-github-actions
Running executables
Don’t forget to “reset to neutral”, and then choose the pp3 profile you want, otherwise some new settings will not be applied.
Note: “live” tuning of this algorithm is fairly new (?) to Rawtherapee, as the algorithm is complex and requires a lot of back and forth (and excuse my bad english). Thank you again
Jacques
1 Like
Is it possible to recreate the sliders within the new tool and disable the ones above? That way if they behave differently, it’s not as confusing to the user.
Sorry, but I don’t understand this request. However, the addition of the “Use custom temperature and green” checkbox is very problematic at the GUI (whitebalance.cc) and “improccoordinator.cc” level. I don’t know how, and I’m not sure it’s doable.
So 4 options:
- I delete the “Use custom…” checkbox and therefore the possibility
- we leave it as it is now, and it’s up to the user (through back and forth to find a compromise), even if it’s not intuitive
- I put the 2 sliders back, but the behavior will always be erratic (hard to accept?)
- another developer is trying to see if it’s possible, but I wouldn’t make this request myself, because it seems difficult to me (the cat biting its tail)
jacques
I increased the temperature sampling, instead of 134 increments between 2000K and 15000K, there are now 175 (wb_research - b60262c)
Each temperature is associated with the white point (XYZ), for example
T=2605 , X=1.134667, Y= 1, Z= 0.290722
T=4914 , X=0.965682, Y= 1, Z= 0.806658
The calculations are more precise and may lead to small differences in the temperature found, compared to previous versions.
It is important to “reset to neutral”
Jacques
I guess i was basically asking to to separate the new white balance refinement tool from the regular white balance tool. That way if sliders behave differently, its not as big of a deal to the user.
I think I understand (??), but it’s an almost unsolvable GUI problem (at least for me). You cannot have a “with” and a “without” system at the same time.
It’s hard to explain, but the “position on the screen” won’t change the problem of the GUI and the calculation of temperatures, tint, and the action of AWB bias, and green refinment, and it doesn’t matter much to do with the algorithm.
Said in another way, whatever the choices, auto (the 2), camera, custom, at the end we obtain a temperature and a tint (the sliders are the same) which results in the calculation of the wb multipliers
jacques
I just merge “wb_research” in PR.
Several changes:
- the most important, from my point of view, is the increase in the temperature sampling which is now more “finer” especially around 2800K, 5000K, 6500K. In addition I extended it up to 15000K. This finer sampling may lead to small differences in the results found.
- the “whitepoint” which is used in particular to size the patch and to determine “chroma patch” is now calculated from the illuminant matrix and Observer. On the one hand it is more precise, and on the other hand takes into account Observer 2° or 10°;
- in order to allow the use of “Use custom temperature & tint” without imposing it - because it is not “ergonomic” I added in “Preferences” - “Color management”, a checkbox which allows this choice . This supposes restarting RT.
https://github.com/Beep6581/RawTherapee/releases/tag/pre-dev-github-actions
Don’t forget to “reset to neutral”
jacques
You have mentioned this and I have noticed that it is necessary. How come it’s not enough to reset whitebalance to camera and then re-set to itcwb?
I’m wondering because I think that it may be important to be able to reset the algorithm from within the module. Perhaps this is simply because it’s in development and will be solved when in release. It’s just important that future changes to code, after release, won’t require “neutral” to reset the wb algorithm.
I re-enabled (wb_research 9302100) an “auto” feature “update” that I had disabled while working on solutions. This should work “better”.
However some changes like the ones I made require erasing the pp3s (hence “neutral”), I now think that’s over. The algorithm now seems complete to me.
On the other hand the functioning of the system (it is not the algorithm strictly speaking) with “Use custom temperature & tint” is degraded and I think will remain so with very erratic operation.
Should we keep this option? From my point of view = no.
jacques
The gui and workflow with custom is certainly complicated and confusing. In the current implementation I don’t think it’s worth keeping.
The reason for wanting it is that I understood that itcwb isn’t really a white balance method on it’s own but in reality a refinement of camera whitebalance. Itcwb will follow what ever the camera/user set on the scene. Only to reset to use Alt_temp if the values are determined to be suspicious. It’s now working quite well and avoiding very wrong wb. It still makes warmer wb if the camera was set to that though.
I still feel itcwb, even in it’s current implementation, would work better as a tick box in the “Camera” method and removed from “Automatic”. It’s to connected to camera settings to be considered it’s own wb method. This is personal opinion and what I feel makes GUI sense. I fully understand that RT is lacking GUI coders and that I may have the wrong end of the stick! If it’s an issue of lacking GUI coding I think it should somehow be noted as a goal or wishlist to refine the GUI at some later stage.
Of course we can do semantics, but as the designer of Itcwb, and of a large part of the colorimetry of RT, I can say that Itcwb is not only a “camera follower”, but a real white balance. This is probably the most complex algorithm I have designed.
Admittedly, it’s also a question of point of view (and semantics) but Itcwb is at least as automatic as “Auto grey”, only considerably more complex…
If it was only an appendix to Camera, then why have more than 5000 lines of complex code, essentially matrix calculation on colorimetry? Why complicate your life by multiplying matrix of Observer, colors, illuminants (to my knowledge, other software uses often simple formulas without matrix). Of course nothing is perfect, the system fails sometimes (less than autogrey). Like I said no intelligence, only math…
The current GUI which takes into account many parameters (Itcwb is only a “small” piece, at the GUI level), is complex. Adding Observer (thanks to @Lawrence37 ) didn’t make things any easier.
I take note for “Use custom…”, Any other opinions on whether to keep it or not?
Thank you again
jacques
@jdc , will the final version be posted here . .?
@stuntflyer
Of course (I hope). It’s in “dev”, but before it’s in a Pull-Request (PR) which allows the updates
https://github.com/Beep6581/RawTherapee/pull/6643
I just removed “Use custom temperature and tint” and that seems like a good decision. In a majority the use of “AWB temperature bias” and “Green refinement” makes it possible to do essentially the same thing.
As several people told me I reduced the “sampling” choices to 2 (as they were at startup) - “Low sampling” and “Force use of the entire CIE diagram” (default). As a reminder, this has nothing to do with the “working profile”.
I now think this version is finalized in terms of code, algorithm (of course we can change if necessary). It remains to optimize - if necessary - the labels and the tooltips. I am not an English speaker, so if someone can look and let me know these remarks.
After that I think we can ‘merge’ in ‘dev’, this PR as it is.
https://github.com/Beep6581/RawTherapee/releases/tag/pre-dev-github-actions
I update Rawpedia.
Jacques