[Insight-developers] MetaIO and vector images

[Bradley Lowekamp]

So the solution is to add the following to ReadImageInformation:

if (m_MetaImage.ElementNumberOfChannels() > 1)
{
this->SetPixelType( VECTOR );
}

and add a test to verify this too. Also relate the conditions for  
streaming/pasting too.

Also, I think it would be a good idea to log the MetaIO feature of  
improved pixel information into Mantis too.


On Mar 17, 2009, at 4:33 PM, Stephen Aylward wrote:

> Cool.
>
> Nice example.
>
> Agreed - the way it is interpreted by ITK is wrong.   The PixelType
> set internal to ITK should be VECTOR, not scalar.    I mistakenly
> thought you were suggesting that the way it was being written was
> wrong and should be changed to write the file as MET_FLOAT_ARRAY.
> Sorry - my mistake.

You were not mistaken. I suggested both ways, and was leaning towards  
the wrong way of using MET_FLOAT_ARRAY, but was uncertain what was  
correct.

>
>
>> Adding a new variable to the file format to explicitly specify the  
>> PixelType
>> (Vector, FixedArray, RGB, RGBA, Offset, Matrix) would be very  
>> useful! It
>> could perhaps even make the writing an injective or one-to-one  
>> operation,
>> there by not loosing any pixel information in the process.
>
> I think this would be useful.   Always wanted to do this.   It is
> backward compatible.   Almost like a suggestion of how the image
> should be read.   Would make distinguishing RGB vs generic
> multi-valued images easier to deal with.
>
> The idea behind MET_*_ARRAY, btw, was to allow arrays (and MET*MATRIX)
> as elements.  This is implemented when a single tag can be assigned
> multiple values (e.g., DimSize) - compare this with scalar tags (e.g.,
> NDims).    That is, DimSize is MET_UINT_ARRAY while NDims is MET_UINT.
>     That is, a MET_*_ARRAY and a MET_*_MATRIX, like all MET_*, should
> describe what is reference via a tag.    We have a metaArray class
> that derives from metaForm.   We also have (in a private stash) a
> metaMatrix class that also derives from metaForm.      When trying to
> come up with a consistent view of a Form, Matrix, Array, and
> multi-channel image, we decided that a channel was the "tag" level of
> an image.    metaMatrix, Array, and Form do adhere to this concept.
> I fear that we never completed refactoring the image to support this
> concept.  The fault is actually that we never provided a method for
> writing images with vectors of vectors at their pixels.   So, an image
> of element type MET_*_ARRAY (or MET_*_MATRIX) should never be created.

That clears things up.

Thank you for this discussion,
Brad

>
>
> I hope this helps,
> s
>
> -- 
> Stephen R. Aylward, Ph.D.
> Chief Medical Scientist
> Kitware, Inc. - North Carolina Office
> http://www.kitware.com
> (518) 371-3971 x300

========================================================
Bradley Lowekamp
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine
blowekamp at mail.nih.gov


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090317/5c09d1e3/attachment.htm>