Bug with Mirax files: imagedVolumeWidth and imagedVolumeHeight values are swapped

General
1

Hi,

I’d like to report a bug related to the handling of Mirax slide files. It seems that the values of the imagedVolumeWidth and imagedVolumeHeight fields are swapped in the metadata.

Using the following slide: CMU-Saved-1_16, Orthanc reports:

  • imagedVolumeWidth: 54.7016716003418
  • imagedVolumeHeight: 26.611949920654297

However, when opening the same slide in QuPath (see screenshot below), the actual orientation clearly shows that the height is larger than the width.

image
image1543×868 161 KB

Thanks in advance for your help,

Lou-Anne

1 Like
2

Dear Lou-Anne,

I reproduce here an image from page 11 of DICOM Supplement 145 (use wget or curl to download this document, as it is only available over FTP):

image
image640×407 24.3 KB

In this image, the “columns/rows” correspond to the pixels coordinates, whereas “X/Y/Z” correspond to the physical coordinates of the slide (aka. the “imaged volume”). As can be seen, there is a swap in the axes: The “columns” (i.e., x-axis in terms of pixel coordinates, expressed in pixels) correspond to the “lines” of the slide (i.e., Y-axis in terms of physical coordinates, expressed in millimeters).

Both QuPath (cf. your screenshot) and Orthanc WSI viewer display the scanned images in “pixel coordinates”. Replicating the DICOM conventions explained above onto your screenshot, we get:

image
image1543×868 84.1 KB

This explains why, given your MIRAX image, the Orthanc DICOM-izer assumes that the ImagedVolumeWidth (i.e., the physical width measured along the “imaged X” axis) is larger than the ImagedVolumeHeight (i.e., the physical height measured along the “imaged Y” axis). I agree that this swap of the axes is not intuitive and can easily lead to interpretation errors. Note that this is not specific to the MIRAX file format.

This is my personal interpretation of the standard, but I evidently could be wrong.

Kind Regards,
Sébastien-

3

Dear Sebastien,

The description of tags says :
Width of total imaged volume (distance in the direction of rows in each Frame) in mm
Height of total imaged volume (distance in the direction of columns in each Frame) in mm.

To my understanding it’s talking about the resulting generated image Width and Height and not from the specimen point of view.

I think to switch back to specimen the Image Orientation which exist on WSI is the link to get back to the specimen reference C.8.12.14 Microscope Slide Layer Tile Organization Module

My personal opinion is the the imagED is specifying the physicial size of the resulting image and not the original specimen orientation.

Another clue we have is we see a pixel size difference between Qpath reading the original slide in proprietary format being different from the WSIDicomizer resulting pixel spacing metadata (and if we switch height and width we fallback to the same Qpath pixel value)

@Lou-Anne correct me if i’m wrong but we also have rectangular pixel size (x and y spacing not equals) with WSIDicomizer and square pixel (x = y pixel spacing) in Qpath which is more likely to be the correct value

Best regards,

Salim

4

Hi Salim,

It seems we have different interpretations of the standard. I would kindly recommend raising this question in the official DICOM discussion group to gather broader input. I’d prefer not to modify Orthanc’s current behavior unless it is clearly confirmed to be a bug.

Also, please note that you can always access the “Pixel Spacing” information to go from pixels to millimeters. This tag really reports (mostly) square pixels:

$ curl http://localhost:8042/instances/5b7f1704-65bdc75f-5cc34a63-79a241ac-4f041413/tags?simplify
{
   [...]
   "SharedFunctionalGroupsSequence" : [
      {
         "OpticalPathIdentificationSequence" : [
            {
               "OpticalPathIdentifier" : "1"
            }
         ],
         "PixelMeasuresSequence" : [
            {
               "PixelSpacing" : "0.0297266971\\0.0297219027",
               "SliceThickness" : "1"
            }
         ]
      }
   ],
   [...]
}

Best,
Sébastien-

5

It’s done : https://groups.google.com/g/dicomforum/c/TNFRCJwPLAg

6

Dear Sebastien,

We got an anwser on the DICOM group, there is a pretty good signal that the ImagedVolumeWidth and ImagedVolumeHeight is based on the resulting image size (see David’s response)

Also I looked over DICOMs WSI datasets of the community and found this sample : https://viewer.imaging.datacommons.cancer.gov/slim/studies/2.25.272404498989310289528949631224247689009/series/1.3.6.1.4.1.5962.99.1.1266888645.512070235.1714958872517.4.0

I selected this series because of the width / height being clearly different (vertical image Height > width), in dicom tags we have :
ImagedVolumeWidth : 9.04621696472168
ImagedVolumeHeight : 11.726876258850098

What do you think ?

Best regards,

Salim

7

Dear Salim and Lou-Anne,

Sorry for the delay. I have just implemented the swap of the imaged width/height by the following changeset that is pending in the mainline.

I confirm that the generated images are now valid according to the recent versions of dciodvfy mentioned by David Clunie (latest snapshot 20251020111927), which was not the case of release 3.2 of OrthancWSIDicomizer.

Please could you make some tests to validate the new version? As usual, precompiled binaries are available. Depending on your validation, I plan a new release in the next few days.

Kind Regards,
Sébastien-

8

Dear Sebastien, we finished the project funding for this project, i’m afraid we won’t be able to test (i don’t have the testing dataset in hands), but we are pretty confident on your fix !

Thank you so much !