[Insight-developers] Pixel type revisited

[Kurt Augustine]

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