Re: [gsoc2020] Answer to histogram design questions from Slack

From: Debabrata Mandal (mandaldebabrata123_at_[hidden])
Date: 2020-05-13 18:07:02

On Wed, May 13, 2020 at 11:09 PM Mateusz Loskot <mateusz_at_[hidden]> wrote:

> On Wed, 13 May 2020 at 18:12, Debabrata Mandal
> <mandaldebabrata123_at_[hidden]> wrote:
> >
> Yes, as what Pranam suggested and I agreed to as well,
> a single channel does sound reasonable to start with and focus on.

Great, so should I start thinking of possible user invocation syntax for
the histogram calculation and related algorithms and share them in an
upcoming email?

> Yes, as image and operation complexity increases, we may need to narrow
> histogram container choices.
>
>
So for now can we assume support only for STL containers (not nested) and
Boost.Histogram?

> I did not suggest anything other than what has been proposed:
> - generic 1D, 2D, 3D histogram functions
> - 1D, 2D cumulative histogram function
> In fact, I assumed we may only be able to provide calculations of
> 2-3 D histograms during this project, nothing else.
>
>
The original project page in Github had suggested some algorithms like
adaptive histogram equalisation, so I had decided to add some more powerful
and better algorithms to my project proposal to cover the span of 3 months.
I had not anticipated the immense number of choices that one had to choose
from while selecting what is best for everyone. I had approximated it as
making some simple type checks and providing specialisations, which does
seem absurd now. So, I think I will need to review my work plan and reorder
things a bit. Should I post the list here that I had proposed initially so
that we can vote on what to keep and what to eliminate for now. It does
cover everything in the project page, just a few extra additions were made
to it.
Thanks, Debabrata.