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