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

[kent williams]

The reason I ran into a problem with the IOPixelType is that I was checking
it in Read(), and changing behavior, without setting it in
ReadImageInformation().   Maybe to say what I meant more clearly:

When you write a file, the PixelType is set for you by itk::ImageFileWriter,
so that the concrete itk::ImageIO class can translate the type info into
whatever the image file format expects.  When you read a file, the ImageIO
has to set its own PixelType based on the file metadata; otherwise
itk::ImageFileReader doesn¹t know what to do with the pixel data.

It makes perfect sense, but in the nearly 1200 lines of itkNiftiImageIO.cxx
I didn¹t realize it wasn¹t happening. Most of the time it¹s moot because it
defaults to SCALAR, and most images have scalar pixel types.

As to the second question:  it¹s been at least 18 months since I wrestled
with streamed IO.  The short answer is Œnot super hard¹ -- niftilib has a
function to read subregions of an image, called, aptly enough
nifti_read_subregion_image.  The long answer is I¹ve mostly forgotten
everything I learned about making an ImageIO streamable, and would have to
re-learn how it¹s done, so it might take me a while.  If anyone else is an
expert on making ImageIO streamable, I can certainly help them out on the
NIfTI side ;-)

On 3/12/09 7:21 PM, "Bradley Lowekamp" <blowekamp at mail.nih.gov> wrote:

> 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
> 




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.

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