Gdcm News
We know the following are missing; don't loose time looking for them ...
We know they could be helpfull. We shall add them some day.
Any contribution is welcome.
- Decoders
- gdcm doesn't read yet JPEG-LS encoded files.
We said 'JPEG-LS', not Lossless Jpeg ...
[JPEG-LS is the basis for new lossless/near-lossless compression
standard for continuous-tone images intended for JPEG2000.
The standard is based on the LOCO-I algorithm
(LOw COmplexity LOssless COmpression for Images)
developed at Hewlett-Packard Laboratories]
- gdcm doesn't read yet JPEG2000 encoded files.
But we are working on it.
- gdcm doesn't read yet MPEG2 encoded files.
But we are working on it.
- Reader
- Allow user to tell gdcm::Document constructor he just wants
to load a given list of DocEntries
(to save CPU time and RAM space)
- Allow 'frame by frame' reading (should be helpfull for huge
multiframe images)
- Allow subvolume selection / frames selection before reading.
- Expose Read/Decompression mechanisms to allow user getting
information from DICOMDIR
-or from his own Data Base-
and reading his images without parsing
the header, one more time.
- Writer
- Allow user to tell the Writer he doesn't want to write down
SeqEntry (if any)
- Allow user to tell the Writer he doesn't want to write down
Shadow groups (if any)
- Allow user to tell the Writer which compression mode he wants
(Right now, no one is available)
- Allow user to tell the Writer he wants to split a
Multiframe image into a serie of
Single frame images.
- Allow user to tell the Writer he wants to agregate a
Serie of Single frame images into a
Multiframe image.
- Reader / Writer
- Full Icon Image management (Read and Write)
- Full Overlays management (Read and Write)
both for 'ACR-NEMA style' (using groups 0x6000
and nexts) and 'DICOM V3 style' (using Sequences)
- DICOMDIR
- DICOMDIR full management (not limited to
PATIENT/STUDY/SERIE/IMAGE)
- Allow user to add an entry (belonging to the file header Dicom
entries)to the default entry list, before
making a DICOMDIR from a root directory
- Allow user to add an entry of his owns (for instance an Icon
to each image, or to each Serie).
- SerieHelper
- An accurate SerieHelper
Right now SerieHelper only works on 'bona fide Series', and
breaks on wrongly forged Series.
We are still looking for any heuristics...
- A SerieHelper that would use the DICOMDIR (if any)
instead of parsing all the files within the Root Directory
- Other
- 16-bits-LUT full Management
- User friendly management of Rescale Slope and
Rescale Intercept
- Allow parsing the Shadow groups against a user supplied
private Dicom Dictionary (pfff!...)
- State of the art
- New Features
- Both vtkgdcmViewer and vtkgdcmViewer2
are available to allow easy displaying of single/multiframe
GreyLevel/RGB/PaletteColor images
- DICOMDIR anonymiser (Load and Noload mode)
- User is now allowed to tell gdcm::Document constructor
he doesn't want to deal with SeqEntry
(every time it's possible)
and/or he doesn't
want to deal with Shadow groups (every time it's
possible)
use :
gdcm::File *f = new gdcm::File();
f->SetLoadMode(NO_SEQ | NO_SHADOW);
f->Load(fileName);
instead of :
gdcm::File *f = new gdcm::File(fileName);
(old style still available)
- User is now allowed to tell gdcm::DicomDir constructor
he doesn't want to deal with SeqEntry
(every time it's possible)
and/or he doesn't
want to deal with Shadow groups (every time it's
possible)
use :
gdcm::DicomDir *dcmdir = new gdcm::DicomDir( );
dcmdir->SetParseDir(true);
dcmdir->SetLoadMode(NO_SEQ | NO_SHADOW);
dcmdir->Load(dirName);
instead of :
gdcm::DicomDir *dcmdir = new gdcm::DicomDir(dirName, true);
(old style still available)
-
- Bug fixes
- The difference between MONOCHROME1 (low values = bright,
high values = dark) and MONOCHROME2 (low values = dark,
high values = bright) is now taken into account.
It's no longer up to the user to change the pixels value
- Writing a 'True Dicom' image after reading an ACR-NEMA image
does not request any longer from the user to build up
'manually' the Meta Elements group (Ox0002)
- Old '24 Bits' ACR-NEMA are now correctly re-written
in DICOM V3 mode.
- Element 0x0000 of Shadow groups is always forced to be a
ValEntry and its VR is forced to UL
-
- A.P.I. breaking modifications (since previous version : 1.0)
- NEVER more API breaking modifications !!!
- Known bugs
- Use of Implicit Value Representation writting mode may
causes troubles, when there are some SQ belonging to a
Shadow Group.
Better you use Explicit Value Representation writting mode ...
- State of the art
- A.P.I. breaking modifications (since previous version : 0.6)
- Use of namespace : all the methods formerly named
className::gdcmXxx() are now named className::Xxx()
End user will have to call them as gdcm::className::Xxx()
- a gdcm::Document is now specialized in :
- gdcm::DicomDir
- gdcm::File
- a gdcm::DicomElementSet is composed of a set of
gdcm::DicomDocEntry
- a gdcm::DicomDocEntry can be :
- a gdcm::ContentEntry, specialized in :
- gdcm::ValEntry
- gdcm::BinEntry (no longer a specialization of
gdcm::ValEntry)
- a gdcm::SeqEntry
- Removal of useless accessors GetXxxByname, SetXxxByname
- Renaming of accessors GetXxxByNumber, SetXxxByNumber
as follow :
- GetEntryByNumber
--> GetEntryValue
- GetEntryLengthByNumber --> GetEntryLength
- GetEntryOffsetByNumber --> GetEntryOffset
- GetEntryVRByNumber
--> GetEntryVR
-
- GetDocEntryByNumber
--> GetDocEntry
- GetValEntryByNumber
--> GetValEntry
- GetBinEntryByNumber
--> GetBinEntry
- GetSeqEntryByNumber
--> GetSeqEntry
This version will be used by Insight Tool Kit
(ITK 2.0) at the beginning of 2005.
It's not yet packaged ...
- User Documentation"
- Developper Documentation"
- The new gdcmDocument class is a parent class of
gdcmHeader class and gdcmDicomDir class.
- Massive modifications in the Class Diagram :
- any dicom related file is a gdcmDocument
- a gdcmDocument can be :
- a gdcmHeader, if it contains pixel data
- a gdcmDicomDir, if it contains only informations
on the files in a given directory
- a gdcmDocument is_a gdcmElementSet,
composed of a set of gdcmEntry separated into :
- gdcmValEntry
a specialization of gdcmValEntry, for 'non
std::string representable' values is
gdcmBinEntry
- gdcmSeqEntry (VR = SQ, i.e Dicom Sequences)
they are dealt as tree-like structures :
- a gdcmSeqEntry is considered as a set
of gdcmSQItem,
- a gdcmSQItem is_a gdcmElementSet, composed
of gdcmDocEntries, recursively
- Improvement of the jpeg sub-library: jpeg
compressed Dicom files (lossless and lossy)
might be read (check-it out)
- gdcm 0.4 UML Class Diagram.
- User Documentation"
- Developper Documentation
- Introduction of a jpeg sub-library: some very simple jpeg-lossy
compressed Dicom files might be working (check-it out).
- And also, fewer memory leaks, cleaned-up stl usage (should work
with gcc-3.x), python disutil installer (see file setup.py)
supporting both Swig and vtk wrapping.
- Introduction of a RLE (Run-Time Encoding) library
- Color images (RGB or Palette Color) are dealt with
- Confusing names gdcmPatient, gdcmStudy,
gdcmSerie, gdcmPatient changed to
gdcmDicomDirPatient, gdcmDicomDirStudy,
gdcmDicomDirSerie, gdcmDicomDirPatient
- gdcmFile class now enables acces to the data
i.e. the image[s] content. Previously only parsing of the
Dicom header was available through usage of gdcmHeader
class.
- a VTK plugin
of gdcm is now available through the vtkGdcmReader
vtk class (see it as a vtk wrapper of gdcm), which enables
- Loading of a single image,
- Loading of a stack of images from multiple Dicom files,
- this class is wrapped for vtkPython (by using native vtk
wrappers).
- Introduction of a jpeg sub-library: lossless-jpeg
compressed Dicom files work.
- vtkgdcmViewer allows easy displaying of single/multiframe
GreyLevel/RGB/PaletteColor images