openslide.level-count: '2'

Benjamin Gilbert bgilbert at
Tue Sep 22 02:36:11 EDT 2015

Hi Mathieu,

On 09/21/2015 08:34 AM, Mathieu Malaterre wrote:
> On Sat, Sep 19, 2015 at 10:03 AM, Ivo Rakar <ivo23061987 at> 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.)

--Benjamin Gilbert

More information about the openslide-users mailing list