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

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2020-05-13 14:47:59

On Wed, 13 May 2020 at 14:55, Pranam Lashkari <plashkari628_at_[hidden]> wrote:
> On Wed, May 13, 2020 at 6:13 PM Mateusz Loskot <mateusz_at_[hidden]> wrote:
> >
> > By asking some questions I did not suggest they should be answered now.
> > I just hoped to direct the thinking/discussion towards quite obvious
> > conclusion:
> > - do not focus on unnecessary stuff (e.g. controlling details of of
> > histogram)
> > - focus on what we know to start prototyping/implementing early
> > - start from easy to complex
> >
> > Obviously, solving a problem for a single channel is easier than
> > solving it for multiple channels and dimensions.
> >
>
> On the other hand, I forgot to mention things related to boost.histogram.
> In my opinion, we should use it only if we are going to use it
> permanently(not a lifetime but a long time, you know what I mean). It may
> make our work a little simple for now, but if we are gonna remove it
> eventually and we know it at the point then why to use it now? it just
> increases the workload for the future.

I don't see how making such shortcut for the time being may increase workload.

It is not different to solving calculation problem for a function
foo(std::vector<T>)
knowing that in future it will have to be extended for
foo(std::set<T>)
foo(T*)
etc.

An output container does not really affect an algorithm, does it?

Besides, I expect permanent integration with Boost.Histogram.
It just will become optional, that is, if a user wants to enable it,
she includes specific header, e.g.
#include <boost/gil/extension/boost_histogram.hpp>

However, I don't want to impose any approach, but if I see we are
brainstorming all possibilities of parameters:

imgHist(srcview,hist);
imgHist(srcview,hist,channels,range,colormap,sparsefill,accumulate);

that convinces me there is more stuff that we don't know
than stuff we do know, at the moment :-)

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