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

From: Debabrata Mandal (mandaldebabrata123_at_[hidden])
Date: 2020-05-17 13:11:12

Hi,
We did not have any discussion on this,

I mean to add the following files to the library:

1. include/boost/gil/extension/histogram/histogram.hpp - Add the image to
histogram container here. Current plan is to start with support for 1d
standard containers as histogram for grayscale images.

2.  include/boost/gil/extension/histogram/utilities.hpp - Add histogram
utilities functions like backprojection, normalization calculation etc.

3. include/boost/gil/image_processing - Add image to image transformation
algorithms based on histogram computation like AHE, HM etc.

This is for the code that I hope to add by the end of the first month. Are
changes needed?
Thanks.
Debabrata Mandal

On Thu, May 14, 2020 at 12:32 AM Mateusz Loskot <mateusz_at_[hidden]> wrote:

> On Wed, 13 May 2020, 20:07 Debabrata Mandal, <mandaldebabrata123_at_[hidden]
> >
> wrote:
>
> > 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?
> >
>
> Whenever you wish to request comments, you can post a new thread here or
> ask on Slack (if questions are not too elaborate) or open a GitHub PR, if
> you want to show any code for review.
> I mean, just as suggested in the initial welcome 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?
> >
>
> Works for me.
>
> > 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.
>
>
>
> Sure, I don't object adjustments to the initial plan.
>
> 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.
> >
>
> I think it isn't necessary.
>
> We have the list of proposed features
> You likely have items that you're certain about, that you want to do for
> sure, for those items you can open feature issues on GitHub (as suggested
> in welcome email).
> Such issues can make up a nice TODO list, then items are ticked via PRs.
> For others, we decide and pick as we go, and we can add them to the TODOs.
>
>
> Mateusz Loskot, mateusz_at_[hidden]
> (Sent from mobile, may suffer from top-posting)
>
> >
> --
> Boost-gil mailing list
> Boost-gil_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-gil
>