Re: [gsoc2019][threshold] Global binarization vs multi-channel binarization

From: Miral Shah (miralshah2211_at_[hidden])
Date: 2019-07-05 15:42:52

On Fri, Jun 28, 2019 at 11:09 PM Mateusz Loskot <mateusz_at_[hidden]> wrote:

> Hi Miral,
>
> ## Global binarization
>
> Let's consider this a canonical (common) case of thresholding.
> This thresholding is a binarization of image that outputs
> a binary (black & white) image.
>
> Technically, it does not have to be represented as a 1-bit channel image,
> but 8-bit grayscale with pixels having only two values:
> - Zero
> - Maximum
>
> I think, the general binarization should be a default behaviour.
> Regardless of type of `src_view`, it should enforce `dst_view`
> is as grayscale view (or binary view, 1-bit values).
>
> For example:
>
>   threshold_binary(gray8_src_view, gray8_dst_view, 128, 255);
>   threshold_binary(rgb8_src_view, gray8_dst_view, 128, 255);
>   threshold_binary(cmyk8_src_view, gray8_dst_view, 128, 255);
>

The reason behind this type of automatic conversion is not allowed because
this conversion of src_view to dst_view can take place before and after
performing threshold operation. Both approaches produce different results.
Sticking and going with one of these approaches will lead us to make too
many decisions for the users. Finally, threshold functions allow src_view
and dst_view to be of the same type only using
"ColorSpacesCompatibleConcept"

> The behaviour should be default for all `threshold_*` functions, I think.
>
> ## Multi-channel binarization
>
> This is a sophisticated case of thresholding,
> after https://homepages.inf.ed.ac.uk/rbf/HIPR2/threshld.htm
>
> > For color or multi-spectral images, it may be possible to set different
> > thresholds for each color channel, and so select just those pixels within
> > a specified cuboid in RGB space.
>
> In this case, thresholding should enforce that both, `src_view` and
> `dst_view` need to be N-channel images. In fact, we could simplify and
> enforce that `dst_view` is of exactly the same type as `src_view`.
>
> For example:
>
>   threshold_binary(gray8_src_view, gray8_dst_view, 128, 255);
>   threshold_binary(rgb8_src_view, rgb8_dst_view, 128, 255);
>   threshold_binary(cmyk8_src_view, cmyk_dst_view, 128, 255);
>

Multi-channel binarization is performed by performing threshold operation
on each channel and returning a view with each channel independently
thresholded.

> ## Conclusion
>
> I prefer the solution #1 as simpler with less parameters to control.
>
> AFAIK, the #1 is our current approach and the channel-wise
> binarization is controlled by combination of views.
> Correct?
>

Yes, our current approach is almost similar to what you stated but
threshold_* does not depend on dst_view type but src_view and dst_view must
be of the same type.

>
> Related design and behaviours should be clearly stated and documented.
> Tests of the implementation should do better, I think.
>
> By the way, this is issue shows that tests should cover more cases :-)
> Otherwise, it is too easy to overlook what behaviours are by design
> and what are accidental, and what are missing.
>

I have created new PR adding new tests.

> The current implementation (incl. Otsu) needs to be reviewed against
> this overall issue.
> I'd start with adding test cases as explained above and see where
> the implementation blows up :-)
>
>
I'll update my  current PR adding new tests otherwise otsu uses the almost
the same approach as other thresholds methods.

-- 
Thank you,
Miral Shah