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:
>>>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).
>>> 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
>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
See also below.
>>>AFAIK, the #1 is our current approach and the channel-wise
>>>binarization is controlled by combination of views.
>>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
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
To summary, Miral, your current implementation accepting views of
compatible/equal color spaces is fine. It just may need some extra compile-time
-- Mateusz Loskot, http://mateusz.loskot.net Fingerprint=C081 EA1B 4AFB 7C19 38BA 9C88 928D 7C2A BB2A C1F2
Boost list run by Boost-Gil-Owners