Add support for DICOM (aka Supp 145) #157

[Mathieu Malaterre]

On Fri, Oct 7, 2016 at 11:02 AM, David De Mena García
<david.mena.exts at juntadeandalucia.es> wrote:
> El 07/10/16 a las 09:01:04, Mathieu Malaterre escribió:
>
> 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
>
> -- Mathieu
>
> Hi, Mathieu:
>
> When you read this paragraphe alone, without any information, you can have a
> non correct interpretation. Of course the supplements are not DICOM
> normative part, but help with the interpretation. (because it's the WG that
> has published the supplment who propuse the change in the normative) When in
> Anex A.32.8 is talking about "multiple SOP Instances in a series" is about
> tiles from different levels, not in one level.

That's *precisely* the discussion with Benjamin. Scenario with
multiple 'files' (aka instances) for a particular level is valid.

In conclusion, my original "Case 2: A single file contains a single JPEG stream"
1. is not implemented currently
2. should be implemented
3. needs much more memory (mainly because of the ICC profile). So the
DICOM tree should be cleared, and ideally only one parse tree at a
time in memory.

-M