[Insight-users] How to read a DICOM volume in its native type?

[Mathieu Coursolle]

Hi,

Thanks for your reply. For dimensions, I always use the same (3D).
It is more on the component type that I am concern. Some of my images
are quite big. Some are stored as float, some as bytes. I do not want  
to load it as float
if all I need is a byte per scalar. Otherwise, I am using 4 times the  
needed memory.

Thanks,

Mathieu

On 8-Jan-09, at 1:49 PM, Bing Jian wrote:

> Hi Mathieu,
>
>   Here is Luis's response to one of my questions back to Nov. 2003  http://www.itk.org/pipermail/insight-users/2003-November/005652.html
>   Hope it helps.
>
> Bing
>
> On Thu, Jan 8, 2009 at 8:52 AM, Mathieu Coursolle <mcoursolle at rogue-research.com 
> > wrote:
> Hi ITK users,
>
> I've been using the itk::ImageSeriesReader with itk::GDCMImageIO to  
> read a DICOM volume from a
> series of slices with success.
>
> Here is part of the code I've been using:
>
> itk::ImageSeriesReader<itk::Image<double, 3> >::Pointer reader =  
> itk::ImageSeriesReader<ITK3DImage>::New();
> reader->SetFileNames(fileNames);
> reader->SetImageIO(dcmIO);
>
> At this time, I don't know what is the scalar component type of my  
> 3D image, so I specify double as the templated image type.
> If the image is in fact stored as bytes, I am using 8 times the  
> memory needed, which is quite annoying for large datasets.
>
> I currently cast it back to its native type once it is read.
>
> Does anybody have a suggestion on how I could check the native type  
> of the image before reading it?
> What I'd like to do is something like: read the header (not the  
> data) to check the native type, then create my image with
> that type.
>
> Note that I have the same issue with other image IO, so it is not a  
> DICOM specific issue.
>
> Thanks!
>
> Mathieu
>
>
>
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>
>

____________________
Mathieu Coursolle, M.Ing.		
Rogue Research Inc.
www.rogue-research.com







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090108/eff84057/attachment.htm>