You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since cornerstonejs has layer API support (cornerstonejs/cornerstone#68), the react-cornerstone-viewport could provide props support. This would allow for easy overlays of segmentation maps, heat maps, and other fusion based image information.
The current behaviour for react-cornsertone-viewport is to take in a list of imageIds as a stack and display some initial index.
Alternatively, the imageIds could by default be added to a single element layer with that layer being set active.
A potential barrier is that the cornerstoneTools stack stateManagement relies on imageIds. Not sure if this would be a big deal though since the cornerstone layer API uses underlying imageIds, and tools can be applied to just the the active layer. I was wondering what would happen if we just provided the list of imageIds from the active layer.
Happy to put together a PR, but wanted to feel out opinions on better API design or caveats.
The text was updated successfully, but these errors were encountered:
Ouwen
changed the title
Support for compositional layers
Proposal compositional layer support
Apr 11, 2021
Ouwen
changed the title
Proposal compositional layer support
Proposal for compositional layer support
Apr 11, 2021
Since cornerstonejs has layer API support (cornerstonejs/cornerstone#68), the react-cornerstone-viewport could provide props support. This would allow for easy overlays of segmentation maps, heat maps, and other fusion based image information.
The current behaviour for react-cornsertone-viewport is to take in a list of imageIds as a stack and display some initial index.
react-cornerstone-viewport/src/CornerstoneViewport/CornerstoneViewport.js
Lines 172 to 188 in 52703b9
However, it would be useful to take in
layers
as a prop wherelayers
can contain many imageIds, but ultimately they are fused together as with the composite image example: https://rawgit.com/cornerstonejs/cornerstone/master/example/layers/index.html.Alternatively, the imageIds could by default be added to a single element layer with that layer being set active.
A potential barrier is that the cornerstoneTools stack stateManagement relies on imageIds. Not sure if this would be a big deal though since the cornerstone layer API uses underlying imageIds, and tools can be applied to just the the active layer. I was wondering what would happen if we just provided the list of imageIds from the active layer.
Happy to put together a PR, but wanted to feel out opinions on better API design or caveats.
The text was updated successfully, but these errors were encountered: