I set the parametric mask to Hue and used the +eye dropper to select a blue area. Then I activated the mask view applied the mask blur to spread it out so it’s blurry and uniform across the region. That’s the critical part. Sometimes you have to play with blur, feathering and contrast to get it right.
1 Like
After scrutinizing the different results, I think the main problem is to keep the details that are present but hidden in those blue regions and let them appear in the output image.
Looking at the hairs of both singers but mainly of the woman, it seems that more or less some processing cannot reveal those details. The first exemple from @aadm is a clear exemple of the absence of detail in hair (no offense intended!). The transformation of blue in black does’nt always improve the situation if the details remain hidden.
So my conclusion is that the issue is not the presence of the “nasty” blue in itself but mainly in that case the loss of the existing details due to a weakness in the processing pipeline starting perhaps with the choice of a suitable camera profile.
I spoke of defective input profile, sorry if I offended somebody, but english is not my native language. Thanks @ggbutcher for the clarification about camera profiles.
Actually, they’re all ‘defective’, in that they’re all just approximations of space on the spectral response of the camera. Even the SSF-based profiles I’m currently making are anchored on the 24 colorchecker patches and surely miss characterizing colors I haven’t yet lamented. I’m going to try making a few profiles from other references, like the Munsell set (1600 patches!), see what happens…
What I did for my entry isn’t so much to make it look impressive but to demonstrate the utility of a good mask. This is the one I used to brighten the blues.
Small size
But we can do better after we handle the blue. Notice that the mask covers only a part of the hair; viz. the blue parts. To recover detail, after mitigating the blue, we should modify the mask so that we don’t see any hair detail; i.e. the mask includes all of the hair instead of only the blue strands. (Self-bookmark for future gmic exploration.)
@Jade_NL: You have a straight line at an angle in contrast equalizer. I don’t find that among the presets. How did you get that?
Also, why do you use tone curve and not rgb curve?
This is based on the sharpen preset. I used the mix slider to bring the right side down. I now notice that there might be a visualization bug in this mix slider.
I remember also playing with the chroma setting and not liking the results, so I double clicked to reset it. This also resets the mix slider to 1.000 even though the actually setting for the luma tab is +/- 0.600
- It’s situated above filmic and thus it saves me the hassle of moving yet another module,
- It has L*a*b options that I use at times,
I only use the rgb curve in combo with the exposure module to anchor my middle grey early in my edit process, but that is a temporary use and it is disabled once I nail the grey point I’m after.
@Jade_NL
Thanks for the answer, Jacques. I appreciate your help.
To study and learn from what others do I have two installations of dt3.3. One is for editing and one for examining the development of the xmp of interest. For anyone who is interested in trying that, it is important that in settings for the second, examination installation, under storage/xmp, un-check: write sidecar files for each image.
I have been going through your xmp and matching the settings on my own xmp. As I go, I compare the look of the photo images and also the histograms and the module tooltips of settings in the history. I use the waveform histogram. Everything goes well until I set up color balance, although there are some small discrepancies between my tooltips and yours earlier.
The tooltip for white balance for your xmp is:
while mine is:
I don’t know where the emerald nan setting comes from, therefore I can’t understand the difference. As far as comparing the images and histograms at that point, I can’t see any difference.
Later, for filmic your tooltip is:
and mine is:
There is a very small difference in white relative exposure, and a bigger one with hardness. Since that is auto-set, there seems to be nothing I can do about it, but the fact that there is a difference would seem to indicate something different about the images. Your tooltip says you are using the 2019 version of the spline generator, although in the filmic settings, color science is set to v4(2020). At any rate, I detect no difference in the graphs, nor in the photo images and histograms.
Coming at last to color balance, at this point obvious differences in the images and histograms appear.
This is your setup:
Mine is exactly the same.
Your tooltip and mine to the right of it are:
lift[0] appears to be 1+lift factor, which corresponds to gamma[0] and gain[0].
lift[1] appears to be 1+lift saturation, while lift[3] is 1-lift saturation.
Your gain[1] appears to be 1-gain saturation , while my gain[1] doesn’t seem to correspond to anything.
My gain[3] appears to be 1+gain saturation, whereas your gain[3] doesn’t seem to correspond to anything.
I haven’t been able to decipher lift[2] and gain[2].
Do you, or does anyone, have an explanation for this?
Too be honest I haven’t put that much time into the latest development version.
I did notice differences between 3.2.1 and (at the time) current master. I asked about it and some of it is explained with this reply from Aurélien Pierre.
I’m assuming for the moment that there are other tweaks and adjustments done to the algorithms that will show (very?) small differences in the end-result when comparing the same settings in 3.2.1 and 3.3.
I opened the above image in 3.2.1 and, after copying both file and xmp to my 3.3 work area also opened it in the latest master: There’s a very slight difference in luminance, visible in the dark(er) parts. Development version 3.3 being just a tad darker.
I have noticed the new tool-tips in the the development version, which is rather nice, but I haven’t looked at the actual numbers and their meaning just yet.
Anyway, that’s all I can say about your findings. Maybe a developer can shed some more light on that.
There should be no difference in algorithms between 3.2.1 and 3.3. Same parameters should give the same result. Only defaults settings have been touched up. Under the hood, it’s all the same.
lift[0], gamma[0] and gain[0] are the luminance factors. The [1], [2] and [3] are R, G and B factors respectively. Saturation and hues are computed dynamically from/to those RGB params normalized in luminance, they are not used in the actual algo (they are UI only). They are all compensated such that 0 in interface == 1 in params == neutral setting for the parameter (no-operation in the algo).
So if any set of settings/XMP produces different “interpreted” parameters in different versions of dt, this should be reported as a bug.
1 Like
I loaded Jacques’ xmp in dt3.2.1 and compared it to 3.3 and found no difference in color picker samples: rgb: 57, 54, 50 for both. Lab had a small difference: 3.3: 22.95, 0.68, 3.05 vs. 3.2.1: 22.96, 0.68, 3.05. I wouldn’t know how to get interpreted values for 3.2.1.
BTW, @Jade_NL, I think you probably captured the look that really existed at the time. I am very impressed with your interpretation sensibilities.
I opened the RAW in two installations of 3.2.1 with Jacques’ sidecar loaded. In one installation I compressed the history stack at filmic. I then set each parameter in color balance, working my down from top to bottom. When I reached gain saturation, setting it to 41.01% should have made the images match. Instead, there was the same mismatch as with 3.3 that I reported above. I discovered that setting gain saturation to 32.86% made the images and histograms match, as far as I could detect by eye. Color picker revealed the same rgb readings but slightly different Lab readings. 32.86% worked in 3.3 also. Is this a bug that should be reported, or an anomaly of just this sidecar, or does nobody care?
I thought I’d use color lookup table in darktable just for kicks and I think I got a decent result with it.
No other edits made, I just tried to remove the blue.
20191201_NIK1145.nef.xmp (7.4 KB)
2 Likes
If you can reproduce this behaviour with other images then it seems to be a bug, or at least a point that needs attention and should be reported (as mentioned by Aurélien in a previous post).
Hi @ilia3101 the play raw exists so our users can learn from other users. We generally ask for a sidecar, and if not thatz then an explanation of what was done.
In your case, nobody can learn from this, though the result is nice.
@paperdigits Thank you for explaining!
I am working on a new image processing module in MLV App (github.com/ilia3101/mlv-app)
This is how the output looks with only whitebalance/exposure adjustment (default S-curve).
2 Likes
May I ask how the camera-colorspace is massaged to fit into sRGB? A simple matrix? Two matrices with an intermediate connection space? Spectral sensitivity measurements? Those nuclear blues are handled nicely! Also: skintones look natural.
I found the reason blues look so bad isn’t necessarily because they don’t fit in the sRGB gamut, but rather because camera RGB+matrix give negative luma (Y) values for blue, the colours are then per-channel clipped (I think in ProphotoRGB space for most raw processors). The result is the completely non-smooth transition in to flat blue we usually see.
Kind of a solution:
Convert to xyY from camera RGB directly (combine the CamRGB->XYZ->xyY process in to one step, just simplify the math), then replace the Y value with a new Y calculated using the matrice’s Y coefficients for G and R, but excluding the negative coefficient for B, maybe use something small like 0.05 * G coefficient for blue instead.
The problem is that many cameras, including the 5D mark 3 which I use, render blue light as pale violet, a fact hidden by the traditional clipping process I described above, this could be corrected with hue adjustments maybe, but that may possibly ruin colours that are meant to be violet, this would be different for every camera. Maybe spectral data could be used here somehow
2 Likes