afre_dehaze is not ready for testing and won’t be for a long time. It is my way of having fun and improving my math and coding. I decided to make it official due to the encouragement of a few of our G’MIC friends.
Goal
– To provide an accessible yet simple dehaze filter.
– To apply what I have learned so far about G’MIC, math and programming.
Features
– Faithfully follows He's papers (with a few additions).
– Each step is a separate command to permit analysis and other usage.
– Parameters are few, and simple to use and understand.
– Available for CLI and GUI.
– CLI and GUI contains documentation in basic English (To Do).
Lessons
– Research into grey scale opening (morphology): it is good at preserving shape but not suitable estimating atmospheric light or removing haze.
– Learned how to implement something and make it robust (at least, no division by 0).
Thanks a lot indeed for your contribution on G’MIC!
In the long past, I have tested a “similar” G’MIC filter (DCP dehaze > by J. Boulanger). Unfortunately, I have never learned how to use it properly.
In short, I found its commands quite difficult to grasp since this filter lacked a proper documentation. For beginners I mean, since, probably, there was, somewhere, a technical paper for specialists.
I hope your filter will be much better commented as regards its “few parameters”
DCP Dehaze doesn’t look bad though it doesn’t need the brightness/contrast control, I can do that with other filters. Comparison would be nice once done.
I haven’t made any comparisons to DCP Dehaze or the implementations of dt or RT. I started asking about RT’s only because I was uncertain of how to interpret some of the language in the papers that I read. A couple of my questions spilled over into the exercises thread. I.e., parts of the method weren’t described explicitly, so I had to figure out what the authors meant. Edit: I think those parts of my implementation is close to what they had done.
Actually the algorithm of DCP Dehaze (and perhaps dt and RT) is based on newer research but I wanted to focus on the original dark channel prior method that has inspired many papers since.
Once I gain enough understanding of haze removal, and mathematical and programming prowess, I may decide to pursue newer ideas, or as usual, do my own research (I like to go my own way ).
Not feeling like working on making it ready for release this week.
In the meantime, post images you would like to see afre_dehazed. It will be a fun way to pass time and test the filter. I prefer it to be your own images since we don’t want to get into licensing trouble.
In the background, to the very left of the “IPERCOOP” red billboard, there is a tiny skyscraper. Currently, it is hardly visible because of the haze.
With the DCP dehaze filter applied this skyscraper stands out better in my image. I have simply changed the “strength” parameter of this filter.
P.S: do not worry about next release of G’MIC. Usually, over time, there are so many following G’MIC releases that you are never late for the party
Thanks a lot for your efforts on this image
Looking forward to test your G’MIC dehaze filter as soon as it is available.
EDIT: just for fine I have tested a web application which allows to dehaze your images (https://www341.lunapic.com/editor/?action=dehaze).
To make it short, I have uplodaed my image and I have clicked on the Menu > Adjust > DeHaze.
The result is quite similar to your G’MIC filter. In essence, my image is much darker.
Patch radius
– This is the main parameter of the filter.
– Small radii prevent halos but may end up over-saturated and overdone .
– Large radii cause halos but may have realistic colour , though diminish dehazing .
– Default radii is calculated. User may double or halve that amount. (To Do: make smart GUI.)
Depth recovery
– Most images require this to look realistic.
– A complete dehaze removes the sense of depth, which is important for landscape photos.
– Default value is 5%.
Brightness (Optional, To Do)
– To prevent the notable darkening, I will provide a elegant way to lift the dark and mid-tones.
Colour shift (Optional, To Do)
– Not necessary in most cases. It is a “break glass in case of an emergency”.
– This gives the user a chance to reduce colour shifting if the filter overdoes it; or the opposite.
PS Variables
– The filter and its sub-commands also have variables that I have set as constants.
– For the devs and the inquisitive. Maybe some images require other values to be set.
1 Revisiting the morphology and transmission parts. Unsatisfied with the algorithm. My current method of overcoming its weaknesses is insufficient to me. It is okay, as you can see from my sample runs above and in my PlayRaws, but there is room for improvement.
2 Unsure about adding the Brightness and Colour shift parameters, as they would add heft and maintenance to the filter. → Should I leave the post processing to the user? Or include them but make them optional? Thoughts?
The more I ponder abour your question, the more I am uncertain about the best way to go. Both options have pros (keep the filter simple) and cons (getting your final image darker)…
In essence, as long as your filter is well documented by well explaining each of its settings it should be enough whatever option you choose, IMHO.
From my personal experience, I find the G’MIC filters lacking in two ways:
lack of proper documentation (e.g. no “F1” shorcut help-button to reach the documentation for every filter: HTML manual, YouTube videos and so on);
slow with big images (due to the lack of the GPU leveraging, maybe?). My Pc has an I7 Intel Cpu and 8 gb of Ram btw.
Therefore, if your filter has a good, not too technical, documentation (with maybe even an image as sample to test it) and it is not terribly slow with big images it should be fine as far as I am concerned
EDIT: as far as the documentation is concerned the worst part regards the G’MIC filters in the Testing group. By and large, right now, there is no way to understand what they are supposed to achieve. This defeats their purpose, which is testing them thoroughly , I suppose
There is the approach of adding info into filter, but it’s a little too much when other languages are considered. Not to mention that it takes some work when creating filter for g’mic can be a lot of work, and especially when new features or bugs are discovered. I totally get why filter developer don’t add info to every of their filters.
Yep. Unfortunately, the lack of written documentation is a a problem for most of the open source softwares I work with. This is for a reason, since it takes a LOT of time to write and test it. Time is money
Just out of curiosity, is it possible do “dehaze” this picture?
Take a look at the sky, that is the very uppermost part of the image. There is a “haze” due to the lamps illumination.
I am wondering whether your upcoming filter takes into account this kind of “problem”…
I have googled a bit and I am wondering whether you have used a plugin for Photoshop (“Kolor Dehazer plugin”).
Since it is a jpeg image, quite compressed in order to post it in this blog, I suppose you didn’t work with RawTherapee or Gimp (as far as this plugin in concerned).
@Silvio_Grosso I use now this 8bf plugin with xnview. It’s not ideal.
If you or @afre want the plugin, I can upload it in a zip. The GUI is very simple as the parameters permit to modulate the depth mask.
I hope @afre will get a better result than this plugin.
@gaaned92 I don’t actually see a difference once I do post-lightening, which I listed as a To Do.
So, in a sense, you are sharing your opinion on:
…
Sure, why not? As aforementioned, I am still making this filter in isolation and prefer it that way. Seeing how much I can push myself. (I have still some math to understand though, so it may be time to ask the coding and math adept members again.) But it would be great to see how the plugin does its GUI. IrfanView should be able to use 8bf.
).
but may end up over-saturated 
and overdone 
