[ITK-users] Patch for ApproximateSignedDistanceMapImageFilter

Fri Mar 31 08:07:13 EDT 2017

Hi,

2nd attempt using approach 1)  (see below). What about typos in comments 
I removed during bug fixing? Include into this patch as well or keep 
them separate?

Additionally you find a small application creating an image with a 
bright square on dark background which displays the image together with 
the result of ApproximateSignedDistanceMapImageFilter. The pixel value 
of the square is 1 by default but can be changed via command line.

Regards,
Christina

On 29.03.2017 15:12, Francois Budin wrote:
> Hello Christina,
>
> I see different paths to try to solve this issue and I am not sure 
> which one is the best one:
> 1) You could modify the itkIsoContourDistanceImageFilter class so that 
> m_LevelSetValue is of some real type. When looking in the 
> implementation of this filter,  you can see that sometimes, 
> m_LevelSetValue is casted to a real type [1], so maybe it makes sense 
> to do that.
> 2) Casting is one solution, but you have to be careful if you want to 
> cast to float or double. If you cast to float, and the input is of 
> type double, you will loose precision. If you always cast to double, 
> you might use a lot of memory. Sadly, in the itkNumericTraits, there 
> is no way of asking for "the smallest floating type that contains my 
> current type". You can call "RealType" which will be "double", or 
> "FloatType" which will be float. One strength of casting, is that if 
> you perform it in place, it can actually not do anything if it doesn't 
> need to [2].
> 3) To avoid casting when you don't need to (your type is float or 
> double), you could use the SFINAE concept like it is used here [3]. 
> This is more complex and may not be worth it.
>
> Beware that images may contain pixels that are not only scalar values, 
> but also RGB, RGBA, vectors. I am not sure if the ApproximateDistance 
> filter supports these types, but it is good to be careful, when 
> modifying the code, to not restrict the usage of a filter to scalar if 
> not required. To avoid that kind of issues, and to answer your 
> original question, you can use the Rebind structure [4].
>
> I hope this helps.
> I will be out of town for a week, and most likely will have limited to 
> no access to the internet, so don't be surprised if I do not answer 
> your next message within the next week.
>
> Thanks for helping!
> Francois
>
> [1] 
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DistanceMap/include/itkIsoContourDistanceImageFilter.hxx#L314
> [2] 
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/ImageFilterBase/include/itkCastImageFilter.hxx#L42
> [3] 
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/ImageBase/include/itkConvertPixelBuffer.h#L153-L161
> [4] 
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/Smoothing/include/itkSmoothingRecursiveGaussianImageFilter.h#L84-L85
>
> On Wed, Mar 29, 2017 at 7:10 AM, Chr. Rossmanith 
> <cr at neuro.ma.uni-heidelberg.de <mailto:cr at neuro.ma.uni-heidelberg.de>> 
> wrote:
>
>     Hi Francois,
>
>     I'm getting back to this issue. I'll introduce an intermediate
>     image in the mini pipeline used in
>     ApproximateSignedDistanceMapImageFilter which has a floating type
>     for pixel values. Given
>
>       /** Type for input image. */
>       typedef TInputImage InputImageType;
>
>     how can I define a corresponding image type FloatImageType
>     replacing the unknown pixel type by float? I can't write
>     itk::Image< float, xxx > because I don't know xxx.
>
>     Is there a way to query the pixel type to avoid applying the
>     CastImageFilter in case we already get floating valued pixels?
>
>     Christina
>
>
>
>     On 03.03.2017 14:58, Francois Budin wrote:
>>     Hi Christina,
>>
>>     Maybe your idea was good but needs more work (e.g. cast the input
>>     image to the output type? at least if input is not a float, or
>>     maybe something else). I am glad you found a solution that works
>>     for you. If you need your software to be faster, you can also
>>     replace the SignedDanielssonDistanceMap with the
>>     SignedMauerDistanceMap [1].
>>
>>     Hope this helps, and thanks for your contribution. Do not
>>     hesitate to submit a new patch to solve your original problem if
>>     you find a solution.
>>
>>     Francois
>>     [1]
>>     https://itk.org/Doxygen/html/classitk_1_1SignedMaurerDistanceMapImageFilter.html
>>     <https://itk.org/Doxygen/html/classitk_1_1SignedMaurerDistanceMapImageFilter.html>
>>
>>     On Fri, Mar 3, 2017 at 8:23 AM, Chr. Rossmanith
>>     <cr at neuro.ma.uni-heidelberg.de
>>     <mailto:cr at neuro.ma.uni-heidelberg.de>> wrote:
>>
>>         Hi Francois,
>>
>>         really strange, on Wednesday changing the data type made my
>>         application work as expected (but obviously there must have
>>         been an additional change which really made the application
>>         work...). When trying to build a small example for you, I
>>         failed. I still think that feeding a 0/1 image into
>>         ApproximateSignedDistanceMapImageFilter makes sense.
>>
>>         Originally I'm interested in ContourExtractor2D, which
>>         operates on a distance map using 0 as contour level. Unlike
>>         in the  ContourExtractor2D example I've decided to use
>>         SignedDanielssonDistanceMap which works fine without any patches.
>>
>>         So send the patch to /dev/null for the moment...
>>
>>         Christina
>>
>>
>>          On 02.03.2017 16:17, Francois Budin wrote:
>>>         Hello Christina,
>>>
>>>         I just reviewed you patch. You are changing the type of the
>>>         variable levelSetValue to OutputPixelType which is suppose
>>>         to be a floating point value.
>>>         However, the computation is done with InputPixelType
>>>         variables (m_InsideValue and m_OutsideValue) and divided by
>>>         an integer. Additionally, the resulting value is used in:
>>>         m_IsoContourFilter->SetLevelSetValue(levelSetValue);
>>>
>>>         which accepts values of InputPixelType [1] since
>>>         IsoContourType is defined as:
>>>           typedef IsoContourDistanceImageFilter< InputImageType,
>>>         OutputImageType > IsoContourType;
>>>
>>>         I am not sure if your patch solves the problem that you
>>>         mentioned. Do you have a test that would verify that the new
>>>         behavior corresponds to your expectations? Based on the code
>>>         review I have done, I would not expect the behavior of the
>>>         filter to change.
>>>
>>>         Let me know if I missed a detail. Thank you for your
>>>         contribution!
>>>         Francois
>>>
>>>         [1]
>>>         https://itk.org/Doxygen/html/classitk_1_1IsoContourDistanceImageFilter.html
>>>         <https://itk.org/Doxygen/html/classitk_1_1IsoContourDistanceImageFilter.html>
>>>
>>>         On Wed, Mar 1, 2017 at 8:12 AM, Chr. Rossmanith
>>>         <cr at neuro.ma.uni-heidelberg.de
>>>         <mailto:cr at neuro.ma.uni-heidelberg.de>> wrote:
>>>
>>>             For binary images with 0 for background and 1 for
>>>             objects with an integer input pixel type there is a
>>>             problem representing the average of 0 and 1 = 0.5 with
>>>             the input pixel type. The output pixel type is required
>>>             to be a floating pixel type (filter documentation), so
>>>             it should be safe to change the type of levelSetValue to
>>>             OutputPixelType.
>>>
>>>             Regards,
>>>             Christina
>>>
>>>
>>>             _____________________________________
>>>             Powered by www.kitware.com <http://www.kitware.com>
>>>
>>>             Visit other Kitware open-source projects at
>>>             http://www.kitware.com/opensource/opensource.html
>>>             <http://www.kitware.com/opensource/opensource.html>
>>>
>>>             Kitware offers ITK Training Courses, for more
>>>             information visit:
>>>             http://www.kitware.com/products/protraining.php
>>>             <http://www.kitware.com/products/protraining.php>
>>>
>>>             Please keep messages on-topic and check the ITK FAQ at:
>>>             http://www.itk.org/Wiki/ITK_FAQ
>>>             <http://www.itk.org/Wiki/ITK_FAQ>
>>>
>>>             Follow this link to subscribe/unsubscribe:
>>>             http://public.kitware.com/mailman/listinfo/insight-users
>>>             <http://public.kitware.com/mailman/listinfo/insight-users>
>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20170331/cf83a8d7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-BUG-calculate-levelSetValue-for-IsoContourFilter-wit.patch
Type: text/x-patch
Size: 4861 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20170331/cf83a8d7/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ApproximateSignedDistanceMapImageFilter.cxx
Type: text/x-c++src
Size: 2704 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20170331/cf83a8d7/attachment.cxx>