feat: Add command to load derived display sets #5381
Conversation
✅ Deploy Preview for ohif-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Viewers
|
||||||||||||||||||||||||||||
| Project |
Viewers
|
| Branch Review |
feat/load-derived-display-sets
|
| Run status |
|
| Run duration | 02m 45s |
| Commit |
|
| Committer | Igor Octaviano |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
Failures
|
0
|
Flaky
|
0
|
Pending
|
0
|
Skipped
|
0
|
Passing
|
37
|
| View all changes introduced in this branch ↗︎ | |
| const getDerivedSequences = (displaySetUID: string): DisplaySet[] => { | ||
| const currentDs = displaySetService.getDisplaySetByUID(displaySetUID); | ||
| const displaySetCache = displaySetService.getDisplaySetCache(); | ||
| return Array.from(displaySetCache.values()).filter( | ||
| (ds: any): ds is DisplaySet => | ||
| (ds?.referencedDisplaySetInstanceUID === displaySetUID || | ||
| ds.referencedSeriesInstanceUID === currentDs.SeriesInstanceUID) && | ||
| !ds?.isHydrated | ||
| ); | ||
| }; | ||
|
|
There was a problem hiding this comment.
I don't see any logic to check if this is derived. I think derived DS have isDerived on them or similar
| segmentationService.addSegmentationRepresentation(activeViewportId, { | ||
| segmentationId: displaySet.displaySetInstanceUID, | ||
| type: | ||
| displaySet.Modality === 'SEG' |
There was a problem hiding this comment.
we like to think about Segmentation as a general term that includes Contour, Labelmap or Meshes. And each of them are segmentation representation.
I think this function should be called loadAvailableLabelmapsForActiveViewport maybe?
There was a problem hiding this comment.
But is mesh a representation today? I thought it was just contour and labelmap. Surface generation occurs even without explicit requests, and the mesh is loaded through geometry calls (no mesh/STL code in ohif today).
I agree to changing the name. Maybe loadLabelmapsAndContoursForActiveViewport?
There was a problem hiding this comment.
@sedghi i'll need some input about this question above
| "extensions/cornerstone": { | ||
| "name": "@ohif/extension-cornerstone", | ||
| "version": "3.12.0-beta.18", | ||
| "version": "3.12.0-beta.23", |
There was a problem hiding this comment.
no sure why bun lock is changing but not yarn lock
There was a problem hiding this comment.
Are we using both? I find it very confusing that we use yarn and bun today. Maintaining two lock files seems error-prone.
There was a problem hiding this comment.
So yes we are currently maintaining both bun.lock and yarn.lock. I don't know why - it predates my current stint on OHIF.
In this case I'm not sure why the OHIF dependencies were updated. This sometimes occurs when someone branches off master prior to the Update package versions [skip ci] step running. In this particular case, I think simply updating from master again should remove this from the PR's list of changed files. If there is a conflict be sure to take the bun.lock file from master. Please merge from master again and see what happens.
In any case the changes I see here to the bun.lock file are benign.
Does this make sense (i.e. capisce?) 😜
Context
Changes & Results
Testing
Checklist
PR
semantic-release format and guidelines.
Code
etc.)
Public Documentation Updates
additions or removals.
Tested Environment