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

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2020-05-12 17:47:56

On Tue, 12 May 2020 at 15:05, Mateusz Loskot <mateusz_at_[hidden]> wrote:
>
> I'd consider:
> - introduce Boost.Histogram as a temporary requirement.
> - use it as a container to output/transfer histograms from/in GIL.
>
> Based on such experience, I think, it will be easier to observe GIL specific
> requirements for histogram container(s) and how to shape a more generic
> interface of functions operating on histogram. We may decide a standard
> container of numbers or tuples is enough or we need a basic histogram
> class, etc.

One more note related to OpenCV which outputs histogram into
N-dimensional structure (Mat, SparseMat, OutputArray).

It is useful to calculate multi-dimensional histograms (e.g. hue-saturation).
I imagine GIL should also allow that too, but OpenCV interface could be better.
Is multi-dimensional histogram the most common, primary use case?
Is histogram of grey levels the most common use case?

If I want a histogram of grey levels, I should not be forced to deal with
any multi-dimensional structure, any matrix.
I should be able to get a histogram in as simple form as
std::array<int, 256> or std::vector<int> or similar,
that is objects with minimal necessary interfaces
and optimal memory management
without unrelated 2-dimensional bloat.

p.s. Debabrata, I'm posting this also to let you test the mailing list,
hopefully you will be able to respond to this.

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