Dicomizer pixel spacing?

[Jack Daniels]

I was wondering if someone can help with figuring out the pixel spacing caclulations performed by the WSI Dicomizer. 

I have a TIF-file that I want to convert to DCM using the command line arguments (more omitted):

"OrthancWsiDicomizer.exe" --imaged-width 4.1664 --imaged-height 4.7616 

After the DCM-files are create, I run dcmdump and the file contains:

(0048,0001) FL 4.1664                                   #   4, 1 ImagedVolumeWidth

(0048,0002) FL 4.7616                                   #   4, 1 ImagedVolumeHeight

(0048,0003) FL 0.001                                    #   4, 1 ImagedVolumeDepth

(0048,0006) UL 10240                                    #   4, 1 TotalPixelMatrixColumns

(0048,0007) UL 8960                                     #   4, 1 TotalPixelMatrixRows

(0048,0008) SQ (Sequence with explicit length #=1)      #  44, 1 TotalPixelMatrixOriginSequence

...

(0028,0030) DS [0.00046499999\0.00046499999]            #  28, 2 PixelSpacing

Note, the TotalPixelMatrixColumns and TotalPixelMatrixOriginSequence values are pulled from the TIFF file by the dicomizer (these values are correct, the image is more wide than tall).

I can't figure out the calculated pixel spacing values. The standard says (emphasis added):

10.7.1.3 Pixel Spacing Value Order and Valid Values

All pixel spacing related Attributes are encoded as the physical distance between the centers of each two-dimensional pixel, specified by two numeric values.

The first value is the row spacing in mm, that is the spacing between the centers of adjacent rows, or vertical spacing.

The second value is the column spacing in mm, that is the spacing between the centers of adjacent columns, or horizontal spacing.

That would mean (0048,0008) should be ( 4.7616/8960 \ 4.1664/10240) which is (0.0005314/0.0004068). The pixel spacing values in the DCM file seem to be computed from ImageWidth/PixelRows and ImageHeight/PixelColumns.

Does this have something to do with the Supplement 145 explanation of the image orientation being rotated by 90 degrees relative to the slide coordinate system or is the dicomizer program incorrect?

Thank you very much,

Jack

[Sébastien Jodogne]

Hello,

Here is an image from my talks that depicts the system of coordinates used in Supplement 145:

This image is derived from the "WSI Frame of Reference" section of the standard:

http://dicom.nema.org/Dicom/DICOMWSI/

Following this image, the X/Y physical axes are indeed rotated by 90° wrt. the X/Y image matrix axes.

As a consequence, in your example, Orthanc sets the PixelSpacing to "(4.7616 / 10240) = 0.000465" by "(4.1664 / 8960) = 0.000465".

For reference, the pixel spacing is computed at the following location of the source code:

https://bitbucket.org/sjodogne/orthanc-wsi/src/OrthancWSI-0.5/Applications/Dicomizer.cpp#lines-354

HTH,

Sébastien-

[Jack Daniels]

Hi Sebastian,

Thank you very much for responding to my question. While I understand the explanatory drawings, switching the Volume/Pixel values seems to contradict the Image Orientation (Slide) (0048, 0102) item defining the orientation of the pixel matrix relative to the slide orientation. Wouldn't it be correct to interpret suppl 145 to keep pixel spacing / ImagedVolume /  PixelMatrix to be consistent in the image context (ie, no dimension switching when calculating pixel spacing) and the actual orientation on the slide being defined by the direction cosine (which may/may not/ rotate the image matrix by 90 degrees and 'switch' rows and columns or scan width and height)?

Thank you very much,

Jack

[Sébastien Jodogne]

Dear Jack,

My own interpretation of Supplement 145 has led to this implementation, so I can't provide more details.

Please get discuss this issue with the DICOM committee on the dedicated mailing list:

https://groups.google.com/forum/#!forum/comp.protocols.dicom

If the Orthanc implementation is wrong, I'll happily patch it.

Regards,

Sébastien-