
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">

<html><body>

<pre><span style="white-space: normal;">Hi:</span></pre>

<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">

<pre><span style="white-space: normal;"><br /></span></pre>

<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">On Mon, Oct 03, 2016 at 02:18:14PM +0200, Mathieu Malaterre via openslide-users wrote:

<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">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).</blockquote>

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?</blockquote>

<pre>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:


<a href="https://lists.andrew.cmu.edu/pipermail/openslide-users/2015-March/001029.html">https://lists.andrew.cmu.edu/pipermail/openslide-users/2015-March/001029.html</a></pre>

<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%"></blockquote>

</blockquote>

<div>

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

<pre> </pre>

<pre>DESCRIPTION OF WSI PROPOSAL</pre>

<pre>(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"</pre>

<pre> </pre>

<pre>But the Z-planes and Wavelength could be stored in separated objects:</pre>

<pre> </pre>

<pre>(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."</pre>

<pre> </pre>

<pre>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. </pre>

<pre> </pre>

<pre> </pre>

<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">

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

</blockquote>

<pre> </pre>

<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">

<pre>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.</pre>

</blockquote>

<pre>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. </pre>

<pre> </pre>

<pre>Best </pre>

<h1 class="gh-header-title"><span style="font-size: 12px; white-space: pre-wrap;">-- </span></h1>

<pre>David de Mena García

Anatomía Patológica

H.U. de Jerez</pre>

</div>

</body></html>