<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body>
<p>Hi Benjamin and Mathieu:</p>
<p>According with the Supplement 145/122, a Dicom image from the baseline (without resolution reduction) is the Case1: a multiframe image where every frame has the same size. There is a per-frame sequence where it indicates the space place of the frame in a the frame of reference (no colum / row correspondence). If there are other images with low resolution will be others instances in the same Series. (even the label)</p>
<p>The Case 2 is what Aperio (now Leica) patented http://www.google.com/patents/US8086077 and there are some legal problems for the implementation. (one of the reason the 145 is not present until today)</p>
<p>I have used gdcm (in phython) to generated a 145 image (it will be asap in the wg26 ftp i hope), but as Mathieu said there is a memory problem (418Mb is a "small" image as you know). </p>
<p>Another problem is the correspondence between columns / row - frame number and level - instance number. The 145 has no indication about (even you can have some radom frames). So the unique data we have yet is the relative position of the left / top pixel of the frame and the total dimension of the level. With that it's possible to get the correspondence with some calculs.</p>
<p>Let me know if I can help in this support</p>
<p>Best </p>
<p> </p>
<p>El 03/10/16 a las 14:18:14, Mathieu Malaterre via openslide-users escribió:</p>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<pre>Hi Benjamin !
On Mon, Oct 3, 2016 at 9:24 AM, Benjamin Gilbert via openslide-users
<<a href="mailto:openslide-users@lists.andrew.cmu.edu">openslide-users@lists.andrew.cmu.edu</a>> wrote:</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">Hi Mathieu, Thanks for the detailed response! On Wed, Sep 14, 2016 at 02:32:51PM +0200, Mathieu Malaterre via openslide-users wrote:
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">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.</blockquote>
Sure, but there are other cases where OpenSlide uses small parts of large libraries. The wasted address space doesn't bother me if it reduces the amount of code we have to maintain.</blockquote>
<pre>Right !</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">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.</blockquote>
I'm not thrilled with the streaming model: it may be more efficient, but at the cost of some indirection and lack of clarity. We clearly want to defer reading the image data, but is the metadata large enough that reading it into memory would really be costly? We'll probably need most of it anyway when generating OpenSlide properties.</blockquote>
<pre>Hum indeed this is actually a very good point. I was trying to be
smart with my fseek (NFS scenario) but indeed loading the whole file
may just work.
I did some quick tests.
Case 1: A single file is the concatenation of multiple JPEG streams.
This is the case for
<a href="ftp://medical.nema.org/MEDICAL/Dicom/DataSets/WG26/Hamamatsu/Human_15x15_20x.dcm">ftp://medical.nema.org/MEDICAL/Dicom/DataSets/WG26/Hamamatsu/Human_15x15_20x.dcm</a>.
In this case the DICOM header is ~696K (file is 418 MB).
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).
So even in the Case 2, this represent ~512Mo in memory. Does that
correspond to other slice format ?</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">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.</blockquote>
What are the problems specifically? Performance, reliability, features, ability to work around bugs in DICOM files?</blockquote>
<pre>As explained above: Point (2). All DICOM toolkits read the entire
file, using there own memory buffer... Supp 145 is very very different
from other class.</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">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</blockquote>
Yeah, we should try to avoid that.</blockquote>
<pre>OK.</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">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.</blockquote>
Not worth it, I think.</blockquote>
<pre>OK.</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">even if OpenSlide and FFmpeg do not share a common DICOM library, they would share a common code base.</blockquote>
If we do ship our own parser, I'd prefer that it completely conforms with OpenSlide's coding conventions, rather than trying to stay synchronized with ffmpeg. Copy-pasted code tends to diverge anyway, and we'd still need to be able to maintain it.</blockquote>
<pre>OK, make sense.</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">I did not describe the issue with DICOMDIR here, since I failed to understand what you meant.</blockquote>
I was thinking of the requirement for the user to generate a DICOMDIR if one doesn't exist, but I now understand that issue better and it's not relevant here.</blockquote>
<pre>Keep in mind my early implementation was done rather quickly (proof of
concept). I assumed a DICOMDIR would be available but if you tell me
how to handle the other case in the openslide framework, I can adapt
the code.
So the only question that remains is the loading of the complete
dataset in memory (as discussed above).
Cheers,</pre>
</blockquote>
<p> </p>
<div>
<pre>--
David de Mena García
Anatomía Patológica
H.U. de Jerez</pre>
</div>
</body></html>