[Insight-developers] Modifying MaskImageFilter to work on VectorImage
Cory Quammen
cquammen at cs.unc.edu
Fri Apr 22 12:15:41 EDT 2011
Brad,
Before you start, I have a patch ready for gerrit, but it depends on
this patch: http://review.source.kitware.com/#change,1381
I'll push the patch to gerrit and add you all as reviewers.
Cory
2011/4/22 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
>
> Le 22 avr. 11 à 14:37, Bradley Lowekamp a écrit :
>
>> I very much would like to get this filter working with VectorImages.
>>
>> I don't want this to get forgotten. I think I will be able to take a stab
>> at it based on some of Cory's work in github.
>>
>> The same technique should be applied to the NotMaskImageFilter as well,
>> are there other similar masking filters?
>
> There is a masking filter for the LabelMap.
>
> Gaëtan
>
>
>
>>
>> Brad
>>
>>
>> On Apr 12, 2011, at 4:12 AM, Gaëtan Lehmann wrote:
>>
>>>
>>> Le 12 avr. 11 à 07:33, Cory Quammen a écrit :
>>>
>>>> Hi Gaëtan,
>>>>
>>>> Thank you for your thoughtful comments.
>>>>
>>>> 2011/4/11 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
>>>>>
>>>>> Hi Cory,
>>>>>
>>>>> I think this code would fail if the mask filter is run a second
>>>>> time with a
>>>>> vector image with a different number of components.
>>>>> There should be a check for the number of components in
>>>>> BeforeThreadedGenerateData().
>>>>
>>>> Yes, it would be good to check that the number of components in the
>>>> OutsideValue matches the number in the image, throwing an exception if
>>>> the number of components doesn't match.
>>>>
>>>>> The initialization of the default value of OutsideValue is quite
>>>>> problematic, as it can be done only when the number of components
>>>>> is known.
>>>>
>>>> Agreed!
>>>>
>>>>> A better option would be to have a way to say "I want to use the
>>>>> default
>>>>> value" - in that case the value can be generated in
>>>>> BeforeThreadedGenerateData() and would fit the vector the filter is
>>>>> currently working on - or "I want to use that value" and then it is
>>>>> the
>>>>> responsibility of the user to provide the right number of components.
>>>>>
>>>>> One way to implement that is to use a 3rd input for the filter
>>>>> which would
>>>>> be of type
>>>>>
>>>>> SimpleDataObjectDecorator< PixelType >
>>>>>
>>>>> and to not provide a default value by default - just keep the 3rd
>>>>> input as
>>>>> NULL. If there is no 3rd input, then the default value of
>>>>> OutsideValue can
>>>>> be generated in BeforeThreadedGenerateData(). If there is a 3rd
>>>>> input, then
>>>>> just use the value provided.
>>>>
>>>> While your suggestion sounds reasonable, the same behavior can also be
>>>> achieved using the current ITK norm of setting filter constants via a
>>>> method. All it would take would be to examine the OutsideValue to see
>>>> if it is zero length or if it consists of all zeros, and if so, infer
>>>> that the user wants to use the default value with the correct number
>>>> of components. To get back to the "default" value, all the user would
>>>> have to do is set the OutsideValue to some vector of zeros or a
>>>> zero-length vector. Does that seem reasonable?
>>>>
>>>>> An additional benefit of that approach: the OutsideValue can be
>>>>> provided
>>>>> through the pipeline, which is not the case currently.
>>>>
>>>> I think that your notion of treating filter constants as inputs to the
>>>> pipeline is very interesting and has merit, but I'll defer to more
>>>> experienced developers to determine if that is where ITK should be
>>>> heading.
>>>>
>>>
>>> Hi Cory,
>>>
>>> You're right, this is not the purpose of this change.
>>> Your proposition to use the default value for a zero length vector
>>> seems quite good to me.
>>>
>>> Gaëtan
>>>
>>>
>>>> Thanks,
>>>> Cory
>>>>
>>>>>
>>>>>
>>>>> Le 11 avr. 11 à 07:30, Cory Quammen a écrit :
>>>>>
>>>>>> David and Luis,
>>>>>>
>>>>>> I have posted a potential solution on github.
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/cquammen/ITK/commit/a92bcc79f267d79f48abb7358881c4b2323ae01d
>>>>>>
>>>>>> I will post it to gerrit if you don't see any showstoppers.
>>>>>>
>>>>>> Thanks,
>>>>>> Cory
>>>>>>
>>>>>> On Sun, Apr 10, 2011 at 5:50 PM, Luis Ibanez <luis.ibanez at kitware.com
>>>>>>>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi David,
>>>>>>>
>>>>>>> We have been discussing this problem with Julien Malik from the
>>>>>>> Orfeo Toolbox team.
>>>>>>>
>>>>>>> In summary, there is a function in the NumericTraits that is
>>>>>>> intended
>>>>>>> to deal with management of size in containers of variable size
>>>>>>> such as the VariableLengthVector and the std::vector.
>>>>>>>
>>>>>>> Regarding your questions, please see below.
>>>>>>>
>>>>>>> On Thu, Apr 7, 2011 at 7:50 PM, David Doria
>>>>>>> <daviddoria at gmail.com> wrote:
>>>>>>>>
>>>>>>>> We have been having some discussion on the best way to allow
>>>>>>>> MaskImageFilter
>>>>>>>> to work on VectorImage (with pixels of type
>>>>>>>> VariableLengthVector) . The
>>>>>>>> problem is that the length of a VariableLengthVector is not
>>>>>>>> defined at
>>>>>>>> compile time. This means that in the MaskInput functor, the
>>>>>>>> member m_OutsideValue cannot be initialized.
>>>>>>>>
>>>>>>>> Brad has identified two problems,
>>>>>>>>
>>>>>>>> 1) How do we initialized the member variable in the functor?
>>>>>>>>
>>>>>>>
>>>>>>> We usually add "Set" methods to the functor,
>>>>>>> the add "Set" methods to the Filter itself,
>>>>>>> and they simply call the "Set" methods of the functor.
>>>>>>>
>>>>>>>> This seems to be the main issue I'm not sure how to address.
>>>>>>>>
>>>>>>>> 2) When do we detect the size of the vector image, and use
>>>>>>>> reasonable
>>>>>>>> defaults?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> At run time,
>>>>>>> by asking them for their "GetNumberOfComponents()
>>>>>>> from the vector image.
>>>>>>>
>>>>>>> Reasonable default (otherwise) is "1".
>>>>>>>
>>>>>>>> We think this could be done in BeforeThreadedGenerateData.
>>>>>>>>
>>>>>>>
>>>>>>> Yes, that's a good place.
>>>>>>>
>>>>>>> The GenerateInputInformation() or
>>>>>>> GenerateOutputInformation() may
>>>>>>> be good places as well.
>>>>>>>
>>>>>>>
>>>>>>>> The complete conversation is here:
>>>>>>>>
>>>>>>>> http://review.source.kitware.com/#change,1338
>>>>>>>> Any thoughts are welcome!
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> David
>>
>> ========================================================
>> Bradley Lowekamp
>> Lockheed Martin Contractor for
>> Office of High Performance Computing and Communications
>> National Library of Medicine
>> blowekamp at mail.nih.gov
>>
>>
>
> --
> Gaëtan Lehmann
> Biologie du Développement et de la Reproduction
> INRA de Jouy-en-Josas (France)
> tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
> http://voxel.jouy.inra.fr http://www.itk.org
> http://www.mandriva.org http://www.bepo.fr
>
>
--
Cory Quammen
Computer Integrated Systems for Microscopy and Manipulation (CISMM)
Department of Computer Science
University of North Carolina at Chapel Hill
http://www.cs.unc.edu/~cquammen
More information about the Insight-developers
mailing list