[Insight-developers] writing filters to support scalar and vector image types

[Bradley Lowekamp]

Hello Kris,

SimpelITK uses VectorImage to represent multi-component image. So I would be bias to suggest that you support VectorImages.

I'd suggest you first write the filter to work with VectorImages. It should be easy to support RGB/fixed array type images after that ( as long as input number of components matches the output ).

After you have that working, I'd look into adding support for scalars to the same class as well. This may requires certain methods to be dispatched based on the pixel-type, but with some assistance from people who have done this before it shouldn't be too bad of an addition. If 95% of the filter will be the same for both scalar and vector-images this should work quite well. So I guess this is suggesting approach 3 with the image-type specialization methods happening internally to the filter.

Hope this helps,
Brad


On Sep 1, 2011, at 1:59 PM, Kris Zygmunt wrote:

> Hello,
>    I am currently writing a filter that will need to support both  
> scalar pixels and vector pixels.  What is the recommended approach for  
> handling this?  Are there any best-of-class examples to look at for  
> guidance?  I will be assuming that the components of the vector are  
> independent and thus be performing component-wise math such as  
> addition, subtraction, multiplication, division, minimization, and  
> maximization on each channel separately.  I see a few different  
> approaches possible:
> 
> 1.  I could easily write a filter that only works with vector pixels,  
> but this would require the user to take any scalar image (greyscale,  
> T1 MR, T2 MR, etc) and convert it to a vector (On the input, they  
> could use a scalar image as vector image accessor.  For the output  
> image, they would also have to convert it back to a scalar image.)   
> This approach seems overly complicated for users with scalar images.
> 
> 2.  I can provide both a scalar and vector implementation of the  
> filter, but this will have a ton of redundancy, making maintenance  
> more complicated and error-prone.
> 
> 3.  I could provide (maybe through numeric_traits??) a definition of  
> operator*, operator/, etc that would do the component-wise operation.   
> If this is undesirable due to ambiguity, I could also provide  
> ComponentMultiply(val1, val2), ComponentDivide(val1, val2), etc that  
> would have the appropriate specializations for both scalar data (would  
> just default to operator* in this case) and vector data.  And then  
> call these functions as appropriate.  Then for the special cases like  
> finding min/max for each channel, I could call the appropriate  
> specialization (for scalar just use MinimumMaximumImageFilter, for  
> vector, loop over the components, calling MinimumMaximumImageFilter  
> for each channel independently using an accessor/filter that extracts  
> the components).
> 
> 
> Also, my approach for supporting RGB pixels is going to be to treat  
> each color component as an independent channel (I'm writing a nonlocal  
> means denoising filter).  Is the ITK-preferred approach to have the  
> user provide the data as a VectorImage in this case, or should I also  
> apply the chosen strategy (1, 2, or 3 above) for RGB pixels as a third  
> class to consider, separate from scalar and vector?
> 
> Thanks!
> Kris
> _______________________________________________
> 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://kitware.com/products/protraining.html
> 
> 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://www.itk.org/mailman/listinfo/insight-developers