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

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

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.

Actually, I have just opened issue about it:
"color_spaces_are_compatible requirement in threshold too strict"
https://github.com/boostorg/gil/issues/323

>> 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.

Yes, but this should be allowed to happen only if the source and destination
views are fullfill the requirement of the `ColorSpacesCompatibleConcept`,
I think.

>> ## 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.

AFAIU, that is not quite correct as per the discussion in
https://github.com/boostorg/gil/issues/323

>> 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.

Great, more tests is gold!

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