[Insight-users] Problems with templated image
Luis Ibanez
luis . ibanez at kitware . com
Tue, 28 May 2002 14:21:02 -0400
Hi Mark,
The code in my previous email was just
a coarse example of how you could mix
ITK images with your inhouse images.
It wasn't intended to compile as it was.
My apologies if my message lead you to
think otherwise.
In the example that you sent, the problem
is that your "typedef"s are redeclaring the
type "bb" in the same scope. The "case:"
statements in a "switch" share the same scope
for variables, so you cannot repeat typedefs
with the same name or reuse variable names.
You can easily solve that by adding brackets
"{ }" to each one of the switch-cases in
order to create a local scope for declarations.
something like:
switch (a) {
case 0:
{ // <-- bracket to limit the scope of types
typedef vector<int> bb; // "bb" not a good name for a type
bb myIntVector;
break;
} // end of scope
case 1:
{// <-- bracket to limit the scope of types
typedef vector<double> bb;// "bb" not a good name for a type
bb myDoubleVector;
break;
} // end of scope
}
When using "switch" it is a good practice
to put the code blocks into brackets.
We are also strong supporters of long names
for types and variables. "bb" could much better
be "IntVectorType", in the first case, and
"DoubleVectorType" in the second case. That
naming could also have prevented the scope
problem.
About your second question:
The solution is another switch...
or given that you are only dealing with
2D and 3D a simple "if" could do it.
That will result in a matrix of all the
combinations between types and dimension.
Let me remark that this is not actually
an ITK-specific problem. Your application
will have the same problem even if you were
not using ITK. The only way to avoid
dimension-checking will be to restrict your
operations to pixel-wise operations. That is,
any conversions that don't require to use
neighbor pixels.
Could you give us some more detail about
the kind of conversions you are interested
on ?
You may be reinventing the conversion methods
that we already implemented in RAWImageIO and
MetaImageIO.
Note that these readers are capable of reading
images of almost any pixel type and convert it
to a predefined image type.
---
About the difficulty for managing image types
at run time in ITK: I'm affraid to disagree
with Jarek on this point.
My personal opinion (which probably is not shared
by other ITK developers) is that medical image
operations should NOT make types transparent for
developer nor users.
Pixel-type transparency is probably Ok for
"Photoshop-kind" of turn-key applications where
you want to make things very easy for users and
provide rapid results.
ITK is intended to be used in clinical practice
for managing real medical images that a doctor
can use for finding a tumor or guiding a surgery.
The pixel type in a medical image makes the difference
between detecting an early tumor or not, and that is
a *huge* difference !
Once you connect a series of filters in a type-transparent
pipeline it is very hard to keep track of the intermediate
losses and therefore is not easy to be confident in the
reliability of the final output.
Pixel type transparency will result in careless
and irresponsible management of medical information.
It will probably produce nice pictures but is not
what we may want to be used by clinicians.
(Sorry for being dogmatic on this).
Luis
=======================================
Mark Hastenteufel wrote:
> Hi Luis,
>
> thanks for your prompt answer. You gave me some example code for
> converting inhouse images to itk images. I have some further questions.
> First, are you sure the code you gave me runs? If I want to compile this
> little piece of test code
>
>
> switch (a) {
> case 0: typedef vector<int> bb;
> break;
> case 1: typedef vector<double> bb;
> break;
> }
>
> I get the following compile errors:
>
> test1.cpp: In function `int main()':
> test1.cpp:186: conflicting types for `typedef class
> vector<double,allocator<double> > bb'
> test1.cpp:184: previous declaration as `typedef class
> vector<int,allocator<int> > bb'
>
>
> The second questions regards the templated image dimension. What should
> I do, if I do not know the dimension of the image prior reading from
> disk or converting. We are working in our group with 2D, 3D as well as
> 4D (3D over time) images. So I want to implement code which runs for all
> kind of image dimensionality. Do you have any suggestions regarding this
> problem?
>
>
> Thanks,
>
> Mark
>
>