In a handful of incidents Filmic RGB with Reconstruction on suddenly jumps from showing the smoothed out highlight to showing a flashlight like white circle in the same places (yes, it can at least be a pair when two blown areas exist).
If I disable Highlight reconstruction, the ‘flash’ disappears (also it’s not shown in the navigator).
In this case the highlights are not blocked, just too white to look at, and I wanted Filmic to put a bit of tone in. This example is with a DNG file from DxO PureRAW 2 (it was further run through Adobe DNG converter to make it loadable in Darktable) - but I think… I have had the same phenomenon with a native ARW file.
It’s probably my GPU that can’t follow - it’s a NVIDIA GeForce GTX 1650, 4 Gb card, which is about to be replaced anyway. But I am curious if others have experienced this phenomena on their Win environment with better GPUs?
Darktable 4.2.2. for Win 64.
This looks like the know problem with the perceptual brilliance grading -> highlights slider. Atm the only way to solve this is to not use too high values on it.
Like I said, I’ve been using the DxO DNGs for years now. And the OP let it seem that he had the same problems with ‘direct use of the ARWs’ so it seems like a sony camers thats supported by DT.
I’m always afraid (no proof ) that running it through Adobe dng creator replaces matrix values out there by DxO to let the colours stay correct.
Maybe pure raw uses a sort of compression that DT doesn’t understand , but why would Photolab not use it? Pure raw is like the ‘easy mode one click auto mode’ for Photolab.
I’m not a fan of using DNGs when the raw files work, but that’s not the subject here.
It looks really like an over-enthousiastic use of highlight brilliance in color balance rgb in combination with hightlight recovery in filmic, and this is not related to any limitations in camera, file format or GPU.
(Just take any file with bright highlights, push the brilliance, and use filmic highlight reconstruction… This phenomenon was iirc the reason filmic’s highlight reconstruction can now be disabled completely, in older versions putting the threshold even at +6 EV wasn’t enough to avoid the problem…)
And to somehow set the white fulcrum automatically, all the time. As far as I understand from Aurélien’s explanation, it’s not an artistic/creative control, like filmic’s relative white exposure, but a technical one that must be set correctly, based on the brightest part of the image.
The DNGs from DxO PureRaw 2 (and probably 3) need to be run through Adobe Camera Raw to be accepted by Darktable - Topaz’ don’t, but they still show edge artifacts.
And the glow phenomenon was not due to my old GPU - it remains with the new fast 8 GB one.
So, this means that the highlight slider in Color Balance RGB can’t be used in a critical interval even before the red clipping warning. That’s a strange rubber like rule to adapt to.
The burn through phenomenon with Filmic RGB, Reconstruction enabled, is not limited to DNG files - it happens with my ARW raw files too.
I use the waveform graph a lot and it shows a dotted upper line for the maximum light level in DT. As long as this line is not passed, everything according to light management should behave as expected, i.e. without breakdowns before even red clipping warning occurs.
Just an opinion from an average user - and a non technician.
Yes, because it has nothing to do with the specific RAW file. It’s purely about the processing algorithms in DT.
Quoting AP:
Problem two is which should be user-defined in the mask options because in a scene-referred pipeline, white is unbounded. This is meant to normalize the scene brightest value to 1, aka a virtual medium white. But of course, people don’t do that.
Here, it’s multiplied by 1.6 as per user request, and I bet the white value didn’t got set properly, say 1.3 × 1.6, you got your 2.08 at the output… What you are creating there is a super-nova white, as per user request.
Now, filmic HL reconstruction does something useful : blurring the edge between clipped and non-clipped. The threshold was set such as it would practically disable reconstruction, only because people with weak computers complained. Blurring is a kind of diffusion. You diffuse super-nova white. You got what you asked: a super-nova glow.
Funny, now my DxO PureRAW 2 DNGs load in DT straight away. At least the problem was not with me alone, I have discussed it in another group, where others experienced the same rejection and solved it via ADC. Maybe DT has changed recently. For sure my environment has … In that case a new stronger GPU would be the only answer.
That’s typical - I thought I should repeat the problem and document the response from DT, and then… everything works, as if it was a DNG from Topaz Photo AI.
All right, this just makes my workflow that easier.
The problem with the super novas goes over my head. It’s not practical for newcomers to deal with buttons or sliders that unexpected make super novas in their images. And complex explanations about how to avoid them are not easy to sell.
What goes on under the hood should stay under the hood and explode there (imho).
But that’s just it, darktable tries to hide as little as possible “under the hood”. That gives you the most freedom to edit your image. The flip side is that it also gives you the possibility to shoot yourself in the foot…
Also, keeping an eye on the hstogram could give a hint something is off when you push that brilliance slider…
And while the explanation of the “supernova’s” might be complex, the way to avoid them is not complicated.
Not wanting to believe the answers you get, doesn’t help though (it has been mentioned that neither the file format used nor the age of your GPU is the issue here, but you kept mentioning those).
I think the problem I mentioned earlier - with staying under the upper dotted line in the waveform - and thereby avoiding red clipping warning - should be considered responsible and safe behavior with any ‘weapon’ - but still the super novas go off - long before my foot comes in the way.
Imo this is due to an inappropriate behavior in the way Filmic RGB handle the infinity theory for the scene referred process. I hope Filmic RGB is an open book for the current DT developers (i.e., with no secrets left behind by Mr. A.P.).
No, it’s not filmic. You have asked color balance rgb to create a spot that’s so bright you’d be burnt to a crisp if light so intense ever rhit you. Then, in filmic, you asked to blur extreme highlights (because that’s all filmic’s highlight recovery does). As a result, the super-bright pixels were blurred to smoothen the transition.
I know it’s inconvenient to switch to the last tab of color balance and pick the white fulcrum, and to pay attention to not raising the brilliance above 1.2. But it is what it is, at least for now.
In that case, I think you’ll have to start coding a solution yourself, as the current DT developers don’t seem to feel there’s a problem with filmic in this respect.
There are no real secrets in filmic, if you can read the code. What happens there is clear (there may be questions about the “why”, perhaps). The same goes for color balance rgb.
In this case, it’s simple: color balance rgb + filmic give you exactly what you asked for. If that’s not what you want, well…
Note that even with the white fulcrum set, you can still get the “supernova explosion”. Not surprising, really, if the white fulcrum is set from the input image. But that means that you can just use the brilliance sliders, remembering to back off a bit when it blows up. (going over 20% brilliance might not be theoretically correct, but as long as you get the image you want, who cares?)
rvietor, I just happen to know how most raw managers work - experienced from the drivers seat. They behave well when it comes to light management. I am less interested in what goes on in the garage, and I don’t want to code anything - or even understand what the code means - I am a USER.
) that running it through Adobe dng creator replaces matrix values out there by DxO to let the colours stay correct.