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

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2020-06-09 16:02:26

On Tue, 9 Jun 2020 at 17:38, Debabrata Mandal
<mandaldebabrata123_at_[hidden]> wrote:
>
> > > And, what should we do about its multi-dimensional counterparts?
> >
> > For the N dimensional variant of boost::gil::histogram, why not the
> > simplest
> > option: multiple underlying arrays based on std::vector?
>
> I think a 2 dimensional histogram on a 16 bit image would have too much
> space overhead, but we know the image size would always be an upper cap on
> the bins necessary hence I had proposed using hashing.

Yes, that is not an optimal choice, but as I tried to explain, type of container
will be implementation detail of boost::gil::histogram,
so it may be changed as you prefer.

> Although, I am ready to start with using a vector if that is the best under
> present circumstances. Please let me know of your thoughts on this.

I'm not recommending or requesting the use of vector.
I was trying to explain that container type may or will change in future,
so I'd pick one that is convenient for you.

TBH, for large images of high depths, users may want to optimise
using custom storage, they simply may prefer Boost.Histogram.
I don't expect GIL to offer highly efficient and specialised histogram
container, rather allow use of Boost.Histogram for special use cases.

IOW, boost::gil::histogram should be a reasonable default,
but not highly thought through and engineered as Boost.Histogram is.

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