Auto flipping of disoriented Mammography images on stack viewport

[Adithyan-Dinesh-Trenser]

Context

The feature is designed to flip the images in the stack viewport, which are initially stored in a flipped orientation. The images are flipped upon loading and when the viewport is reset. It relies on ImageOrientationPatient or PatientOrientation, and ImageLaterality or FrameLaterality to identify the necessary flipping. Primarily, this feature is aimed at MG images that are stored in an incorrect orientation. It is capable of correcting images through vertical and/or horizontal flips, but it does not handle images requiring rotation for correction.

Changes & Results

The activation of the feature is handled through CustomizationService. A function that accepts the metadata instance and returns whether auto-flipping is needed or not is provided in the CustomizationService.

A sample customization

function getCustomizationModule() {
	return [
		{
			name: 'default',
			value: [
				{ id: 'orientationCorrectionCriterion', criteria: isOrientationCorrectionNeeded }
			]
		}
	]
}

A demo recording of the feature

Auto-flipping-OHIF-upstream-demo.mp4

Testing

Checklist

PR

• My Pull Request title is descriptive, accurate and follows the
  semantic-release format and guidelines.

Code

• My code has been well-documented (function documentation, inline comments,
  etc.)

Public Documentation Updates

• The documentation page has been updated as necessary for any public API
  additions or removals.

Tested Environment

• OS: Windows 11 Pro
• Node version: 18.17.0
• Browser: Chrome 127.0.6533.120 (Official Build) (64-bit)

[netlify]

✅ Deploy Preview for ohif-platform-docs ready!

Name	Link
🔨 Latest commit	7763d5b
🔍 Latest deploy log	https://app.netlify.com/sites/ohif-platform-docs/deploys/66fe9447c982330008cfda32
😎 Deploy Preview	https://deploy-preview-4353--ohif-platform-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[netlify]

✅ Deploy Preview for ohif-dev ready!

Name	Link
🔨 Latest commit	7763d5b
🔍 Latest deploy log	https://app.netlify.com/sites/ohif-dev/deploys/66fe9447994f6a00090a8afe
😎 Deploy Preview	https://deploy-preview-4353--ohif-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[Adithyan-Dinesh-Trenser]

Cc : @Ouwen

[Ouwen]

@sedghi let us know if there are changes needed to this PR. @Adithyan-Dinesh-Trenser i would rebase to master in the meantime

[sedghi]

CC'ing @wayfarer3130 since he has worked on a lot of MG hanging protocols recently

[wayfarer3130]

This doesn't really belong here - this is adding specific behaviour for certain types of images in certain cases. I would suggest adding it to the split/sort rules as part of generating the splitting criteria, and add it into the series level splitting for MG type series that have this issue. Then, the hanging protocol rules can choose to pickup those values for the orientation/position. That is a much more generic approach, and doesn't cause the viewport service to have deep knowledge about how to handle orientation changes.
You could also create a custom orientation/position metadata module as an alternative, and use that module in CS3D as the initial flip setup if it isn't currently set, but if so you need to change the viewport handling so that a viewport with flipHorizontal/flipVertical/initial rotation works correctly when you flip the viewport - that is, flipping the viewport should flip the images FROM the original location.

[wayfarer3130]

In fact I think this should also be calculated in the hanging protocol service because the same orientation isn't always shown for hanging protocols, and those should still work correctly - that is, left on right or right on left should both be supported by the hanging protocol, and NOT the viewport. Even if you create a default rule and add it into the default hanging protocol, I think doing it there is a better choice, although getting default values in the split/sort rules to apply at hte series level makes that easy to apply in the hanging protocol.

[wayfarer3130]

What you should do is compute the desired default initial flip state in the display set object, and export it as a metadata instance and apply it here when it is set for the image id/display set uid. It should be applied as the base data, and then rotation/flip etc on TOP of that applies relative to the base rotation etc. That change could actually go into the CS3D library in the stack/volume viewports, or it can be done here as an integrated value. That way, the image "flip" isn't shown by default unless the flip is changed relative to the base flip/rotate state. That is a robust way to specify the values correctly.

[sedghi]

@wayfarer3130
So what is the decision on this? Do we need it in OHIF upstream?