Re: [GSOC] Deciding upon the version of Adaptive Histogram Equalization to implement

From: Debabrata Mandal (mandaldebabrata123_at_[hidden])
Date: 2020-08-16 08:01:11

I went forward with the Non-overlapping block histogram equalization, among
the other techniques discussed.
But I have faced a blocker. I am not sure exactly if it is a bug in my code
or simply the flaw with the technique.
As expected I had faced the blocking effect since I divided the image into
tiles to perform local histogram equalization. To mitigate this effect I
have applied Bilinear interpolation (as mentioned in [1]) on the tiles, but
can't see any noticeable difference. I verified that bilinear interpolation
was working properly on small images.
I have attached a few images based on my outputs.
Right now, I am thinking of shifting to another version called sliding
window histogram equalization which tends to be slower than the one I have
implemented right now. But I have implemented that in the past (in Matlab)
and it gave correct results.
I will look into the current algorithm for another day and try to debug it,
and if it does not work I am thinking of making the shift, keeping in mind
the time constraints.

[1] Pg 475, Graphic Gems 4,
http://cas.xav.free.fr/Graphics%20Gems%204%20-%20Paul%20S.%20Heckbert.pdf

Thanks.
Debabrata Mandal

On Wed, Aug 12, 2020 at 2:31 PM Mateusz Loskot <mateusz_at_[hidden]> wrote:

> On Wed, 12 Aug 2020 at 08:17, Debabrata Mandal
> <mandaldebabrata123_at_[hidden]> wrote:
> >
> > > Can you give references to any particular papers?
> > > The names listed below, I think, may be ambiguous to some.
> > >
> >
> > The thing is I did not reference any particular paper when I mentioned
> > these techniques. One reason was that I could not find the original
> sources
> > for the 3 techniques mentioned. But there are dozens of papers discussing
> > improvements to these 3 barebones algorithms.
>
> Yes, it often is difficult to point at a particular paper
> as some techniques are tweaked numerously and
> the tweaks are published in separate papers.
>
> I still think we need to document some references to give
> docs/sources reader rough bearings at least.
>
> > For example,
> > In this book,
> >
> http://cas.xav.free.fr/Graphics%20Gems%204%20-%20Paul%20S.%20Heckbert.pdf
> > Pg - 474 (By, Karel Zuiderveld, 1994) the CLAHE algorithm (a type of
> block
> > overlapping HE) is mentioned.
>
> Excellent.
> Please, stick the title/year/author in source comment or docs.
>
> > > > 1. Block overlapping HE
> > >
> > > Block Overlapped Intensity-Pair Distribution Approach for Image
> > > Contrast Enhancement, 2007
> > > by Md. Hasanul Kabir, M. Abdullah-Al-Wadud, Mohammad A.U. Khan, Abdur
> > > Rashid and Saghir Ahmad
> > >
> >
> > This paper also talks about an additional 'Intensity-Pair distribution
> > method' which I am not currently familiar with.
>
> Right. It already is helpful to know that the block overlapped HE in GIL
> is not exactly that one.
>
> > > 3. Non-overlapping HE
> > >
> > > Block based Intensity-Pair Distribution for Image Contrast Enhancement,
> > > 2006
> > > by Md. Hasanul Kabir, M. Abdullah-Al-Wadud, Mohammad A.U. Khan, Abdur
> > > Rashid and Saghir Ahmad
> > >
> >
> > I was unable to find the link to the full paper for this. From the
> abstract
> > it seems an re-application of the 'Intensity-Pair distribution method' to
> > non-overlapping blocks which they had published in a previous paper (the
> > first paper that you mentioned).
>
> Yes, that is my understanding too.
> I don't have a copy of the full paper either.
>
> > > Another example of possibilities for the 1. and 3., that is
> > > - non-overlapped sub-blocks HE
> > > - overlapped sub-blocks HE (as an improvement of the former, to remove
> > > the blocking effect)
> > > is explained in this paper, referred w/ citations [13] and [14]:
> > >
> > > Image Contrast Enhancement based Sub-histogram Equalization Technique
> > > without Over-equalization Noise, 2009
> > > by Hyunsup Yoon, Youngjoon Han, and Hernsoo Hahn
> > >
> > >
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1047.6395&rep=rep1&type=pdf
> > >
> >
> > These are the newer publications on the topic. I have not read them yet.
>
> Okay. It is helpful again to filter out things we don't refer to.
>
> > > > The main difference between the three are the technique in which they
> > > > improve the computation time while keeping undesired effects out.
> > > > For example, Block overlapping HE performs equalization on a window
> > > around
> > > > each and every pixel in the image thus suffering from huge
> computational
> > > > costs. Non overlapping HE on the other hand does a bilinear
> interpolation
> > > > to find the transformation function for equalization but suffering
> from
> > > > something called blocking effect.
> > >
> > > All the three above are techniques for local contrast enhancement.
> > > Are we also having implementation of classic/canonial global contrast
> > > enhancement?
> > >
> >
> > Yes, I have already implemented the Global HE which was part of the
> > proposal. Is that what you had meant by classic/canonial global contrast
> > enhancement?
>
> Yes, it is.
>
> Global HE is a fundamental technique, so I called it canonical.
> Local HE can be viewed as refinement for optimal output, optimal run-time,
> etc.
>
> > > > My goal, as I had mentioned in the proposal was to implement Block
> > > > overlapping HE (specifically CLAHE - which makes some additions to
> it).
> > > > But I am not sure which to choose.
> > >
> > > For archives, I'll quote Pranam from #boost-gil channel,
> > > https://cpplang.slack.com/archives/CSVT0STV2/p1597051626006600
> > > "if you already have implemented one technique then you should proceed
> > > with it to speed up things"
> >
> > Sure, thanks for the advice. We can make improvements based on the
> results
> > we obtain on the initial implementations, since it is difficult both to
> > decide beforehand which is the best one and at the same time implementing
> > all possible approaches.
>
> Yes.
>
> We can also consider all 3-4 algorithms expecting them to be
> implemented in future,
> so for functions/algorithm(s) we've got now, we can pick more specific
> names
> or we can consider common interface with some arguments (e.g. enumerations)
> to specify HE technique (e.g. something similar to what we've got for
> thresholding
> implemented by Miral Shah last year).
>
> For example, to make my suggestion of future-proofing perhaps clearer,
> a function to run one of the local HE that you have implemented,
> don't name it `equalize_local` or `ehannce_local`, but name after
> algorithm,
> unless it is going to be a common interface to all local-based HE
> algorithms
> with specific strategies controlled via input arguments.
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> --
> Boost-gil mailing list
> Boost-gil_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-gil
>