-
Notifications
You must be signed in to change notification settings - Fork 439
fix: restrict labelmap to surface conversion #2426
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
base: main
Are you sure you want to change the base?
fix: restrict labelmap to surface conversion #2426
Conversation
|
I tested this PR elaborating on the instructions provided (thank you for such detail). In summary I locally linked the OHIF master branch with the branch (Devu-trenser:fix/labelmap-to-surface-conversion) with the fix and I found that labelmaps failed to convert to surfaces when switching from MPR to 3D four up. That is to say the third step in the instructions failed. Here are the specific steps I was using to test this PR...
Unfortunately the testing failed on step 7 with the following exception(s) and failure to create a surface representation... Note that I tried the exact steps above using the commit prior to the one for this PR and there was no exception at step 7. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing failed.
|
@jbocce I have verified the behavior again using both the latest OHIF Following the exact steps mentioned in your comment, I was unable to reproduce the issue and the labelmap to surface conversion worked as expected without any exceptions. A reference video demonstrating the test workflow and results has been attached for your review. Could you please confirm if you’re still able to reproduce this issue, or if I might be missing any specific steps in your testing process? With latest OHIF OSS.main.branch.mp4With OHIF branch OSS.fix.branch.mp4 |
|
@Devu-trenser, apologies, I am not sure what is wrong with my local system so I had a colleague go through my testing steps and it passed for them. Now I will look more closely at the code. |
packages/tools/src/utilities/segmentation/computeAndAddRepresentation.ts
Outdated
Show resolved
Hide resolved
packages/tools/src/utilities/segmentation/computeAndAddRepresentation.ts
Show resolved
Hide resolved
6bd1709 to
26e53b0
Compare
| * @param options - Additional options for computing the representation. | ||
| * @param type - Representation type (e.g., LABELMAP, CONTOUR). | ||
| * @param computeFunction - Async function that computes representation data. | ||
| * @param updateFunction - Optional function to update UI/state on segmentation change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove this param from the doc too please
| ): (segmentationId: string) => Promise<void> { | ||
| const polySeg = getPolySeg(); | ||
| return (segmentationId: string) => | ||
| polySeg.updateSurfaceData(segmentationId, { viewport }).then(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need the .then() here?
| const viewportId = display.render(viewport, representation); | ||
| viewportRenderList.push(viewportId); | ||
| display.render(viewport, representation).then(() => { | ||
| if (!existingRepresentation) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit curious for me. From what I can see the display.render also does a addDefaultSegmentationListener via a call to computeAndAddRepresentation. So why do we need this as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach looks good to me. Just a few comments and questions to address. I tested the implementation and it looks great.
Context
Fixes issue:
This merge request refactors the segmentation representation computation and event subscription system.
Changes & Results
This merge request refactors the segmentation representation computation and event subscription system. The goal of this refactor is to:
Testing
Devu-trenser:fix/restrict-labelmap-to-surface-conversionbranch with the branch (Devu-trenser:fix/labelmap-to-surface-conversion)Checklist
PR
semantic-release format and guidelines.
Code
etc.)
Public Documentation Updates
additions or removals.
Tested Environment