[DAR-5370][External] Axially-agnostic pixdim scaling on import for medical files that require it

[JBWilkie]

Problem

Annotations outside the platform are represented in "pixel space". This is a measurement independent of real-world distance where 1 pixel maps to 1 pixel. Most annotations in-platform are also represented in pixel space, except those created on post-MED_2D_VIEWER medical files. Why?

These files are represented on a stretched workview canvas in "mm space". This means instead of measuring annotation coordinates in terms of pixel values, they are represented in millimetres

Given a pixdim mapping, you can transform coordinates between pixel space and mm space. pixdim is an n-dimensional array that represents how many millimetres are represented by a single pixel for each axis. For example, pixdim = [0.5, 0.25, 1] means:

• Each pixel in the x axis represents 0.5 mm of physical distance
• Each pixel in the y axis represents 0.25 mm of physical distance
• Each pixel in the z axis represents 1 mm of physical distance

Then:

• To transform from pixel space to mm space: Multiply each x and y coordinate by the pixdim value aligned with the appropriate axis
• To transform from mm space to pixel space: Divide each x and y coordinate by the pixdim value aligned with the appropriate axis

Why is this a problem? Importing and exporting. Given that when importing and exporting non-NifTI annotations, we do not perform any scaling under any circumstance, consider the following 2 scenarios:

• 1: Annotations are created in mm space in the platform and then exported. For pixdim values other than 1, the coordinates of the exported annotations will not match the pixel space of the originally uploaded file
• 2: A client prepares annotations out of the platform in pixel space for some medical files. They then upload medical files & their corresponding annotations. For pixdim values other than 1, they will not be aligned with the canvas's mm space expectations

Problem 1 is being addressed in DAR-5339 and will be released to backend at the same time this ticket is. It will apply a mm space to pixel space transformation for all non-NifTI mm space annotations upon export

Problem 2 is addressed by this PR

Solution

This PR introduces scaling of non-NifTI annotations upon import as follows:

• 1: Get a list of remote files targeted by the import by parsing the local annotation files
• 2: Determine which, if any, of the files in the above list either:
  • a: Require us to apply our legacy NifTI scaling method if importing NifTI annotations. These are medical files that have been uploaded with the MED_2D_VIEWER feature flag disabled (not monai handler)
  • b: Require a transformation of their annotation coordinates from pixel space to mm space. These are medical files that have been uploaded with the MED_2D_VIEWER feature flag enabled (monai handler)
• 3: We then pass the list from 2b into a function that multiplies the coordinates of every annotation according to the correct pixdim values associated with the axis of acquisition of the target remote file

NifTI annotations are not considered because the NifTI importer already performs pixdim scaling, so we don't want to apply it twice

Note that 2a is a re-write of a previously existing feature. We did this re-write to reduce the load it was exerting on our list /items API. Previously, it would list every file in the dataset and then filter. Now, it polls /items only for the files that are targeted by the import

Changelog

Introduced automatic transformation from pixel space to mm space when importing annotations to medical files that require it. i.e. those that have been processed with MED_2D_VIEWER

[linear]

DAR-5370 `pixdim` scaling not being applied at import time