There is a huge difference between the old and new version of this tool. Finally, it’s useful! Great job!
Does anyone know what’s making the banding appear in the gradient images above? Can the algorithm be fixed so that it goes away?
Also think it’s a big improvement, the RGB setting with highlights makes for nicer looking skies rather than turning it grey…
@agriggio, have you any thoughts on this? Also I’d like to understand what the radius does. It seems the tool says “I will work on the shadows & higlights, evening things out, but maintaining some differentiation between the tones present within the given radius”. Is this anything like?!
No, sorry, I didn’t take a look.
Essentially it controls the amount of blurring of the masks uses to isolate shadows/highlights from the rest of the tones (what is a highlight or a shadow is controlled by the threshold sliders). The larger the radius, the more gradual the transition will be.
As the example is lowering the highlight AND raising the shadows there will be one (and possibly two) positions in the gradient where part of the gradient coming from the light side will be darker then the part of the gradient coming from the dark side. With the radius being set to zero there will be a step at that position and thus the algorithm will try to raise contrast there.
Here’s an ugly sketch trying to illustrate what I mean:
- The gradient
- The gradient with the highlights being lowered and the shadows being raised, The part in the middle represents an area unaffected by both
- The contrast enhancement done by the algorythm
My guess, without knowing the algorithm.
@RawConvert could you post the same example with a larger radius?
hi McCap, I’ll see about some more examples, however the banding disappears with a decent radius, as I recall. You are talking about the gradient from one direction interacting with the opposite direction. I did the gradients like that thinking if there was going to be a problem, it might well be a boundary issue along the join. However that’s not really the case in my view - the banding is across a wide stripe and I would think not connected to the adjacenet stripe.
I think I get your diagram - I’ve seen much uglier things! - do you mean affected by both rather than unaffected? Anyway, surely you should not be rasing shadows that are already brighter than highlights you are lowering! (if I understand correctly) Perhaps the tool should warn you about attempting that? Hopefully @agriggio will comment.
P.S. Radius was 1, 0 not allowed.
@RawConvert I believe that there will always be “issues” whenever you compress the dynamic range. Try exporting a neutral profile image from RT and try manually taming it using 1-2 curves. It isn’t easy, at least for me!1
I haven’t used either version of the shadows-highlights tool, but based on what I have read, its improvements are substantial.
PS 1 Lately, that is what I have been doing with my recent PlayRaws. The results don’t get a lot of likes but I have been hard at work experimenting on ways to tame the dynamic range and making everything super clean. That is why I ask the reader to zoom 100% to see the difference. I use simple curves and other simple ideas, so it isn’t like I am doing anything crazy like what others are doing with the venerable RT, DT, GIMP, etc.
hi afre, I don’t see why. You can compress using simple scaling or a decently-smooth curve, and I don’t think that could ever cause artefacts like banding or noise - as it seems you are finding!
You may think it’s pernickity that I’ve gone on about this, but lots of people spend lots of hours using RT, DT, etc and I’m sure everyone, especially the developers, want the apps to be as good as possible. Being aware of shortcomings and possible bugs can only be a good thing, even if they can’t be fixed for whatever reason.
Is there a case for more organised testing? Should some or more of us users work more closely with developers to test changes?
1 Like
Absoltutely! Very good idea!
1 Like
Definitely, that is what the thread and we’re here for!
1 Like
I’d love to have a pool of sample RAW images that are particularly suitable for testing shadows/highlights adjustment and dynamic range compression in general (actually, I believe the two things are the same). I am also doing some work with edge-aware blur filters and dynamic range compression, and it would be great to be able to directly compare results. I am mostly playing with the concepts and examples provided here.
What do you think?
Yes and the banding shifts if you change the tonal width. The raised shadows doesn’t quite reach the lowered highlights that is why there is a wider stripe.
What I find strange is what happens in the raised shadows:
Original picture was a jpg gradient, white on the left and black on the right.
See the black pixels they stay black for some reason when raising the shadows. The halo on the dark end comes from raising the radius. Which means he seems to detect an edge there?
These were the settings:
Hi,
I have no direct experience with the bilateral filter, but I’m a huge fan of the (fast) guided filter. It’s a simple, efficient, and yet extremely powerful tool. It can be implemented in a few lines of code, and has many interesting applications, not just dynamic range compression (e.g. also dehazing, denoising, feathering, detail enhancement… see the paper for examples). Here is a little demo of some of its possibilities (note, this is my “playground” version of RT, it’s not in the official repo):
https://filebin.net/8qeqmo4htk4i67zp/Peek_2018-10-19_14-03.mp4?t=01i9fcft
1 Like
I’m also very much interested in this option, as I still have few “theoretical” difficulties with the bilateral filter and its proposed optimizations (in particular those that rely on image down-sampling).
Could you point me to the relevant file for the fast guided filter in RT?
Thanks!
P.S: could you remind me in which post I can find the picture your are using in your video? Thanks!
I LOVE the guided filter. I use it and link it whenever I have an excuse to do so. A lot of sophisticated applications and derivatives have been researched since. At its worst, it performs as well as the bilateral but is faster and simpler. … At least that is what I have read and experienced so far.
Just did a quick test with your settings, 100% view, RGB and Lab, I’m not seeing the halo or anything strange -
There’s some similar stuff here to my “Tone Enhance” filter in G’MIC (bilateral + tone masking), so perhaps it’s useful to show a breakdown of how the gamma adjustment part functions. It can possibly be simplified further.
Edit: I must point out the example here is from a quite heavily compressed “sample” image in G’MIC.
- Median then bilateral the image, convert to luma then split to 3 tones
- Create a “gamma mask” from that with the user supplied values (an exponent value per pixel)
- Apply it (raise to that exponent), example here uses gammas 2,0.8,0.5 for shadow, mid, highlight
G’MIC code stripped down to those parts:
gcd_tone_simple : skip ${1=1},${2=1},${3=1},${4=128}
repeat $! l[$>]
+n 0,255 median. 3 bilateral. 2%,30 gcd_srgb2luma.
sub. $4 +abs. negate.
+max.. 0 min... 0 abs...
mul... {if(iM#-3>0,(1/$1-1)/iM#-3,1)}
mul.. {if(iM#-2>0,(1/$2-1)/iM#-2,1)}
mul. {if(iM#-1>0,(1/$3-1)/iM#-1,1)}
add[-3--1] 1 mul[-3--1]
m={0,iM} div[0] $m pow[0,-1] mul[0] $m
endl done
The main thing I wanted to show is that G’MIC is very good for prototyping this sort of thing (there’s also a “guided” filter in G’MIC).
1 Like