<B>D</B>i<B>C</B>o<B>M</B>.
<!###################################>
-<H2>What gdcm IS</H2>
+<H2>What gdcm <font color=#00ff00>IS</font></H2>
<UL>
<LI>gdcm implements the
<A HREF="http://www.dclunie.com/dicom-status/status.html">
<UL>
<LI>ACR-NEMA version 1 and 2
</LI>
- <LI>Dicom version 3 (including various encoding like jpeg or RLE).
+ <LI>Dicom version 3.0 (including various encodings of JPEG -lossless and
+ lossy-, RLE).
+ Please refer to
+ <A HREF="ConformanceSummary.html">gdcm conformance summary</A>
+ for more details.
+ <LI>Papyrus V2 and V3 file headers are readable; the user will have to use
+ low level accessors if he wants to get the image pixels -sorry-.
</LI>
</UL>
+<LI> gdcm includes a lot of heuristics that allow reading all the
+ 'exotic' files (headers with oddities) we had to deal with.<BR>
+ Any king of 'exotic' Dicom file is welcome, to help us to improve our
+ library.
+</LI>
</LI>
<LI>gdcm is distributed with
<A HREF="License.html">Berkeley-like license</A>.
</LI>
+<LI>gdcm is cross platform (it compiles with gcc 2.95, 2.96, 3.0.x, 3.2.x,
+ 3.3.x, 3.4.x, 4.0.x, 4.1.x , icc , cc (SunOS), VisualC++, Borland,
+ nmake... )
+</LI>
+<LI> gdcm has a nightly Dashboard (the whole lib is checked every night)
+</LI>
<LI>gdcm targets both GNU/Un*ces and Windows/VC++
(refer to
<A HREF="Installation.html#gdcmRequirements">requirements</A>
</LI>
<LI>gdcm comes with a
<A HREF="http://public.kitware.com/VTK">VTK</A>
- shallow wrapper class vtkGdcmReader (refer to
+ shallow wrapper class <TT>vtkGdcmReader</TT> (refer to
<A HREF="VtkGdcm.html">VtkGdcm</A>)
to ease the burden of VTK users,
<LI>gdcm also comes with
</UL>
<!###################################>
-<H2>What gdcm is NOT</H2>
+<H2>What gdcm is <font color=#ff0000>NOT</font></H2>
Except for
<A HREF="http://www.dclunie.com/dicom-status/status.html">
gdcm does NOT implement any other part of the Dicom base standard
(as opposed to other C++ based with open license libraries like
<A HREF="http://www.offis.de/projekte/ig/dicom/soft-docs/soft01_d.html">
- DCMTK </A>.
+ DCMTK</A>
or
<A HREF="http://www.erl.wustl.edu/DICOM/ctn.html">CTN</A>).
<BR>
In particular <B>gdcm is not aware</B> of:
<UL>
-<LI>the Dicom network file exchange protocol,
+<LI>the Dicom network file exchange protocol (Query/Retrieve),
</LI>
-<LI>the Dicom media storage formats,
+<LI>the Dicom media storage formats (well ... it knows about the
+ <TT>DICOMDIR</TT> -reading and writing- and its parts <TT>PATIENT</TT>,
+ <TT>STUDY</TT>, <TT>SERIES</TT>, <TT>IMAGE</TT>)
+</LI>
+<LI>Print, Verification
</LI>
<LI>ANY OTHER PART of Dicom.
</LI>
gdcm doesn't implement (yet?)
<UL>
<LI>the integration of (optional) overlays on image.
- </LI>
+ </li>
+ <LI>a support to write files according to the
+ <A HREF="ConformanceSummary.html">various classical Jpeg encodings</A>
+ (only read methods are provided)
+ </li>
+ <LI>a support to deal with JPEG 2000 encodings</A>
+ </li>
+</UL>
+Gdcm also still needs
+<UL>
+<LI> an enhanced and simpler API to access the various forms of pixel data
+ (e.g. RGB, GrayLevel, RawData...),
+</LI>
+<LI> a decent user's guide (currently, only a partial doxygenation is
+ available),
+</LI>
+<LI> the python wrappers to be fixed,
+</LI>
+<LI> a simple
+ <A HREF="http://www.wxwindows.org/">wxWidgets</A>
+ Dicom file editor.
+</LI>
+</UL>
</UL>
<HR size="1"><ADDRESS style="align: right;"></ADDRESS>