[Insight-developers] What image types to wrap?
Luis Ibanez
luis . ibanez at kitware . com
Tue, 08 Jul 2003 14:49:15 -0400
Jim,
Yes, I'm suggesting not to wrap "unsigned char" and "unsigned short".
The rationale is to reduce the wrapped types to the bare minimum.
The sacrifice as you pointed out, is that standard camera images will have
to be represented as "signed short".
For output/input, I think we can easily support most of the types.
So, in the case you cite, we will be able to read the "unsigned char" image,
process it in a pipeline composed of "float" + "signed short" filters, and
finally cast it at the output to "unsigned char"., That's the reason for
suggesting to instantiate the casting-like filters for almost all the
output types.
(float, double, unsigned/signed char, unsigned/signed int,
unsigned/signed long)
In particular, the filters
- RescaleIntensityImageFilter
- CastImageFilter
that will be typically used before a final writer.
---
All this is under the assumption that the typical use of the wrapping
will be
1) Rapid prototyping
2) Teaching
3) Demos
These activities can probably be performed with the restricted set
of types proposed above.
Real applications will still need to use C++,
or will have to visit the CableSwig configuration files and wrapp
their particular new image types.
Luis
-------------------------------------------
Miller, James V (Research) wrote:
>Luis,
>
>I agree with the overall philosophy. Particularly, that we try to limit
>filter instantiations to InputImageType == OutputImageType except for the
>cases where
>a filter has a well defined output image type that is different from the
>input
>image type (filters that produce label maps).
>
>You are also suggesting that we do NOT wrap images of unsigned char and
>unsigned
>short. That means that we would not be able to represent standard
>(grayscale) camera
>images in their native format.
>
>But do we still need to wrap images of unsigned char so that the PNG images
>can be
>written?
>
>Jim
>
>
>
>
>
>>-----Original Message-----
>>From: Luis Ibanez [mailto:luis . ibanez at kitware . com]
>>Sent: Tuesday, July 08, 2003 1:48 PM
>>To: Miller, James V (Research)
>>Cc: Insight-developers (E-mail)
>>Subject: Re: [Insight-developers] What image types to wrap?
>>
>>
>>
>>Hi Jim,
>>
>>A couple of suggestions :
>>
>>0) I agree with you in that only 2D and 3D should be wrapped.
>>
>>1) At the meeting we mention that wrapping "signed short" could be
>> better than wrapping "unsigned short", since in this way we can
>> manage CT data.
>>
>> we can still read 'unsigned short' from MRI into 'signed shorts'.
>>
>>
>>2) I would suggest also that the filter having Input/Output template
>>parameters
>> be wrapped only with the same image type. That is
>>
>> InputImageType == OutputImageType
>>
>> Except when the output image type is well defined (e.g. the
>>segmentation filters
>> that produce binary masks as output: Confidence connected
>>and so on).
>>
>>3) We can have Readers and Writers wrapped for a larger variety of
>>image types
>> and make the casting-like filters support these types.
>>For example
>>for the types
>>
>> float, double, int, unsigned int, char, unsigned char
>>
>> and the casting-like filters
>>
>> - RescaleIntensityFilter
>> - CastImageFilter
>> - ShiftScaleImageFilter
>>
>> This will allow to read and write many image types, even if we
>>restrict the
>> internal pipelines to run only on 'float' and 'signed short'.
>>
>>
>> 4) As you pointed out, label maps are quite a special case,
>> and maybe the only in which it is justified to wrapp for
>>
>> : unsigned long.
>>
>> That seems to be necessary, specially considering that
>>this is the
>> output of watersheds.
>>
>> We should only wrap for "unsigned long" the filters that are
>>expected to
>> manage labeled images.
>> (e.g. no reason for having a GaussianFilter here..
>>Instead we want
>> to make sure that the new ConnectedComponents filter is wrapped
>> for unsigned long.)
>>
>>--------------
>>
>>To summarize:
>>
>>The suggestion is to wrap most filters for
>>
>> - 2D/3D float
>> - 2D/3D signed short
>>
>>and only selected filters for other pixel types.
>>
>>
>>
>>Luis
>>
>>
>>
>>-------------------------------------
>>Miller, James V (Research) wrote:
>>
>>
>>
>>>At the last meeting we briefly discussed what image types should be
>>>wrapped by Swig when someone builds ITK out of the box. The user
>>>always has the option of adding more image types later and
>>>
>>>
>>adding more
>>
>>
>>>filter instantiations. But we still need to pick a good
>>>
>>>
>>set of image
>>
>>
>>>types that are immediately useful.
>>>
>>>Here is a set of suggestions:
>>>
>>>2D/3D float images - standard datatype used to avoid precision
>>>problems, PET images are floating point
>>>2D/3D short images - CT images (HU) are signed short
>>>2D/3D unsigned short images - MR images are unsigned short (?), PNG
>>>images are unsigned, label maps are unsigned
>>>2D/3D unsigned char images - PNG images are unsigned char
>>>2D/3D unsigned long - label maps are unsigned and can
>>>
>>>
>>easily overflow
>>
>>
>>>an unsigned short
>>>
>>>(Plus some RGB types)
>>>
>>>I think these basic image types should be wrapped. Then
>>>
>>>
>>the question
>>
>>
>>>is how many combinations of instantiations for filters should be do?
>>>
>>>
>>>*Jim Miller*
>>>*/_____________________________________/*
>>>/Visualization & Computer Vision//
>>>/GE Research/
>>>/Bldg. KW, Room C218B/
>>>/P.O. Box 8, Schenectady NY 12301/
>>>
>>>//_millerjv at research . ge . com <mailto:millerjv at research . ge . com>_/
>>>
>>>/james . miller at research . ge . com/ <mailto:james . miller at research . ge . com>
>>>/(518) 387-4005, Dial Comm: 8*833-4005, /
>>>/Cell: (518) 505-7065, Fax: (518) 387-6981/
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>