|
Boost : |
Subject: Re: Hysteresis step in Canny edge detection
From: Olzhas Zhumabek (anonymous.from.applecity_at_[hidden])
Date: 2019-03-17 17:50:12
Woops, the 0.5s in my version should've been 0.
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
вÑ, 17 маÑ. 2019 г. в 11:20, Olzhas Zhumabek <
anonymous.from.applecity_at_[hidden]>:
> Thanks for heads-up.
>
> I had a look at it, and it seems like it has the same problem as I had in
> the beginning: applying hysteresis as I go, not at once in the end. From
> what I understand, hysteresis makes transition from weak edge to strong
> edge only when strong edge is in immediate vicinity, e.g. one of the
> closest 8 pixels. The way it is written in the code linked it seems like it
> will produce different outputs on these inputs (assuming they are somewhere
> in the middle of image and immediate vicinity is filled with zeroes):
>
> 1, 0.5, 0.5, -> 1, 1, 1
> 0.5, 0.5, 0.5 1, 1, 1
>
> should be in my opinion
> 1, 1, 0.5,
> 1, 1, 0.5
>
> -----------------------
>
> 0.5, 0.5, 0.5, -> 0, 0, 0
> 0.5, 0.5, 1 0, 0, 0
>
> should be in my opinion
> 0.5, 1, 1,
> 0.5, 1, 1
>
> E.g. relative position of weak edges to strong edges matters in code of
> the linked pull request. I wanted to verify if I'm right before contacting
> the author, because I've seen various interpretations on the internet.
>
> I uploaded my solution to github:
> https://github.com/simmplecoder/edge-detection . I separated IO code from
> the rest, as it seems to cause massive compilation time increase. The toy
> program asks for input file, output file, upper and lower threshold in
> double thresholding. It saves all of the intermediate steps in .png files
> as well (can be suppressed by defining LEAN_AND_MEAN at the top of main.cpp
> file). The code has comments and more or less meaningful names, but might
> be a little bit verbose. I'm paranoid on Argument Dependent Lookup, so I
> always prefix with namespace if I actually don't want ADL. CMake script
> assumes presence of GIL and Boost.Math for value of Pi in the include path
> (last time I tried it seems like CMake doesn't know about existence of GIL).
>
> Here is the output with thresholds 0.7 and 0.1: https://imgur.com/QcGxwzg
> . Original image:
> http://justin-liang.com/tutorials/canny/images/1_original.jpg . It looks
> like due to difference in non-maximum suppression algorithm, mine picks up
> quite a bit of false edges along the way.
>
> What steps next should I take in my application process to Boost.GIL GSoC?
>
> Sincerely,
> Olzhas
>
> > FYI, someone has just proposed the Canny edge detector,
> > have a look at the proposed implementation at
> > https://github.com/boostorg/gil/pull/258
> >
> > Best regards,
> > --
> > Mateusz Loskot, http://mateusz.loskot.net
>
Boost list run by Boost-Gil-Owners