[Insight-developers] What image types to wrap?

[Miller, James V (Research)]

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