[Insight-users] Re: ITK Questions
Ofri Sadowsky
ofri@cs.jhu.edu
Fri, 15 Nov 2002 16:30:12 -0500
1. OK. Are the test programs updated too?
2. I looked at MetaImageImporter and got the idea of how to use it. But it
would be more helpful if the MetaImageIO format were documented in detail
somewhere. I don't want to rely on the manual process in MetaImageImporter
only. Then, I was not sure how to use MetaImageIO. In particular, MetaImageIO
defines the function
MetaImage * GetMetaImagePointer (void)
but no link to class MetaImage is provided, and I could find no reference for
it in the manual.
3. By meta-information I mean items such as the ones in Dicom: hospital name,
patient age, x-ray energy, etc., which may vary between images and according
to the needs of the user. Neither ImageIOBase nor MetaImageIO has any methods
to handle that. I think it's hard to give a general format to
meta-information, but it may prove useful when I want to customize and label
images. For example, it can provide time stamps for image sequence (video
etc.), bed position, or any other parameter by which the images are
parametrized. Maybe the MetaImage class contains something like that and
maybe not. Maybe the simplest answer is to write my own format and reader.
But at least for the dicom format, it would be convenient if ITK provided
methods to extract meta-information, e.g. by tag code.
4. I'm sending this email to the list as well. I hope that's fine.
5. My installed version of ITK is 1.0.0. I could start a CVS tracking of
changes, but it has some drawbacks. For once, I want to use a more or less
stabilized interface. Then, I don't want to rebuild the ITK libraries every
other day, or even every week. Do you have a recommended update strategy for
"external" users? How stabilized are the release interfaces?
Thanks,
Ofri.
Luis Ibanez wrote:
> Hi Ofri,
>
> Please find below comments/answers to your questions.
>
> 1) You are right about the inconsistency on the DicomImageIO
> object. The constructor and destructor should be protected.
> I just fixed this in the repository. The DicomImageIO object
> is intended to be used a any other ImageIO object.
>
> Something like:
>
> itk::DicomImageIO::Pointer dicomIO =
> itk::DicomImageIO::New();
>
> typedef itk::ImageFileWriter<ImageType> WriterType;
> WriterType::Pointer writer = WriterType::New();
>
> writer->SetImageIO( dicomIO );
>
> 2) The easiest way at this point to read a group
> of dicom slices into a volume is to write a
> MetaImage header for them. This is pretty simple
> to do. The application: MetaImageImporter will
> guide you step by step through the process.
>
> You basically create a text header that lists the
> names of the dicom files as well as the basic
> information about spacing and size.
>
> 3) Well, this is already what you get from the MetaImage
> reader. Have you tried this approach ?
> Do you see any serious drawbacks on it ?
> BTW: ITK is not a Kitware only product. It is
> developed by a consortium integrating many different
> groups. Kitware is however strongly commited to
> maintain and further develop the toolkit.
>
> 4) Sure,
> here is the link to the web site where you can
> suscribe. This is mailman, it is pretty flexible
> as to how you want to customize your suscription
> to the list.
>
> http://www.itk.org/mailman/listinfo/insight-users
>
> Please let me know if you have any other questions.
>
> Thanks
>
> Luis
>
> -------------
>
> Ofri Sadowsky wrote:
>
> > Hi Luis,
> >
> > I have some more questions regarding itk::DicomImageIO and related
> > classes.
> >
> > 1. I was looking at the test code provided with ITK at
> > itkDicomImageIOTest.cxx . In line 43 it calls
> > itk::DicomImageIOFactory::RegisterOneFactory();
> > Then, in the doxygen on the web site, the way to use itkImageIOBase is
> > to plug it into an itkImageFileReader. That is consistent with the
> > example in itkPNGImageIOTest.cxx.
> > Also, in itkPNGImageIO the ctor is protected, and an object is created
> > by the New() factory method. But in the doxygen of itkDicomImageIO the
> > ctor is public, which is inconsistent again.
> > So what is the right way to use itkDicomImageIO?
> >
> > I ran the IO test on one image that I have, and it seems to run without
> > problems. At least that means that it works.
> >
> > 2. We had a previous discussion about the difficulties of processing
> > DICOM files. Since there is a problem in reading a set of slices and
> > ordering them correctly, especially when the inter-slice spacing is
> > nonuniform, I thought I could do at the beginning with processing each
> > slice separately. The itk::DicomImageIO provides the public methods for
> > setting a file prefix or a file pattern, but I could not understand how
> > the range of numbers in the pattern can be provided to the DicomImageIO.
> > Also, I should be able to find the bed position from the dicom file (the
> > third coordinate). Is there any method in ITK for that? I guess that you
> > can't associate this number with ITK 2D image, but at least I'd like to
> > have some access to it.
> >
> > 3. In the long run, it might be useful to have some Dicom tag-set that
> > stores all the meta information on a study (or an image) in one
> > structure. Are there any plans in Kitware to create such a structure?
> >
> > 4. I think there was a mailing list of ITK developers/users that you
> > refered me to previously, but I lost the email. Could you send it to me
> > again please?
> >
> > Thanks,
> >
> > Ofri Sadowsky
> >
> >
> >