[Insight-developers] VectorType of itk::LevelSetFunction is FixedArray. Why not Vector?

[Zachary Pincus]

Hi Luis,

Thanks for your reply!

Josh Cates had some good commentary for why not to use itk::Vector  
for advection fields:

> Hi Zachary,
>
> As I recall, FixedArray was chosed for maximum compatibility with  
> the variety of vector types in itk.  For whatever reason, all  
> numeric vectors do not inherit from itk::Vector.  (To wit,  
> itk::CovariantVector is a sibling of itk::Vector and not its  
> child.  This setup also allows floating-point RGB type images.)   
> Images of itk::Vector should work, but I think you'll also be ok  
> changing the typedef in your own code.
>
> Josh.

I agree that it's easier to make a loop that copies a subclass of  
FixedArray into a FixedArray than copying one sibling type into  
another. Nevertheless, your point about Vector being the appropriate  
type for advection fields is very correct.

I'll try a build on my machine and see how that goes.

About the FixedArray read/write coverage: I can't seem to write  
Image<FixedArray<float, 2>, 2> images out to MHA/MHD files. Where  
would I look in the code to see what the coverage capabilities for a  
given file reader/writer are? (I'm not too familiar with how the  
reader/writer code is structured.)

Zach



On Jul 7, 2005, at 8:28 AM, Luis Ibanez wrote:

>
>
> Hi Zach,
>
> Thanks for pointing this out.
>
> There is no aparent reason why this VectorType couldn't
> be an itk::Vector instead of an itk::FixedArray.
>
>
> The fact that the VectorType represents an advection field
> is actually a good argument in favor of using an itk::Vector
> type instead of the itk::FixedArray type.
>
> Note that the IO argument may not be the best reason for
> changing the type. The coverage for reading and writing
> itk::FixedArrays should be as complete as the one for
> itk::Vectors
>
> The itk::Vector class derives from the itk::FixedArray,
> so the only reason for having them separate, is the fact
> that Vectors represent a geometrical concept in N-D space,
> and can therefore have a particular set of operators defined.
> A comparative discussion on the concept of Vectors, Points,
> Arrays... has been added to the second edition of the
> Software Guide:
>
>       http://www.itk.org/ItkSoftwareGuide.pdf
>
> you will find it in section 8.8.1 "Geometrical Representation"
> pdf-page 415.
>
>
>
> Probably the right way to proceed at this point, will be for
> you to change the type in your local copy, run and submit an
> experimental build, and if all the tests are green in the
> Dashboard then we will proceed to change the type.
>
>
> Please let us know if this option sounds reasonable to you.
>
>
>
>     Thanks
>
>
>        Luis
>
>
>
>
> -----------------------
> Zachary Pincus wrote:
>
>> Hi guys,
>> The base class for level set functions in ITK  
>> (itk::LevelSetFunction) typedef's VectorType as a FixedArray. This  
>> means that custom edge advection images need to have FixedArrays  
>> as pixels, which is inconvenient because most of the ImageWriter  
>> classes that deal with vector images only work with Vector-typed  
>> pixels, not FixedArray-typed pixels. Moreover, there are many  
>> appropriate numeric traits defined for Vector, but none for  
>> FixedArray -- this makes using filters on FixedArray images more  
>> challenging.
>> Is there any reason why FixedArray images are used in this case  
>> and not Vector images? Do FixedArrays have fewer data members or  
>> fewer virtual functions so that using them is significantly  
>> faster? Or is there some other advantage? If not, is there any  
>> reason not to change the LevelSetFunction typedef to Vector  
>> instead of FixedArray? (And you guys prudently wouldn't want to  
>> make this an ITK-wide change, is there any reason I wouldn't want  
>> change it for my own ITK checkout?)
>> Sure, I can pixel-by-pixel copy a Vector image to a FixedArray  
>> image, but if it's not necessary that's better for me.
>> Zach
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>