[Insight-developers] Pixel type revisited

[Miller, James V (Research)]

Kurt,

There are a few filters that only make sense to run on certain data
types.  Some of these filters require floating point pixel values
otherwise calculations become too imprecise to be meaningful.  We
have discussed several options for "calling" out these filters. 
Solutions range from using special Doxygen tags to using the Concept
Checking to force a compiler error if the input/output is not the 
correct type.

Aside from the filters where the authors want to restrict the type
to float, if a filter does not work on a particular scalar type, then 
it is a bug. It is difficult to write filters that work correctly on 
any data type.  For instance, it the input to a filter is an unsigned 
char and the output is a short, what data type do you use for intermediate
calculations? unsigned char? short? float?  We have a NumericTraits<> has 
a RealType that can be used for intermediate calculations but it is not 
used consistenly throughout the toolkit. 

GE and Kitware try to make a few passes through the code a few times 
a year and identify problems with the filters.  We look for whether
the filters handle the pipeline mechanism correctly, when they
are multithreaded when it should be trivial to multithread an 
algorithm, whether the filter is using other subsystems of the toolkit,
and whether we think the appropriate data types are being used. 
Unfortunately, this like counting the grains of sand on the beach. So
we end up relying on the developers and users to tell us when a filter 
does not work properly on a particular data type and we'll go in and 
fix it.


Jim



> -----Original Message-----
> From: Kurt Augustine [mailto:augustine.kurt@mayo.edu]
> Sent: Friday, February 28, 2003 12:06 AM
> To: insight-developers@public.kitware.com
> Subject: [Insight-developers] Pixel type revisited
> 
> 
> I tried sending this to the users mailing list but it was 
> blocked (says I'm
> a non-member???) so I'm trying here.  I should be a member of both but
> something is messed up. --- Kurt
> 
> 
> As many of you may know, David and I are working on integrating ITK
> functionality into the software package we developed here 
> called Analyze
> (that's what our MLM contract states so that's what we MUST 
> do).  Without
> getting into the details of what Analyze is, suffice it to 
> say, it is a
> comprehensive imaging and visualization package used in a 
> wide variety of
> applications involving virtually ALL medical and many 
> biological imaging
> modalities.  As you know, David has been running into some 
> problems with the
> use of pixel types other than floats in his registration 
> work.  I have been
> running into similar problems while trying to implement a 
> number of the
> image filters.  For example, the GradientMagnitudeImageFilter fails to
> produce correct results when the pixel type of my image is 
> unsigned char but
> if I reformat the image to float, it produces exactly what I 
> would expect.
> 
> The problem: some filters work very well with non-float pixel types
> (BinomialBlurImageFilter, for example) and others don't (like
> GradientMagnitudeImageFilter).
> 
> Please forgive me if my ignorance is showing but I see no 
> reason why most
> image filters should not work with all (or most) pixel types 
> (if there are
> good reasons, and there may be, please educate me).  This is 
> similar to the
> issue David brought up earlier in the week but I think registration is
> considerably more complex.  As application developers, we certainly
> recognize the need to make our program "wise" enough to only 
> offer access to
> an appropriate, limited set of parameters based on the type 
> of registration
> being carried out.  We are not suggesting that every 
> registration parameter
> be exposed to the naive end user (not a programmer). That would be a
> disaster and one that we, the programmers must be smart 
> enough to guard
> against. That's different than the pixel type issue I started 
> out discussing
> so let me stop before I diverge any further.
> 
> In the interest of progress, we would love to get a list of all
> classes/filters/functions that require specific pixel types.  
> We can simply
> be sure to cast them to float and worry about potential 
> memory problems
> later.  If they are rewritten to support more pixel types 
> later on, we can
> change our application to support it as well.
> 
> Question: Does anyone have such a list or could it be readily 
> generated?
> 
> 
> Perhaps we could discuss this more during the tcon.
> 
> Thanks ... Kurt
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>