Fix: Jump to measurement from measurement panel after rotating viewport

[nithin-trenser]

Context

• Fix for [Bug] After the crosstools is rotated in the mpr view, the measurement panel will report an error when clicking to jump #4785
• This PR has been incorporated by FlyWheel.io.

Changes & Results

The issue was resolved by resetting the viewport to the plane where the measurement is located and highlighting it when a measurement is selected from the measurement panel.

jump-to-measurement-cross-hair.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:
• [] Node version:
• [] Browser:

[netlify]

✅ Deploy Preview for ohif-dev canceled.

Name	Link
🔨 Latest commit	5b8e058
🔍 Latest deploy log	https://app.netlify.com/projects/ohif-dev/deploys/69431704663f7900084095f8

[nithin-trenser]

@sedghi Could you please review and merge this PR?

[jbocce]

@nithin-trenser please update your branch and resolve the conflicts. Otherwise it looks good! Thanks for your contribution.

[jbocce]

@nithin-trenser, We are planning a code freeze at the end of this week. So please make updates soon to have this include in the release. Thanks for you contribution.

[nithin-trenser]

@jbocce Conflicts resolved and committed. Could you please re-review and approve?

[sedghi]

platform/app should not use cornerstoneViewportService

[nithin-trenser]

Upon revisiting the issue, it was observed that the implementation of jumpToMeasurement has changed. Therefore, the fix provided in this PR is no longer applicable. As the issue still persists in the latest version (3.12.0), further analysis will be conducted later to determine an appropriate solution.

[arul-trenser]

On further analysis found the below issues
Reproduction Steps

• Draw an annotation in the axial viewport.
• Enable the crosshair.
• Rotate the crosshair in the sagittal or coronal viewport.
• Click on the measurement.

Observed Behavior

1. A “Maximum call stack exceeded” error occurs.
2. After a short delay, the measurement appears active in both the previously active viewport and the axial viewport, both shown in axial orientation.

maxium_call_stack_error.mp4

Note
This works correctly in the following scenarios:

• When the active viewport has the same orientation as the measurement.
• When the crosshair is disabled

working-scenario-jump-mpr.mp4

Issue 1: Measurement jump occurs in the active viewport

Root Cause:
In findNavigationCompatibleViewportId, the viewport selection logic prioritizes viewports based on the following order:

1. Active viewport that can navigate to the image without orientation change
2. Other viewport that can navigate to the image without orientation change
3. Active viewport that can navigate to the image with orientation change
4. Other viewport that can navigate to the image with orientation change

When the viewport is rotated using the crosshair, navigation without orientation change is no longer possible. As a result, the logic falls back to selecting the active viewport that can change orientation, which is incorrectly chosen as the best fit.

Fix
Before evaluating viewports that require orientation changes, all viewports are first sorted by least orientation difference using a computed view-plane alignment score. Navigation with orientation change is then evaluated in this order, ensuring the most suitable viewport is selected.

Issue 2: Maximum call stack exceeded error when crosshair is enabled

Root Cause
After selecting the target viewport, navigation to the measurement triggers setViewReference, which calls setOrientation.
This leads to the following call sequence:

• setOrientation → applyViewOrientation
• applyViewOrientation → resetCamera({ resetOrientation: false, resetRotation: false })
• resetCamera triggers CAMERA_RESET
• CAMERA_RESET resets crosshairs
• Crosshair reset triggers another camera reset with resetRotation: true

After applying the orientation, setViewReference continues under the assumption that the viewport is aligned with the measurement’s orientation. However, the repeated camera resets triggered by the crosshair revert the orientation. This causes setViewReference to continuously reapply the orientation, resulting in an infinite loop and eventually a maximum call stack exceeded error.

Fix
Suppress camera reset events during setOrientation to prevent recursive camera and crosshair resets.

I have:

Created a PR in CS3D cornerstonejs/cornerstone3D#2519 to fix the maximum call stack exceeded issue.
Updated this PR to address the viewport selection logic for measurement navigation.

@sedghi Could you please review both this PR and the corresponding CS3D PR?

[wayfarer3130]

@wayfarer3130 is reviewing these changes, will check and then merge if it looks good. I was noticing this hang as well, so I'm glad to have this in for the next release.

[wayfarer3130]

Two relatively small changes - extract the sort by closest orientation viewport logic so it can be re-used in #5630 and use the planeRestriction instead of the view plane normal, as the planeRestriction object inside the metadata is more consistently created. Note you may have the second inPlaneVector absent (or even both of them).
The logic is
alignmentScore = Math.abs(vec3.dot(inPlaneVector1,viewPlaneNormal) + Math.abs(vec3.dot(inPlaneVector2,viewPlaneNormal))
where the two dot products default to 0 when the in plane vector is absent.