Poor man dehaze (and remove uniform lens flare)

[heckflosse]

I made some tries with a very simple method to remove haze (and uniform lens flare) from raw files. Well, at least partly. It's a good starting point to add the already existing dehaze tool in RT.

The method is super simple. It just calculates the mininum value from each raw channel and subtracts that value from the corresponding channel.

The idea behind this approach is:

If there is a region in the scene, which does not reflect enough light to the camera sensor, to be recorded by the sensor, then, if there is a sensor value > 0, this value must be caused by haze or flare and not by the scene.

Having this situation and assuming the haze or flare is somehow evenly distributed, we can just subtract it, and surprisingly, it works very well for long distance landscape shots, where there is a lot of haze between camera and subject, and maybe also a lot of flare (internal lens reflections) by using a long focal length which are more prone to internal reflections.

Of course we can not use this method for every image. 1) It does not work on high-iso files where the minimum value is always around zero because of noise 2) it does not work on underexposed files for the same reason

I just works for the conditions I described above.

Anybody interested in a branch? In first step the branch would just spit out the raw black levels for the dehaze/deflare in console.

Ingo

[Floessie]

I already had the pleasure to play with Ingo's patch and it really makes a difference for the type of shots he mentioned. When it comes to me, yes, I'm interested! :smile:

[Thanatomanic]

@heckflosse Will you integrate this with the current dehaze tool as a variant (like unsharp mask and deconv for sharpening)? Or will it become a separate module?

In any case, a branch would be nice to test.

[heckflosse]

@Thanatomanic

Will you integrate this with the current dehaze tool as a variant (like unsharp mask and deconv for sharpening)? Or will it become a separate module?

Don't know at the moment where to put it. Maybe it will just become an automatic checkbox in raw black levels tool (because it does exactly that).

[heckflosse]

Branch follows soon. Have to code three variants (Bayer, Panasonic Bayer where raw value 0 means a bad pixel, and xtrans...)

[heckflosse]

I just created the poor_man_dehaze branch.

To test, you just have to look at the console output and fill in the values in ui by hand. Example:

Console output:

red : 57
green : 155
blue : 112

ui:

[heckflosse]

Here's a before/after (left neutral profile, right neutral + raw black levels). Shooting distance was roughly 7 km.

And here's the raw I used for the screenshot. It's a bit overexposed, because it is part of a bracketing...

D200_20070802_2087.zip

[heckflosse]

Just for the record. When testing this, please also test in combination with the current dehaze tool in RT, as in my opinion the current dehaze tool in RT works better after this black level adjustments.

[Desmis]

@heckflosse Ingo I tested with your image but also with "madeira.dng" this very clearly improves the results....And result is better with "dehaze RT tools" after black levels

Impressive jacques

[heckflosse]

@Desmis Thanks for testing. Sometimes kiss just works fine ;-)

[heckflosse]

A nice side effect of subtracting black levels for this kind of images is, that the auto radius calculation of Capture Sharpening is better after the subtraction. With my example raw linked above I get 0.93 without bl subtraction and (much more accurate) 0.80 with bl subtraction.

[heckflosse]

Another comparison using the raw I linked above. Left with current dehaze, right with current dehaze + bl subtraction. As a gimmic, isn't there a nice face in the image? ;-)

[Desmis]

@heckflosse Perhaps you should change the name of this issue, and call "Smart Dehaze"

A question, for the same file D200_200070802_2087.NEF", the values displays in console are different from you

You red 57 , green 155, blue 112

Me red 225, green 508, blue 462 But it works :)

Do you think we can "auto" this behavior (by passing values to GUI ??)

Jacques

[heckflosse]

@Desmis Jacques, my values are from a different file

[heckflosse]

@Desmis

Do you think we can "auto" this behavior (by passing values to GUI ??)

Yes, that should be possible

[Thanatomanic]

Some testing on my end on a real haze:

Neutral vs. black level modification:

Black level modification vs. additional Haze removal

Neutral vs. Haze removal

I think the black level modification + haze removal is a clear winner here, but the "poor man"'s version is already helping out.

