[Insight-developers] Questions about itk::ImageIOBase::IOPixelType and Reading/Writing

[Bradley Lowekamp]

Hello,

I just reread what you wrote and realizes I just about repeated what  
you said. That is what I get for rushing before I leaving the computer.

I ran into a related but with MetaIO:
http://public.kitware.com/Bug/view.php?id=8732

After investigating further, it appears that the ImageFileReader does  
not pay attention to the PixelType. It just attempts to convert what  
it gets from the ImageIO object to it's templated pixel type  
disregarding what ImageIO says the pixel type is. So does the  
PixelType matter? For use with the ImageFIleReader I do not see how it  
would.

But it does matter if one use runtime information to determine your  
pixel type. Slicer makes heavy use of this, but they use the nrrd  
format a lot. I belive that nrrd correcly handles many different pixel  
types.

As pointed out in the bug report above, when streamed pasting is used,  
the pixel type also needs to be verified.

So is it the rule? I don't think so. It just hasn't been tested! As I  
don't think that scalar pixel types with multiple components makes  
much sense.


On another note, how hard would it be to get Nifty to support streamed  
writing?

Brad

On Mar 12, 2009, at 1:37 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote:

> Hello Kent,
>
> 	That doesn't sounds quite right to me. It is my understanding that  
> in the ImageFileReader::GenerateOutputInformation calls the  
> ImageIOBase::ReadImageInformation methods. I believe the expected  
> behavior is that all the meta data (largest region, origin, spacing  
> etc) an the pixel information (pixel type, component type and number  
> of components) is read by the derived ImageIO class and configures  
> the member variables of ImageIOBase with this information. So  
> NiftiImageIO should be detecting the pixel type in the  
> GenerateOutputInformation method.
>
> I am not sure of some of the detail your are describe but I hope I  
> have helped.
>
> Brad
>
> On Mar 12, 2009, at 1:23 PM, kent williams wrote:
>
>> I noticed this debugging a new itkNiftiImageIO test.
>>
>> The test was failing with an exception, having to do with trying to  
>> convert
>> pixel types between a vector of 6 floats and a scalar float.
>>
>> It turns out that the itkImageIOBase::m_PixelType was scalar, but I  
>> was
>> trying to read in an image with vector pixel types.
>>
>> So is this the rule?
>>
>> When you write a file itkImageFileWriter will set the PixelType for  
>> the
>> itkImageIO instance, but when you read the itkImageIO instance  
>> needs to set
>> the PixelType, and the itkImageFileReader then does whatever  
>> conversions it
>> can to return an image of the requested type.
>>
>>
>>
>> Notice: This UI Health Care e-mail (including attachments) is  
>> covered by the Electronic Communications Privacy Act, 18 U.S.C.  
>> 2510-2521, is confidential and may be legally privileged.  If you  
>> are not the intended recipient, you are hereby notified that any  
>> retention, dissemination, distribution, or copying of this  
>> communication is strictly prohibited.  Please reply to the sender  
>> that you have received the message in error, then delete it.  Thank  
>> you.
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.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
>
> ========================================================
> Bradley Lowekamp
> Lockheed Martin Contractor for
> Office of High Performance Computing and Communications
> National Library of Medicine
> blowekamp at mail.nih.gov
>
>
> <ATT00001.txt>

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