After looking at multiple solution it seems that we have the same dilemna as XML. GDCM will have to provide a DOM like approach and a SAX like approach for the exact same reason as those two interfaces exist.
gdcm::Parser will be the Simple API for DICOM aka SAD ;-P
GDCM development on CVS will stop since subversion is much more flexible. The sources are being moved carefully from one revision system to the other (allowing reoragnisation).
gdcm2 now has an alpah Printer. It will read the dicom file, element by element and interpet the Value tag to display it.
Enjoy
A lot of classes were moved recently, some were renamed. Some still need to be renamed therefore we need to agree on the terminology to be able to find the best possible name for a class.
All third party library needed for a full DICOM implementation where added to gdcm in the Utilities directory:
- IJG 6b
- JPEGLS 1.2
- OpenJPEG 1.0
- MPEG2
- ZLIB 1.2.3
- expat 2.0-pre (not really needed but very usefull since we want more XML!)
This project is based (heavily?) on gdcm(*). It's goal is too be even better than gdcm. Therefore we should support all the borken DICOM files gdcm support and fo even more.
Namely:
- Be faster
- More user friendly
- Read Write: Big Endian, Little Endian, Compressed raw...
- Support internationalization
- Well better in fact :)