Frame-specific information in DICOM file instance

[fhnaumann]

I am using the Orthanc Dicomizer tool and I want to try out this tool.
Dicomizer uses two specific tags to store the relative position of each frame/tile:

The tag “Column Position In Total Image Pixel Matrix” (0x0048,0x021e) contains the x-position of one frame, and “Row Position In Total Image Pixel Matrix” (0x0048,0x021f) its y-position. This information is collected for each frame of the DICOM instance inside the tag “Per Frame Functional Groups Sequence” (0x5200,0x9230).

I'm wondering how this is done here. It clearly works, as I'm able to view the generated DICOM files in the Orthanc WSI viewer, I just don't know how it's stored in the DICOM tags.
And before head diving into the source code I figured I could maybe ask beforehand incase someone knows it.

[fhnaumann]

Inside dataset.py in the wsidicom project there's a frame_sequence method which checks for the PerFrameFunctionalGroupsSequence tag, but it is never present in converted files and therefore it returns the SharedFunctionalGroupsSequence tag.

    def frame_sequence(self) -> DicomSequence:
        """Return per frame functional group sequene if present, otherwise
        shared functional group sequence.

        Returns
        ----------
        DicomSequence
            Per frame or shared functional group sequence.
        """
        if "PerFrameFunctionalGroupsSequence" in self and (
            "PlanePositionSlideSequence" in self.PerFrameFunctionalGroupsSequence[0]
        ):
            return self.PerFrameFunctionalGroupsSequence
        elif "SharedFunctionalGroupsSequence" in self:
            return self.SharedFunctionalGroupsSequence
        return DicomSequence([])

Now I don't know yet where these tags are populated when using the convert function.

The Orthanc WSI viewer is able to load the tiles because DICOMweb allows for retrieval of frames on an instance with {s}/studies/{study}/series/{series}/instances/{instance}/frames/{frames}. However internally the DICOMweb protocol also has to look at specific tags to figure it out?

[erikogabrielsson]

Hi @wand555
There are two types of tiling types possible for DICOM WSI: TILED_SPARSE and TILED_FULL, given by the Dimension Organization Type Attribute. For TILED_SPARSE, each (non-sparse) tile in the file should have an entry in the Per-Frame functional group sequence stating the position, optical path, etc. of the tile. For TILED_FULL this is not needed, as all tiles for the the whole image (as given by the Total Pixel Matrix Columns/Rows, optical paths, focal planes) arepresent and should be ordered by column, row, focal plane, optical path.

TILED_SPARSE has the advantage of possible space saving, but the Per-frame functional group sequence can become very long (especially the combination of small tile size and large image/multiple paths/focal planes) and is inefficient to parse, resulting in long loading times (seconds or tens of seconds). I dont know a way around this keeping within the standard.

TILED_FULL is on the other hand both easier to write and faster to read. WsiDicomizer (or rather WsiDicom) therefore only writes TILED_FULL. For reading both tiling types are supported.

[fhnaumann]

Thanks a lot for your response.
I looked into the DICOM WSI definition and reaffirmed what you said:

Each frame is located by three spatial coordinates relative to the WSI: X and Y offsets (by convention, the upper left corner pixel is {1,1}, and X increases down the image to the bottom, while Y ascends across the image to the right), and Z - which indicates the plane in which the image belongs.