Add support for DICOM (aka Supp 145) #157

[Mathieu Malaterre]

Hi Benjamin,

Thanks for taking the time to review my PR !

> I think the major question is whether we should really be implementing our own DICOM parser, or whether we should use an existing DICOM library instead.

Here is the summary (pros):

1. OpenSlide needs to handle a very particular subset of the DICOM
Transfer Syntax(s). Because of some low level (boring) details, some
complex parsing issues are totally avoided in that subset. What this
means is that the (limited) parser can be much smaller in code size
compared to a full implementation.
2. OpenSlide needs a particular DICOM parsing behavior (typically SAX
or StaX in the XML world), with an optimization toward reading images
out of DICOM file.
3. OpenSlide is a small C library, limited to reading from file.

Of course I am very biased here, but anyway I do believe that because
of the previous 3 points it makes sense to have this small DICOM C
code within OpenSlide.

---

I do not know of a quality C DICOM implementation. I do not believe
medcon would be a good fit here. I know of two relatively good generic
C++ toolkit: GDCM & DCMTK. As upstream author of GDCM, I am in a
position to say that GDCM also does not make a good fit here. That
leaves us with DCMTK. What I do know is that the code is very complex
in part because of the code legacy and because DCMTK is a generic
DICOM toolkit. So IMHO DCMTK is also not a good fit here, esp because
of point (2), which is something very special in the DICOM world. I do
know of vtk-dicom, but this library does pull in an insane amount of
dependencies, which I believe is not a good thing for OpenSlide (I do
not believe it support WSI by design anyway).

---

I could also build some kind of abstract level on top of this library
and only use that abstract level within the core openslide
implementation (eg. parse_header_dicom(), read_tile_dicom...). This
would make transition to another DICOM library trivial (tm) in the
future.

Finally to be complete, the DICOM parser included in this PR is
directly derived from a WIP I submitted to libav[1]. As everyone knows
now, I bet on the wrong horse, and I would need to re-submit to ffmeg
at some point. Eventually, what I am trying to say is even if
OpenSlide and FFmpeg do not share a common DICOM library, they would
share a common code base.

I did not describe the issue with DICOMDIR here, since I failed to
understand what you meant. My limited parser does handle enough of
DICOMDIR to be usable, and at least one openslide user on windows
reported being able to load DICOMDIR(s).

Until this point is resolved I'll hold off all further review. Let me
know if any of the above makes any sense.

Thanks again for your time,

[1] https://lists.libav.org/pipermail/libav-devel/2015-March/068286.html
-- 
Mathieu