# Found some bugs on Orthanc-WSI

**URL:** https://discourse.orthanc-server.org/t/found-some-bugs-on-orthanc-wsi/6431
**Category:** General
**Created:** [April 22, 2026, 3:35pm UTC](https://discourse.orthanc-server.org/t/found-some-bugs-on-orthanc-wsi/6431 "2026-04-22T15:35:35Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![ypollet](https://discourse.orthanc-server.org/letter_avatar_proxy/v4/letter/y/d78d45/32.png) [@ypollet](https://discourse.orthanc-server.org/u/ypollet)
#### Post date: [April 22, 2026, 3:35pm UTC](https://discourse.orthanc-server.org/t/found-some-bugs-on-orthanc-wsi/6431/1 "2026-04-22T15:35:36Z")

</div>

Hello,

We found some bugs/missing functionnalities on the WholeSlide Imaging plugin.

These are the options in our configs file :

```auto
"WholeSlideImaging": {
    "Enable": true,
    "EnableIIIF": true,
    "OrthancPublicURL": "http://localhost:8042/",
    "ServeMirador": true, // Whether to show the "Test IIIF in Mirador" button
    "ServeOpenSeadragon": true, // Whether to show the "Test IIIF in OpenSeadragon" button
    "ForcePowersOfTwoScaleFactors": true // Can be used to disable the compatibility mode
  }

```

1. In a series containing multiple high-resolution images (7942x7936) (where we need on-the-fly IIIF).  
The manifest.json for each individual instance works perfectly, because it “goes” to the link “wsi/iiif/frames-pyramids/instance\_UUID”, and also automatically pad the image cfr next\_screen.

 ![image](https://discourse.orthanc-server.org/uploads/default/original/2X/7/7431175f96f12a3ff47b5cd138e30242a5bcb5c7.png)

In comparison, when we get manifest.json from the series, Orthanc rightfully understand that there are different images (and send multiple items). But it goes to the link “wsi/iiif/frames/instance\_UUID/0/full/” (and doesn’t pad). (This is one instance of the series).

 ![image](https://discourse.orthanc-server.org/uploads/default/original/2X/b/b76ef844f9b4c7da86654dc298cff849c3fdf0f1.png)

Just in case, Orthanc differenciates correctly a series of a pre-tiled image and a series of multiple images to tile on-the-fly.

I would like to add that this problem shows only for series containing dicom files of encapsulated JPEG images.  
If these images are stored as PNG, Orthanc doesn’t generate the manifest.json

1. This is not urgent as the viewers work with the current plugin but the Standard IIIF API shows the following URI :  
{scheme}://{server}{/prefix}/{identifier}/{region}/{size}/{rotation}/{quality}.{format}

I do not know how to add Dicom Files here but this example has dicomized JPEG files (so it is encapsulated)

Thank you very much in advance for your reply,

---

<div class="post-metadata">

### Author: ![jodogne](https://discourse.orthanc-server.org/user_avatar/discourse.orthanc-server.org/jodogne/32/1511_2.png) [@jodogne](https://discourse.orthanc-server.org/u/jodogne)
#### Post date: [May 8, 2026, 3:37pm UTC](https://discourse.orthanc-server.org/t/found-some-bugs-on-orthanc-wsi/6431/2 "2026-05-08T15:37:00Z")

</div>

Dear Yann,

I’m unfortunately unable to understand your issue because you haven’t provided enough information for others to reproduce what you consider to be a bug. You should provide a minimal working example, including at least sample DICOM files and the exact calls to the REST API, [as explained in the Orthanc Book](https://orthanc.uclouvain.be/book/users/support.html#discussing-a-minimal-working-example).

> [@ypollet](#):
>
> The manifest.json for each individual instance works perfectly, […] In comparison, when we get manifest.json from the series […]

As written in the [documentation of the plugin](https://orthanc.uclouvain.be/book/plugins/wsi.html#rest-api): “The WSI plugin can also generate multi-resolution pyramids on-the-fly from the frames of a DICOM **instance** ”. This implies that this feature is _not_ supported at the series level. It is up to your higher-level application to deal with series containing high-resolution images, by generating IIIF links for the instances inside the series.

> [@ypollet](#):
>
> If these images are stored as PNG, Orthanc doesn’t generate the manifest.json

A minimal working example is definitely needed here.

> [@ypollet](#):
>
> ”wsi/iiif/frames-pyramids/[…]/0/full/max/0/default.jpg” should show the full image at max resolution for example instead of the smallest tile containing the full image.

From what I see in the [source code of the WSI plugin 3.3](https://orthanc.uclouvain.be/hg/orthanc-wsi/file/OrthancWSI-3.3/ViewerPlugin/IIIF.cpp#l940), `wsi/iiif/frames-pyramids/[...]/full/max/[...]` is simply not implemented. Again, I would need a minimal working example.

> [@ypollet](#):
>
> It could be nice to have the customization for at least “region” and “size”.  
> This will allow to generate thumbnails for example.

Yes, it would be nice to implement additional support for IIIF, but I already have many other tasks to work on. I would need backing from a research project, a scientific publication, or a funding agency to make this a high-priority task.

Kind Regards,  
Sébastien-

---

<div class="post-metadata">

### Author: ![ypollet](https://discourse.orthanc-server.org/letter_avatar_proxy/v4/letter/y/d78d45/32.png) [@ypollet](https://discourse.orthanc-server.org/u/ypollet)
#### Post date: [May 12, 2026, 9:53am UTC](https://discourse.orthanc-server.org/t/found-some-bugs-on-orthanc-wsi/6431/3 "2026-05-12T09:53:24Z")

</div>

[plugins.json](https://discourse.orthanc-server.org/uploads/short-url/5KcvgHOua4ooD1ivL1o2boNAV2k.json) (320 Bytes)

Sorry about that here is the config file.  
And [here](https://naturalsciences-my.sharepoint.com/:f:/g/personal/ypollet_naturalsciences_be/IgCtI5BSW4a0S5X0Y4wQ7khuAWBhIkYqz1-aLmqIXxaOjaA?e=tTI0Vn) are the dicom files. I added a file imported as a png, one imported as a jpeg and a pretiled dicom IIIF image.

For the last one, I forgot to add there is just a bug that appears sometimes on other IIIF viewers (e.g. Mirador and openseadragon), where there is an artefact on the bottom right corner when the image is dezoomed (it goes away when you zoom in). This bug also appeared on on-the-fly images.

But you answered here : it is just not supported at the series level and we will need to check if our images are pretiled or not tiled on-the-fly to send the right api call.

> [@jodogne](#):
>
> As written in the [documentation of the plugin](https://orthanc.uclouvain.be/book/plugins/wsi.html#rest-api): “The WSI plugin can also generate multi-resolution pyramids on-the-fly from the frames of a DICOM **instance** ”. This implies that this feature is _not_ supported at the series level. It is up to your higher-level application to deal with series containing high-resolution images, by generating IIIF links for the instances inside the series

The bugs cited in my first post are only on the series level API (for the PNG and JPG images), so it doesn’t matter in this case
