WSI imagedVolumeWidth/imagedVolumeHeight is Image based or slide based orientation ?

[Salim Kanoun]

Hi there,

I'm reaching the community to better understand the DICOM standard specification for Whole Slide Images, this is after a discussion on Orthanc Implementation with Sebastien Jodogne (https://discourse.orthanc-server.org/t/bug-with-mirax-files-imagedvolumewidth-and-imagedvolumeheight-values-are-swapped/5912/1)

The DICOM WSI has a change of orientation compared to the Slide coordinate, so X orientation in slide coordinate is in the image rows direction and Y slide coordinate is in column image direction.

With Sebastien we have a difference of understanding for the imagedVolumeWidth and imagedVolumeHeight meaning.

Those tags are giving the physical size of the slide.

Is these value related to the physical width/height following the orientation of the generated image or the width/height following the orientation of the slide ? 

We want in the viewer compute the physical size of a pixel, so

- If those tag are based on the resulting image the physical size the pixel size calculation will be : 

x spacing = imagedVolumeWidth / number of columns

y spacing = imagedVolumeHeight / number of rows

- If those tag are related to the slide orientation the computation will be

x spacing = imagedVolumeWidth / number of rows

y spacing = imagedVolumeHeight / number of columns

Thanks for you help !

Salim

[Salim Kanoun]

Hi there, 

Any opinion about this question ?

Is there some reference validated DICOM WSI that could serve as reference to check how this metadata has been considered ?

Best regards,

Salim

[Justin Kirby]

There are lots of freely available DICOM pathology reference datasets at https://portal.imaging.datacommons.cancer.gov/explore/filters/?Modality_op=OR&Modality=SM.

Best,

Justin

[David Clunie]

The images from products (rather than ones I converted that are in IDC) from the most recent DICOM WG 26 Connectathon and their dciodvfy reports are available at "https://tinyurl.com/WG26SP2025Images", and numerous older images are available in the parent folder. See also discussion at "https://tinyurl.com/WG26SP2025Results".

[David Clunie]

Hi Salim

On Thursday, June 12, 2025 at 12:17:16 PM UTC-4 salim....@gmail.com wrote:

I'm reaching the community to better understand the DICOM standard specification for Whole Slide Images, this is after a discussion on Orthanc Implementation with Sebastien Jodogne (https://discourse.orthanc-server.org/t/bug-with-mirax-files-imagedvolumewidth-and-imagedvolumeheight-values-are-swapped/5912/1)

The DICOM WSI has a change of orientation compared to the Slide coordinate, so X orientation in slide coordinate is in the image rows direction and Y slide coordinate is in column image direction.

There might or might not be - there is no requirement for a scanned image of a slide to be in a particular orientation - that is why there is an attribute ImageOrientationSlide to describe what the orientation is relative to the slide coordinate system, and the creator of the image (slide scanner or converter from proprietary format to DICOM) is supposed to populate that correctly.

With Sebastien we have a difference of understanding for the imagedVolumeWidth and imagedVolumeHeight meaning.

Those tags are giving the physical size of the slide.

Is these value related to the physical width/height following the orientation of the generated image or the width/height following the orientation of the slide ? 

My understanding is that ImagedVolumeWidth and ImagedVolumeHeight describe the physical extent of the encoded total pixel matrix array (even though it is tiled) and correspond to the values in TotalPixelMatrixColumns and TotalPixelMatrixRows, respectively. I.e., they describe the image, not the slide (i.e., not the image volume in the frame of reference) . It may not be very clear from the attribute descriptions (or in http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.12.4.html#sect_C.8.12.4.1.2). That is certainly how I have always implemented it and AFAIK most (if not all) of the scanner vendors do it that way (vide infra).

We want in the viewer compute the physical size of a pixel, so

- If those tag are based on the resulting image the physical size the pixel size calculation will be : 

x spacing = imagedVolumeWidth / number of columns

y spacing = imagedVolumeHeight / number of rows

- If those tag are related to the slide orientation the computation will be

x spacing = imagedVolumeWidth / number of rows

y spacing = imagedVolumeHeight / number of columns

The X and Y (spacing between columns and rows, respectively) values are explicitly described for each image layer in SharedFunctionalGroupsSequence > PixelMeasuresSequence > PixelSpacing (http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.16.2.html#sect_C.7.6.16.2.1), noting that the row spacing is the first value. WSI image pixels are normally square. I suggest that you should always use the specified PixelSpacing values for any viewer logic that requires knowledge of the pixel spacing, not something computed from ImagedVolumeWidth and ImagedVolumeHeight.

Attempting to compute the pixel spacing from the ImagedVolumeWidth and ImagedVolumeHeight might not provide a precise result because the specified extent may not be actually encoded in the pixel data (theoretically).

To explore what scanners and converters actually do, I have added a check in dciodvfy to today's build (http://www.dclunie.com/dicom3tools/workinprogress/dicom3tools_1.00.snapshot.20250715101647.tar.bz2) to warn if the computed values of ImagedVolumeWidth and ImagedVolumeHeight derived from TotalPixelMatrixColumns and TotalPixelMatrixRows and PixelSpacing do not match the encoded values. Running it on the samples from the recent DICOM WG 26 Connectathon (http://tinyurl.com/WG26SP2025Images) shows that many but not all values are as expected, and some are difficult to explain (others seem to be incorrect units of microns vs. mm perhaps). I don't see any that are inconsistent that appear to be "swapping" the width and height as was suggested, but then again, I have not checked the ImageOrientationSlide values to see if they are consistent with the Slide Coordinates Frame of Reference ("http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.12.2.html") and if there is any transformation between the physical microscopy "slide" height and width vs. the encoded total pixel matrix.

David

PS. wrt. the thread at "http://discourse.orthanc-server.org/t/bug-with-mirax-files-imagedvolumewidth-and-imagedvolumeheight-values-are-swapped/5912":

- DO NOT use Sup 145 as a reference - use the current standard, which includes many subsequent CPs - e.g., start from "https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.32.8.html"

- some of the explanatory material from Sup 145 has been updated and augmented and lives at "http://dicom.nema.org/dicom/dicomwsi/"

- if you have questions about a particular scanner vendor's implementation of DICOM, then contact that vendor's DICOM WG 26 member, e.g., if you don't think their population of ImageOrientationSlide or ImagedVolumeWidth and ImagedVolumeHeight or other attributes is "correct" wrt. you understanding of the standard

[Salim Kanoun]

Dear David, 

Thank you so much for this wise explanation, that is pretty clear !

Best regards,

Salim