Proposals:Make GDCM the default DICOM: Difference between revisions
Hjmjohnson (talk | contribs) No edit summary |
|||
| Line 14: | Line 14: | ||
= General User Comments = | = General User Comments = | ||
GDCM has been much more useful and more fully implemented than DICOMImageIO2. The development group at Iowa fully supports this change. | GDCM has been much more useful and more fully implemented than DICOMImageIO2. The development group at Iowa fully supports this change. | ||
= Implementation Specific Comments = | |||
== DICOMSeriesFilenames == | |||
There is a lot of work to do. Keep in mind that those class were written against gdcm 0.5 which had lot less advanced features. Anyway to enhance the class I would also suggest it can have multiple choices of generating names: | |||
* Keep the original name, but then we have to write files in another directory (thus we need an 'input' dir and an 'output' dir). | |||
* Since DICOM does not specify the naming convention for the filename, we should be able to write the file under its UID (it's garantee to be unique!). | |||
* Another approach (more conventional) would be to specify a prefix and a pattern. (we don't require two differents directories anymore). | |||
== DICOMSeriesFilenames == | |||
gdcm 0.6 could only handle one serie within a directory. gdcm 1.0 and above have a much easier API to manipulate multiple series (and order files) within the same directory. For more info see gdcm::SerieHelper | |||
Revision as of 17:50, 18 April 2005
Proposal
Make GDCM to be the default DICOM implementation in itk.
Rationale
GDCM is a full featured DICOM read/write library that has an active development community. DICOMImageIO2 served the Insight community for a few years, but, it lacks DICOM write capablities and does not support all of the tags that itk is now using. DICOMImageIO2 no longer has an active developer community.
Roadblocks to the Change-Over
GDCM does not support all of the DICOMImageIO2 API's:
1. DICOMSeriesFilenames has a SetDirectory method while GDCMSerieFilenames uses SetInputDirectory and SetOutputDirectory. This roadblock can be removed if we add a SetDirectory method that applies the existing SetInputDirectory method.
2. DICOMSeriesFilenames can handle multiple series in one directory. Although the gcdm library appears to support multiple series in a directory, GDCMSeriesFilenames does not. This roadblock can be removed if GDCMSeriesFilenames adopts the DICOMSeriesFilenames API.
There may be other incompatabilities that should be discussed here.
General User Comments
GDCM has been much more useful and more fully implemented than DICOMImageIO2. The development group at Iowa fully supports this change.
Implementation Specific Comments
DICOMSeriesFilenames
There is a lot of work to do. Keep in mind that those class were written against gdcm 0.5 which had lot less advanced features. Anyway to enhance the class I would also suggest it can have multiple choices of generating names:
- Keep the original name, but then we have to write files in another directory (thus we need an 'input' dir and an 'output' dir).
- Since DICOM does not specify the naming convention for the filename, we should be able to write the file under its UID (it's garantee to be unique!).
- Another approach (more conventional) would be to specify a prefix and a pattern. (we don't require two differents directories anymore).
DICOMSeriesFilenames
gdcm 0.6 could only handle one serie within a directory. gdcm 1.0 and above have a much easier API to manipulate multiple series (and order files) within the same directory. For more info see gdcm::SerieHelper
