[prev in list] [next in list] [prev in thread] [next in thread] 

List:       insight-users
Subject:    Re: [Insight-users] Image pixel type safety
From:       Wagner Sales <wsales () gmail ! com>
Date:       2009-11-25 14:19:41
Message-ID: 11b83aa60911250619i62e1d338x208e76b836701e9e () mail ! gmail ! com
[Download RAW message or body]

2009/11/24 Mathieu Malaterre <mathieu.malaterre@gmail.com>:
> On Tue, Nov 24, 2009 at 10:19 PM, Wagner Sales <wsales@gmail.com> wrote:
>> Hi all,
>>
>> I'm working with DICOM images and I'm looking for a pixel type safety.
>> I know are possible to use GDCMImageIO to ask about the pixel type of
>> an image. May be that's are the better way to read, register or
>> segment images. But in most cases ( registration are the most
>> important ) I have two different pixel types. Commonly, DICOM are 12
>> bit per pixel ( 4096 ), but I really don't know if are safe to read
>> all images without ask, but using a double or float as pixel type.
>> Many examples in ITK and others that's uses ITK simple define the
>> pixel type as float, for example. But this examples, in most cases,
>> expect a well known image to work (provided with the example). What's
>> I'm asking are: can I assume a fixed pixel type ( of course, a large
>> value, like double, and not a char, wish only supports 0-255 ) to read
>> images and do registration/segmentation? For example
>>
>> typedef itk::Image<float,3> ImageType;
>>
>> or
>>
>> typedef itk::Image<double, 3>  ImageType;
>>
>> Because some float issues, I'll prefer the second option.
>>
>> If can I assume this, are implications? Of course, if I didn't my
>> house work, please point me in a direction.
>
> DICOM does not support floating point image. The only case where you
> can have floating point image is when you have a Rescale Slope /
> Intercept.
> In which case the type used to describe the linear transformation ax +
> b where a,b are of type VR:DS (see DICOM PS 3.5-2008 for
> clarification) which is closely represented by a ieee double precision
> floating point type.
>
> So in summary: yes double will always work.
>
> Now the second question is: in a templated framework such as ITK; do
> you really want to process unsigned short image using double ?

Hi Mathieu,

Thanks to answer. I think using ushort will be less expensive to
process. But some algorithms in ITK expects double or float. And I
want to run away from conversions of pixel types.
Using double are so most expensive to be prohibitive as default? My
datasets are, in most cases, between 80MB or 120MB.

Regards,

Wagner
>
> HTH
> --
> Mathieu
>
_____________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.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-users

[prev in list] [next in list] [prev in thread] [next in thread]