No crash for me on guided filter with the today build.
Here is another edit of the Sonly Alpha 6000 shot, with a less saturated and IMHO more natural look:
DSC09850-2.pfi (96.2 KB)
I have used a combination of two TM curves (gamma + linear/log) and a standard curve, all applied to the residual image of a guided blur. The details are added back to the image after the TM.
Personally I am very often combining the “dynamic range compressor” and the “tone mapping” modules together, one after the other. In fact, the output of the dynamic range compressor tends to be too flat, and and S-shaped tone mapping curve helps to recover mid-tones contrast.
So, I was thinking that it would probably make sense to combine the two in a single tone-mapping module, where the compression and tone mapping steps are accessible from a single UI panel.
What do you think?
For those interested in the details, the dynamic range compressor is actually nothing else but a gamma curve applied to the residual image of a guided blur. The gamma curve is scaled so that the the mid-gray point is preserved, and the exponents for the regions below and above mid-gray are adjusted separately to have independent control over the shadows and highlights.
Well, that’s what I’ve been doing in my last edits.
Except El Zorro, in which I didn’t use the compressor, because I thought that image hadn’t a great dynamic range. But this evaluation wasn’t scientific at all, just a visual guess.
Won’t there be cases where the compressor is too much? (Again, no theoretical basis, just speculation)
I think the compressor should default to “zero compression”, because as you say this is not always needed.
By the way, the Zorro image does not even require the filmic tone mapping module, as one could use normal curves instead.
In fact, the filmic tone mapping is really needed for high contrast images, typically those in which an positive exposure adjustment is needed to put middle grey at the right place, resulting in blown-out highlights. Then the highlights compression of the filmic curve can gently bring them back in the output display range…
Would this new compression slider replace the Exposure one that shows on the tm’s?
Actually, I don’t quite understand its usage there … why not adding a Basic Adjustment layer before tm, if you need to change exposure?
Same here since the introduction of DR tool, you can see that in almost all recent playraws where I’d used PhF, the DR tool named DR Gauss and the TM > GRADE. Both in each group, DR with a couple gaussian blurs to feather further ( a shop for silk sheets) Its boundaries and if I recall correctly also a mask in the group. The TM in softlight mode (I think) and inbetween to colour space shuttles. Lately I edit everything with Raw colour and gamma 1.8. Example >> [PlayRaw] Another view from the mountaintop
but it would crash latest PhF version!! the latest (hoji) 20190123 opens it fine
So, I was thinking that it would probably make sense to combine the two in a single tone-mapping module, where the compression and tone mapping steps are accessible from a single UI pane
That’s sounds neat
I am of two minds about this one because I don’t necessarily use both together. I mostly use
tone mapping and not
dynamic range compressor, if I were to use them at all. I would recommend that you keep the drc as a module and also incorporate it in tm. However, I am still hesitant because the list of tm parameters are getting long.
I’m also wondering about this.
Not only long but also wide. I don’t like how the module window keeps on changing size on me because of text length and general layout. Perhaps @Carmelo_DrRaw could also look into that.
I’ve no experience about drc, but I’ll make a try.
My experience with filmic on dt turned me a bit cautious with all in one module, specifically when there is no neutral setting. Both crc and tm correct the image by default and I think there is no way to avoid that (in the curves above I haven’t seen any straight lines ).
Then, combining both, you start with two opposite corrections and you don’t know exactly where you are.
So, unless you can deactivate one or the other I would prefer (a lot) to keep them independant.
Another point pushes me in same direction. I don’t find the histogram very readable and I miss it to control what I’m doing with the sliders (maybe a log y scale would expand it better …).
My two most recent filmic curves can be “neutralized”, at leat in the sense that they can provide a diagonal curve, but values above 1 are clipped:
The sliders in the DRC can be set to “0”, which corresponds to “no compression at all” or “output equal to input”…
@Carmelo_DrRaw You may have seen this but didn’t find the need to respond. To me without the labelling, the curves you are demonstrating to @phweyland are “nonsense” because we don’t have a frame of reference.
I know that the values won’t be as static as other processors’ because the ranges could vary depending on the overflow. I just find myself looking less at the curve and more at the preview.
I missed that ! So that’s fine. No, excellent !
I had missed this one too. As says @afre some figures on the graph would help.
Sorry for being silent on this, but I must admit I have been focusing much more on the math than on the usability and communication during the past few weeks
I totally agree on the labelling of the axes, and I think I find the current setting rather reasonable: the horizontal axis goes from 0 to 2, with mid-gray at 0.5 (the axes encoding is perceptual and not linear, to better see the shadows), while the vertical axis goes from 0 to 1. The continuous vertical line in the middle marks the input value of “1”.
What do you think?
I am thinking more of the long term when you support HDR and OCIO more openly. The axes would be dynamic but the idea of having the middle vertical line as mid-grey is good (at least for now; we can move it later if need be). It would also be good to indicate the encoding of the curve because in PF this depends on the module and therefore could be confusing if omitted.
I was just going to publish this one on its normal thread when I realized a cyan artifact at the bottom, center-left.
Is this an out-of-gamut pixel (or pixels)?
_MG_1074.pfi (37.3 KB)
Then, by zooming at 100%, I realized there are also a couple of artifacts (the string lamps at both sides of the entry plate):
There are also black artifacts on the red parkas, but I believe those are an expected result from the saturation masks I’ve used.
What do mean the values between 1 and 2 ?
The artefact was due to a wrong handling of negative channel values, leading to NANs. This is fixed in the new packages from today (will be ready in a little while).
Those are artefacts coming from the sharp saturation mask you are using. A little bit of gaussian blur helps a lot to mitigate them (as the mask is on the saturation, there is little risk of introducing visible halos with the gaussian blur):
The NAN’s have gone, thanks!
Thanks for the tip!