Add support for DICOM (aka Supp 145) #157

[David De Mena García]

Hi:

>> On Mon, Oct 03, 2016 at 02:18:14PM +0200, Mathieu Malaterre
via openslide-users wrote: 
>> 
>>> Case 2: A single file contains a
single JPEG stream I did not have any dataset, so I used GDCM to split
the above dataset into individual file. In this case the header is 104K
(x 4824 files). This is nasty mostly because the ICC profile is repeated
in every single file (that may explain why no vendor choose to implement
this option).
>> As I understand the spec, all tiles from a given level,
Z-plane, and wavelength must be stored in a single image object, and
thus in a single file. (I think that's also what David is saying?) Am I
misunderstanding the spec, or is there another reason that there could
be a large number of files?
> 
> There is no requirement for the the
tiles of a given level to be
> stored in a single file. Technically I
also missed that, Alvaro did
> pointed the missing functionality in his
original post:
> 
>
https://lists.andrew.cmu.edu/pipermail/openslide-users/2015-March/001029.html
[1]
> 
>> 

About Matthieu said I would like to make a comment, because
the Supplement 145 said it clear about the "normal" tiles:

DESCRIPTION
OF WSI PROPOSAL

(line 287) "The basic mechanism proposed for storing
WSI images for Pathology in DICOM is to store the individual "tiles" of
a single WSI pyramid level as individual frames in a DICOM multi-frame
image object"

But the Z-planes and Wavelength could be stored in
separated objects:

(line 293) "Where multiple Z-plane images are needed
for the WSI, each plane may be stored separately in an object in the
series, or all the planes at one level may be stored in the same image
object. Similarly, for multispectral imaging each wavelength may be
stored separately, or all in the same object."

So, when you talking
about separated objects for one level I suppose or you are talking about
Aperio proposition (that is DICOM image, but not a VL Whole Slide
Microscopy Image SOP) or this case. 

> To be clear: you're saying that
GDCM and DCMTK need to load all of the image *data* into RAM, not just
the metadata?

Correct. Keep in mind that DICOM really is just like XML.
You need a
properly defined DTD and specifically tailored parser if you
want to
do anything smart.

In pydicom library there is a parameter in
the read_file (stop_before_pixels=True) that let you parse the tags less
the PixelData. Maybe this could be a help about how to proceed. 

Best 

ía Patológica H.U. de Jerez


Links:
------
[1]
https://lists.andrew.cmu.edu/pipermail/openslide-users/2015-March/001029.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/openslide-users/attachments/20161007/222660f7/attachment.html>