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)