Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating proper values for ChangeType parameter in AnnotationModifiedEventDetail. #1821

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

nithin-trenser
Copy link

@nithin-trenser nithin-trenser commented Feb 12, 2025

Context

Updated ChangeType parameter value in AnnotationModifiedEventDetail for LengthTool

Changes & Results

The ChangeTypeparameter in AnnotationModifiedEventDetail now returns StatsUpdated following the execution of the _calculateCachedStats function, it returns HandlesUpdated when the handle position is modified.

The initialSetup change type can be fired from addNewAnnotation(), we currently left it out. Please let us know if you think it should be there as cs3d already has a annotation created event for it. Should we remove the change type InitialSetup ?

Testing

Checklist

PR

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

Code

Public Documentation Updates

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

Tested Environment

  • [] "OS:
  • [] "Node version:
  • [] "Browser:

Copy link

netlify bot commented Feb 12, 2025

Deploy Preview for cornerstone-3d-docs ready!

Name Link
🔨 Latest commit 40ffe9e
🔍 Latest deploy log https://app.netlify.com/sites/cornerstone-3d-docs/deploys/67bc38aa7150630008cdd2b7
😎 Deploy Preview https://deploy-preview-1821--cornerstone-3d-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

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

@sedghi
Copy link
Member

sedghi commented Feb 12, 2025

I think this look ok, wdyt @wayfarer3130

@@ -685,7 +685,7 @@ class PlanarFreehandROITool extends ContourSegmentationBaseTool {
const { data } = annotation;
if (
!data.cachedStats[targetId] ||
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about !data.cachedStates[targetId]?.areaUnit
The areaUnit should be a non empty string, even for unknown units as that will be pixels

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems there is an existing issue that calculateCachedStats is always called for each mouse movement of open freenad annotation. This is due to the areaUnit for open freehand ROIs in cachedStates is always undefined.

As this condition is always true for Open freehand annotations, resulting in the unintended activation of an annotationModified event, we are restricting the second condition for closed freehand only.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we should probably check on unit rather than areaUnit, and always make sure we specify unit in it - that should be available for both closed and open contours. I believe it is not currently set for open contours, but it should be.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be an equivalent check for open contours, and I'd really rather have a single check that works for both.

@@ -81,6 +81,8 @@ type Annotation = {
[key: string]: unknown;
/** Cached Annotation statistics which is specific to the tool */
cachedStats?: Record<string, unknown>;
/** Label of an annotation */
label?: string;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is inconsistent with the label in LengthTool - label belongs to the data element. Note the difference between CS3D and OHIF - in CS3D the data is in the data object, while in OHIF it is at the top level.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The label is already defined inside the data element as you suggested.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, was seeing the nesting wrong. Could you move the handles to it's own type - I think that is sufficiently long to be worth having by itself. That would resolve the issue with having it hard to see the nesting.

@wayfarer3130
Copy link
Collaborator

The initial creation should leave the label changed event out

@nithin-trenser
Copy link
Author

The initial creation should leave the label changed event out

At present, the label change event is not triggered upon the creation of an annotation. We will trigger this event from the OHIF side when an annotation label is added or modified.

Copy link
Member

@sedghi sedghi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine, let's see what @wayfarer3130 thinks

Copy link
Collaborator

@wayfarer3130 wayfarer3130 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks good - just two changes:

  1. Can you ensure that open and closed contours both define unit?
  2. Change the planar freehand roi to use unit instead of areaUnit so that both open and closed contours correctly detect not initialized
  3. Move the handles into it's own type definition so that it is obvious what belongs with what parts. Or, at a minimum, define all the short items above handles so that when the handles ends, it also ends the data element. But, I'd really like a separate type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants