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

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2020-06-09 14:54:00

On Sun, 7 Jun 2020 at 07:55, Pranam Lashkari <plashkari628_at_[hidden]> wrote:
> On Fri, Jun 5, 2020 at 12:52 Debabrata Mandal <mandaldebabrata123_at_[hidden]> wrote:
>
> > 2. Class approach - To decide on a particular class type, means deciding
> > against future extensions to the container type, which is not a plus point
> > if someone comes up with an implementation of efficient Histogram class for
> > Boost.GIL. To further support this argument I can provide the
> > implementation design of OpenCV which separates the *conversion routine* of
> > image to histogram from the *implementation *of the actual histogram class.
> > Although they do not provide overloads for their container type, they have
> > their own histogram class to rely on. Since GIL lacks this feature,
> > wouldn't it be better to allow work on this in the future?
>
> I am in favour of this as I have mentioned earlier. We always have to
> compromise something there can not be a perfect design always.

For now, I think, we should decide on a simple histogram container
and move to the algorithms part.

Generally, there are possibilities w.r.t. the interface:
1. generic, container-agnostic
2. container-specifc

Can a function calculating histogram offer a container-agnostic interface?
What such an interface could look like?
Obviously, a container-agnostic is desired from a user point of view,
but it may not be easy to achieve.

Simpler is to stick to a specific container, especially since a container
selection is not a primary task here.
Here, we can have a simple one as our own type, like for the kernels.
If we have `boost::gil::histogram` class, we can pick and switch as we go.
I wouldn't waste too much time on debating which one is best,
undordered_map or vector, etc.
Unless selection is obvious, I usually start with the vector.

I honestly think we will be back to refining the interfaces for other
containers,
or for container-agnostic mode, but that will happen in future,
after the primary goals of the project have been achieved.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net