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

From: Debabrata Mandal (mandaldebabrata123_at_[hidden])
Date: 2020-06-05 07:22:04

>  Debabrata would you like to throw some light on this!
>

*Note *- This is a rather long email. I am trying to highlight most of the
discussion that took place scattered in the slack group, github comments
etc.

*Answer to the post above* : I had mentioned unordered_map due to the
reason it employs hashing which is similar to the way Boost.Histogram maps
keys to unique bins in a storage class. This will become particularly
useful for signed images of any channel type. At the same time an
unordered_map does not guarantee key value mapping to be present for every
pixel value in a given range. So a sequence container like array or vector
would be better in this case.
The histogram class has a clear distinction from the kernel class, in the
sense that the kernel needs a contiguous storage while the histogram does
not.

This was the conundrum that we were stuck in earlier which is why I guess
the option to choose the container type was given.

Further external classes like Boost.Histogram might still need template
specialisation to distinguish between the implementations.
FYI, Boost.Histogram solves a similar problem by letting the user provide a
custom storage class that models the histogram concept that it follows.

Further, I believe it is not practical to provide the entire interface
shipped by an already sophisticated histogram class like Boost.Histogram.
The reason I mention this is because while Boost.Histogram might provide a
special function which is available only if we use Boost.Histogram as our
background storage, providing a similar function for std container like
vector may prove inefficient which then leads to the problem of
inconsistency. We need to make the end user accountable for the interface
they desire which can be done only if we give control over the container.

What's left is what can be done for the std containers. We have *two*
approaches in hand :-
1. Overload design - One of the drawbacks in picture is the usage syntax
which might be difficult to use, but we cannot avoid that in the case of
class approach either if we want future integration with external classes.
Another drawback would be the difficulty in tracking which functions get
called for a particular container type. This is a problem because when we
add histogram utilities like mean, normalization etc. , they might need
different implementations for different classes which is why it would be
difficult to identify the right function unless they are properly commented
and documented.

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?

A third approach would be to provide a mix of classes for std containers
and overload for external classes which will deal with the problems of both
the above two points.
So a clear way to me (which I had mentioned in the proposal as well) is to
provide the conversion routine for now, independent of the container class
type, but ofc this is my solo opinion and might not be the best. I wish to
know what the opinions of the community are?
Further details on the overload design are provided in the github comment
<https://github.com/boostorg/gil/pull/499#issuecomment-637746390> .
 I hope I could clearly express my views on the topic.
Thanks Debabrata.
GSoC 2020 student.