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.7016716003418imagedVolumeHeight: 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.
Thanks in advance for your help,
Lou-Anne
1 Like
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):
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:
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-
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
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-
