bgilbert at cs.cmu.edu
Tue Sep 22 02:36:11 EDT 2015
On 09/21/2015 08:34 AM, Mathieu Malaterre wrote:
> On Sat, Sep 19, 2015 at 10:03 AM, Ivo Rakar <ivo23061987 at gmail.com> wrote:
>> I tried but I got the same result. I think that the problem lays in the
>> number of levels of the whole slide image. When I run this function
>> openslide_get_level_count(openslide_t * osr) the result is 2 with the DOGDIR
>> and the respective values are 1 for the first level and 1.9444444444444444
>> for the second level. If I try to do the same thing with another file, for
>> example OS-3.ndpi from the Openslide test data I got that is has 13 levels
>> with respective values [1.0, 2.0, 4.0, 8.0, 16.0, 32.0, 64.0, 128.0, 256.0,
>> 512.0, 1024.0, 2048.0, 4096.0].
> Since this is beyond my understanding of OpenSlide design, could you
> comment on Ivo issue with my DICOM implementation. [...] Is this an
> issue in my code, or just an artefact from a poorly optimized whole
> slide ?
OpenSlide uses the levels, level sizes, and downsamples provided by the
driver (or computes the downsamples if the driver doesn't specify them).
If the reported levels are, in fact, the levels available in the file,
then a) that's an unfortunate slide file layout, and b) your output is
correct. It shouldn't cause any problems with OpenSlide itself, but Ivo
is correct that many applications (including the OpenSlide Java demo
viewer) assume that a reasonable set of downsamples is available.
In general, OpenSlide does not synthesize intermediate levels; we try to
deliver the information actually present in the slide file, and leave
the post-processing to the application. (There is one driver, hamamatsu,
which does synthesize levels due to some quirks of the format.)
More information about the openslide-users