[ITK-users] Patch for ApproximateSignedDistanceMapImageFilter

Mon Apr 3 15:18:03 EDT 2017

Hi Christina,

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

Thanks! This patch has been uploaded:

  http://review.source.kitware.com/#/c/22149/3

The typos could go in a different patch (ideally), but it is OK, if
they are included.

Thanks,
Matt

> 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> 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
>>
>> On Fri, Mar 3, 2017 at 8:23 AM, Chr. Rossmanith
>> <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
>>>
>>> On Wed, Mar 1, 2017 at 8:12 AM, Chr. Rossmanith
>>> <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
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Kitware offers ITK Training Courses, for more information visit:
>>>> 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
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/insight-users
>>>>
>>>
>>>
>>
>>
>
>
>
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> 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
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-users
>