No crash for me on guided filter with the today build.
@gadolf
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.
@afre @chroma_ghost @nosle @gadolf @phweyland
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 - #19 by chroma_ghost 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.
@gadolf The exposure slider is everywhere, including in the raw developer. I remember having this conversation with @Carmelo_DrRaw but I donât remember if they are all the sameâŚ
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!