Boost logo

Boost :

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2020-08-12 09:01:53

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,
> Pg - 474 (By, Karel Zuiderveld, 1994) the CLAHE algorithm (a type of block
> overlapping HE) is mentioned.

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
> >
> >
> >
> 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,
> >
> > "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.


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
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,

Boost list run by Boost-Gil-Owners