And another test on a different image:

Here the haze was stronger to begin with (and much more uniform). The simple subtraction works great.

@heckflosse I have thought about your idea for a checkbox in Raw Black Points. I actually think that's not the right place. The black points are strictly something to correct for camera behavior, not scene effects. If you start mixing them up, people might think it's a good idea to play with those sliders in general, which it isn't...

[Thanatomanic]

I also tried to get an approximately similar image by simply using the 'Black' slider in the exposure module. Of course this doesn't touch the individual ratio's of the channels, so it can't be identical. But you can actually get pretty close.

Does make you wonder about the usefulness of the new method though... Also, since you tweak the RGB ratio's quite early on in the pipline (I assume, haven't checked) don't you loose the colorimetric ratio's early on? A certain French developer of darktable would probably flout you for that 😉

[heckflosse]

@Thanatomanic Thanks for testing :+1:

I have thought about your idea for a checkbox in Raw Black Points. I actually think that's not the right place. The black points are strictly something to correct for camera behavior, not scene effects. If you start mixing them up, people might think it's a good idea to play with those sliders in general, which it isn't...

Yes, that's one problem with the method. Technically it would be the right place for the current implementation. Though I think the final implementation has to be a bit more complex. For example we should not subtract this black levels from pixels >= whitelevel. Clipped is clipped and should stay clipped.

Does make you wonder about the usefulness of the new method though... Also, since you tweak the RGB ratio's quite early on in the pipline (I assume, haven't checked) don't you loose the colorimetric ratio's early on? A certain French developer of darktable would probably flout you for that

That can be a desired effect, because the haze is not always monochrome, it has a colour, which is then just subtracted ;-) Think about it: If the haze is uniform, which I assume for the kind of images we speak about, the haze adds the same R-value to each red pixel, the same G-Value to each green pixel and the same B-Value to each blue pixel (roughly at least). Subtracting these should indeed give a more correct ratio. Of course not referred to the scene (because the scene is affected by the haze), but referred to the scene if there would be no haze between the camera and the scene.

[heckflosse]

@Thanatomanic

Does make you wonder about the usefulness of the new method though...

There is another point which makes it useful, I already mentioned above: On hazy images, Capture Sharpening auto radius is more accurate when the haze is removed before Capture Sharpening,

[heckflosse]

@Thanatomanic

A certain French developer of darktable would probably flout you for that

Well, that would be no problem for me if the results are good ;-)

More than two months ago I showed him this two screenshots:

left without haze removal, right with, both without subtracting

Now the same, but right with subtracting and haze removal

and his reply was: That last result is very good. ;-)

[heckflosse]

here's the raw file from my last post D200_20070803_2129.zip

[teplit]

@Thanatomanic

I also tried to get an approximately similar image by simply using the 'Black' slider in the exposure module. Of course this doesn't touch the individual ratio's of the channels, so it can't be identical. But you can actually get pretty close.

I don't agree here - the Black slider from the Exposure module can strongly discolor the image and the attempts to fix this problem probably will cause additional color distortions.

I made a comparison between four global haze removal methods (after applying Neutral profile):

Raw Black Points

Tone curve - Standard

Exposure - Black

L*a*b* Adjustments - L* curve

Note that the Standard tone curve is linear, but I think that it affects non-linearly the image due to this:

The curve and histogram is always displayed with sRGB gamma, regardless of working or output profile.

[heckflosse]

@teplit Thanks for the comparison. I'm interested about your conclusion about the comparison of the four methods ;-)

[teplit]

In my opinion the first of the four images is the most suitable for further processing – it looks the cleanest. It may look a bit greenish, but that is easy to change with the White balance. The latter is probably affected from the Raw channels subtraction.

The second one have a bluish bias, which is most easy to see in the shadows. Here a warmer white balance can neutralize the bluish tint, but the image still looks somehow polluted.

The last two are substantially discolored and require intervention to fix that. There are several ways to boost the colors. RawPedia recommends Lab chromaticity:

Positive RGB Saturation values will lead to hue shifts (the larger the value, the more visible the shift), while positive Lab Chromaticity values will boost colors while keeping their hues correct, rendering a crisp and clean result.

