Split rock again with a clean sensor and a wider lens
B&W was a jolly good idea, thanks @Claes!
Unfortunately that scene is now over 300 miles away so I wont be going back any time soon
Sooo, how far would you crop it while keeping it clean?
Any other B&W treatments?
Enjoy
IMG_9849.CR2 (21.5 MB)
IMG_9849.CR2.xmp (15.5 KB)
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License
Thank you for this play! A nice rock 
RT 5.9 dev, power lines removed with Gimp
I can’t help, but @Claes’ framing reminds me a bit of Arnold Böcklin
Isn’t it fantastic how many interpretations/versions
that can be produced from the same raw material???
Have fun!
Claes in Lund, Sweden
Thanks for posting
darktable 4.0.1 (Ubuntu 18.04 / Flatpak install)
Strange .jpg output iwth my usual export options (cannot explain the large yellow dot)
Any help ? Could you reproduce this strange behaviour ?
Salut, @Jean-Marc_Digne!
my usual export options
What options, please?
No need to reply 
I tested two export settings up here — and they both
look peculiar… I will dig deeper…
Cordialement,
Claes en Lund, La Suède
As Aurélien explained on Github (ignore the tone, concentrate on the content):
Problem two is which should be user-defined in the mask options because in a scene-referred pipeline, white is unbounded.
The brilliance adjustment multiplies B by some coefficient between 0 (-100% in GUI params) and 2 (+100% in GUI params). Problem one is the backtransfom is stable only up to , which maps to… 3.89e+19 Cd/m². […] The solution is to narrow the range of the brilliance slider to -20;+20 %. It’s a GUI problem.
One option is to disable highlight reconstruction in filmic, as it disperses that nuclear spot.
The other is to use color balance rgb as AP suggests. He didn’t intend brilliance as a kind of contrast control.
@Jean-Marc_Digne
OK, I have dug a bit deeper, and found the following
a) in dt, start with compress history stack.
b) the peculiarity occurs in history stack #16, sharpen, where you increase radius, and amount.
c) reset sharpen parameters, and peculiarity is gone.
Why it happens, I have no idea… (Evidently, István knows better, see hit posting one level up…)
Have fun!
Claes in Lund, Sweden
Thank you for your detailed explanation, Thanks for your time
Thank you for your detailed explanation, It works …
There seems to be another bug. Even if I disable both filmic (so there is no chance of any highlight reconstruction), and color balance rgb (so no chance of brilliance adjustment), I see always different artefacts when I zoom in to 100%, and just move around:
With only the following modules active, I still get them:
Check, for example, that directly under the bright stone surface on the left, we have 2 artefacts in the 1st image, but only one, smaller in the 2nd.
Disabling haze removal (which has given me trouble all the time) removes those weird artefacts – but, if your filmic and color balance rgb settings are used, shows the problem that I first suspected (filmic trying to bloom highlights).
With haze removal on, filmic always blooms elsewhere, or not at all
Dragging the view a bit:
I think this is a problem in haze removal, but…
Disabling haze removal produces filmic bloom:
With filmic disabled, I was able to zoom in on the ‘epicentre’ (I disabled crop as well).
With all profiles (histogram, output, screen) set to linear Rec2020, the colour picker reads a max RGB of 154, 124, 0:
Which is rather strange, as that highlight on the glass seems to be rather bright.
A bug report is probable needed, but I have no time now. Will try to file one during the weekend.
Since we’re doing creative edits, some stable diffusion AI versions, starting from a vertical crop :
The edit was done on Windows, without OpenCL, using the latest ‘weekly’ build. I cannot reproduce the dehaze issue on Linux, with or without OpenCL, using the latest code from master, built locally (--build-type Release).
