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

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2019-07-07 20:09:05

On 19-07-05 22:33:26, Mateusz Loskot wrote:
>On 19-07-05 21:12:52, Miral Shah wrote:
>>On Fri, Jun 28, 2019 at 11:09 PM Mateusz Loskot <mateusz_at_[hidden]> wrote:
>>>
>>>## 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"
>
>If the destination is gray8, then the color space 'narrowing' should be
>possible automatically as per the way the `static_transform`-s work.

I have been reflecting on that and I came to conclusiont that letting to leak
out the behaviour of static_transform to behaviour/interface of threshold
functions is not a good idea. I posted detailed explanation here
https://github.com/boostorg/gil/issues/323#issuecomment-508944967
See also below.

>>>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.
>
>AFAIU, that is not quite correct as per the discussion in
>https://github.com/boostorg/gil/issues/323

So, considering static_transform behaviour as internal implemenation detail and
the fact it can transfrom wider color space to narrow color space (picking first
N channels only) should not leak out into behaviour of threshold functions,
I give my judgement above back.
See my last comment on that
https://github.com/boostorg/gil/issues/323#issuecomment-509025917

To summary, Miral, your current  implementation  accepting views of
compatible/equal color spaces is fine. It just may need some extra compile-time
assertions.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Fingerprint=C081 EA1B 4AFB 7C19 38BA  9C88 928D 7C2A BB2A C1F2