So let try +70 Lab Chromaticity for the Exposure - Black method:

Here the colors are somehow distorted in my opinion - the shadows are a bit discolored and polluted, while the bright areas look quite saturated.

Let try +40 Lab Chromaticity for the L*a*b* Adjustments - L* curve method:

This image looks like a brighter and hazier version of Tone curve - Standard, but it requires more movements to achieve.

I forgot to mention another method - RGB curves. Like the previous three it is not automatic (R - 25, G - 25, B - 29):

The shadows still look somehow polluted - they lack contrast.

In my opinion it is best to minimize the movements in the Raw editor - this saves time and reduces the possibilities to overcook the image.

[heckflosse]

@teplit Thanks a lot for this comparison and your conclusion :+1: I also think, that raw bl subtraction is a good starting point for a kind of automated processing of this (haze, lens flare) cases.

Now the point is, where to put this method in ui...

[TechXavAL]

@heckflosse

In my opinion it should be placed within the Raw Black Points tool, as it is where it belongs: that's what you are modifying. As you said, you only have to add an Auto-calculated checkbox, and that's it. Even if this method does dehaze the image, that's a side effect and not the goal, I think. In fact, as I see it, it's closer to controlling the black point of the image (in a way similar to what Photoshop and Gimp do) than to remove haze.

The problem I see is that we won't have any semi-automatic way of controlling the strength of the tool. Or how to control the result to best fit our needs: it's either all or nothing. I know we can always tweak each slider ourselves, but most often than not, than won't ever happen.

So maybe a solution could be adding an extra slider? A Strength slider, which would act as a layer opacity and would give us some control over the tool? It would be just a multiplier of the auto-calculated values, and it would allow us to improve black levels without fully removing haze, if that's what we wish.

And by the way, as this method works well with the current dehaze tool, it would be a shame having to choose between one method or the other (if this one is placed alongside the dehaze tool, as a choice).

[68pandreas]

Hi, I use the Christmas days to look for image processing tools beyond gimp, which so far was the only I used from time to time but cannot handle RAW files. Motivation to do so is that I will be responsible for a lecture coming up in wintersemester 25/26. I came about darktable with its advantage being open and algorithms being explained. On the other hand it is even harder to get into it than gimp since it is seemingly more or less a must to understand the algorithms in order to use it appropriatly.

I wonder now, where this suggested feature went to. From a user perspective it is seemingly very simple to understand and apply. So a very pragmatic feature. Where can I find it now?

Best regards, Andreas

[Lawrence37]

It's in the poor_man_dehaze branch. You'll have to compile it yourself to use it.

[lngndvs]

For microscope images I have been using "Haze Removal" as the first step, almost everytime, when processing *Cr3 images using RawTherapee. It helps. This algorithm, with the first-listed RGB settings, works very nicely, potentially better than what I've accomplished so far. Then again, I am not highly skilled, and prone to self-deception.

The "poor-mans-dehaze" branch is three years old. Has anything been done more recently? Perhaps to integrate it with more recent code? Or has it been deemed to be superceded?

[Lawrence37]

There have been no updates as far as I know. The question that remains is how to add this feature in the UI. I second the idea of having an auto-calculate checkbox in the raw black points section.

[Desmis]

This is also my opinion. This is a priori a GUI problem, a bit complex, because you have to pass parameters depending on the type of sensor (Bayer or Xtrans)

[Desmis]

I'm working on a new branch "poordeha" to put a checkbox (this should be easy), but above all to ensure that the parameters are passed - this is the main thing for Bayer sensors.

Jacques

[teplit]

In the meantime here is a workaround via RawDigger, which I use frequently:

[Desmis]

I think that for Bayer sensor it works correctly for dehaze. There are probably improvements to be made.

Branch "poordeha"

Jacques

[Desmis]

Now, X-trans sensor seems to works correctly.

I create a Pull request, with executables "poordeha" (appimage and windows) https://github.com/Beep6581/RawTherapee/releases/tag/pre-dev-github-actions

Jacques