Add support for DICOM (aka Supp 145) #157

[Mathieu Malaterre]

On Fri, Oct 7, 2016 at 8:44 AM, David De Mena García via
openslide-users <openslide-users at lists.andrew.cmu.edu> wrote:
> 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
>
> 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.
>


I have no clue what you mean by 'Aperio proposition'. The paragraph
you quoted is from the original proposal (Supp) however this is not
the normative text. Instead you should be refering to the PS 3.3
documentation only.

Which states:

[...]
An entire set of tiles for an acquisition may be encoded in the frames
of a single SOP Instance, in multiple SOP Instances of a single
concatenation, or in multiple SOP Instances in a series (with or
without concatenations). E.g., a single SOP Instance may contain an
entire low resolution image as a single tile (single frame), or a
single SOP Instance may contain an entire high resolution, multi-focal
depth, multi-spectral acquisition (multiple frames).
[...]

ref:
http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.32.8.html#para_6f94f2c4-a42f-4d0a-9230-e08ef79837bb

>
> 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
>
> --
>
> David de Mena García
> Anatomía Patológica
> H.U. de Jerez
>
>
> _______________________________________________
> openslide-users mailing list
> openslide-users at lists.andrew.cmu.edu
> https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
>



-- 
Mathieu