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.
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?
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.
I just made a small modification, upstream of the algorithm. When you select “Low sampling” (probably to eliminate some colors, hence this choice), if some conditions are recognized (tint camera > 1.02, and others), then “Camera settings” are not used
But be careful, no miracle, there will always be unresolved cases
I did this morning (19/05/2023) an update both in wb_reseach (3ffbee8) and in the Pull-request (9cfa5ba).
The link for executable is the same as above
This version tries to better determine “upstream the algorithm” the temperatures and starting green, in the case “Low sampling & do not use Camera settings”
Reminder, this mode which does not use Camera data already exists “upstream the algorithm” and also inside the algorithm. But in this case we “force” the system (when green camera > 1).
Bonjour. Lien du test de ce jeudi 25 mai: https://drive.shadow.tech/s/mbESrMtfkBok7Sb
Un NEF et ppa. Les saisies-écran des BdB à tester (Low et Entire) et plusieurs BdB (APN,Lumière du jour,Ombre,Nuageux) pour comparer. Amicalement. Alain
Compared to my last interventions I make a point of the operation of the system to date:
modifications have been made upstream and just at the end of the algorithm (which is almost unchanged)
these last modifications (upstream and end) make it possible in almost all cases to offer 2 settings (temperature and tint) with indication in the GUI “Best or Worst” of the alternative solution.
3 samplings are offered:
Force uses of entire CIE diagram: This approach may seem unnatural, as in some cases it involves taking into account imaginary colors. Nevertheless, it is the one that is ‘normally’ integrated into the process (Raw process, demosaicing, etc.). The conversion to the “working profile” which can also handle imaginary colors comes later.
Medium sampling – near Pointer’s gamut: in this case I use the “Beta RGB” profile (B.Lindbloom origin) which seems closest to the visible colors in reflected color (Subtractive color mixing) - Rec2020 gives very close results .
Low sampling & Not use camera settings: this choice restricts sampling to sRGB (which roughly corresponds to the gamut of the Colorchecker24) and therefore eliminates high gamut colors. I have added to this choice another approach to the starting point (temperature, green) by calculating this starting point according to various parameters from a mix of “Auto WB grey” and “Camera”.
I replaced ACESP0 by JDCmax (new profile) for maximum sampling. The whole CIE diagram is not fully covered, less than ACESP0, but more than ACESP1 with different primaries. Imaginary colors may occur slightly in blues and greens with very high gamut(between 515nm and 530nm)
Primaries
Red 0.734702 0.2653
Green 0.0219 0.903
Blue 0.1206 0.0016
White point: D50
Just for information. If you compile either the wb_research (83e823f) version or the PR. You can see (it slows down the process) the display of the xy values found by the “sampling”. Thanks to Reffort for this work. These values are not sorted by number, so you will see values from 1 to 10 given…which of course are not retained. I would remove this feature (it can easily be re-enabled by compiling) so as not to slow down the system.
And if you activate “verbose=true” (options) and change the value of “Itcwb_deltaspec” (options), for example “Itcwb_deltaspec=0”, then you will see in the console the values retained and classified in ascending order. The smallest possible retained value (in number of sampled data) is 400*9 = 3600.
Compared to the display of data in the GUI, these can be different, eliminated for various reasons (for example being more restrictive for high luminance values, or x or y too small).
Thus you will see the influence of the sampling and the values chosen for the spectral data.
As a reminder, you now have another “working profile” at your disposal “JDCmax”. Large, less than ACESP0, but unlike Prophoto, imaginary colors can occur in extreme greens instead of blues, which from my point of view should be less of a consequence. I looked for a name, and many names have already been registered (alpha, beta, etc.)… This one must not already be taken
Version: 5.9-443-g932568e5f
Branch: wb_research
Commit: 932568e5f
Commit date: 2023-06-06
Compiler: cc 12.2.0
Processor: x86_64
System: Linux
Bit depth: 64 bits
My image below is now back to looking very warm. it sets a temp of 7002 for a sunny daylight photo because the camera was accidentally set to shade wb. For a while it was corrected to a reasonable daylight temp.
I also noticed another thing. If you set wb to temperature correlation using the file browser “batch edit” panel (after resetting to neutral) and export the image the wb doesn’t seem to be calculated using temperature correlation. It seems you have to open the image in the editor to trigger the algorithm. It won’t run on export even when set? It may be something I’ve done but so far my testing suggests this is the case.
Now that the algorithm systematically has 2 alternatives, the question arises which other starting temperature to put.
The algorithm alone, without touching either upstream or downstream, is capable of modifying approximately ± 200K, of course by adapting the green.
With “medium” and “Close to full CIE” sampling:
Between 4000K and 6000K, the downstream process amplifies this value by 200K.
I modified the rule above 6000K, to bring the second temperature back to around D50. Which should improve the rendering in this case.
For “Low sampling” the upstream operation is very different, taking into account both “AWB grey”, “Camera” and the values of “green”.
Other internal improvements have been made, which bring little or no interference with the results, but concern either the borderline situations (gamut) or the GUI.
I had some trouble with commits, and the wb_research branch diverged. To simplify and avoid malfunctions, I deleted this branch and created “wbresearch” (dc8bd18). I did not update the PR.
I just added in the samplings, “Camera XYZ matrix”, thanks to Reffort, matrix which is directly derived from the color matrix.
As these instructions (sampling) are before white balance and before assigning a profile (working profile), there is no “right” answer or solution.
Here is a new build which should give almost similar results (differences of 1 or 2 K) on temp.
There is no revolution in the code, but a rewrite of certain parts to better take into account Observer and 5.9. This led to quite significant changes.
I think this version is close to finalization - except for minor improvements (comments, cleanup…) made in wbresearch (2b35ed0)
@jorismak
I don’t know Gmic, and therefore don’t know how to port the code. A few landmarks
the basic data is in Raw just after demosaicing;
the algorithm compares the data of the image - through a filter taking into account a “sampling” (using CIE xy diagram) and the starting data “temp” and “green”, and spectral data (429) which will vary as a function of the temp;
the C++ code does not call on complex functions, but on mathematics (matrix calculation, student method) and the laws of colorimetry (Planck, etc.). ;
the number of lines of code is close to 5000 lines;
the code is distributed between the algorithm itself, which at the end has a feedback loop and an upstream part which serves as a switch.
@jdc I just tried the latest build Version: 5.9-499-gcb8330f64 on Windows 10, and it seems all of my old PP3’s crash when when I try Automatic > Temperature Correlation. I have tried isolating the cause but have been unable. Here is a sample of one that crashes it. Bleached.pp3 (16.3 KB)
