feat: Cornerstone3D 2.0 #1400
feat: Cornerstone3D 2.0 #1400
Conversation
❌ Deploy Preview for cornerstone-3d-docs failed. Why did it fail? →
|
| ); | ||
| await viewport.setStack([imageId], 0); | ||
| const viewport = renderingEngine.getViewport(viewportId); | ||
| await (viewport as Types.IStackViewport).setStack([imageId], 0); |
There was a problem hiding this comment.
Could you leave this as a generic viewport and call setDataIds instead? I think that would be more consistent across viewport types.
There was a problem hiding this comment.
I want the migration to be as minimal as possible. I understand it will be consistent, but perhaps this could be implemented in Cornerstone3D 3.0?
|
For the image volume, the access to that data is pretty low level, assuming that the internal organization of the pixel data is exactly a typed array and that there may or may not be slices associated with it. That causes us memory issues as we try to allocate larger buffers, and also forces us to share the image slice data in order to not need to copy the data all the time. If we could start having a better interface on top of the ImageVolume and other image data objects to hide some of the internal details, it would eventually allow us to use a single representation consistently. The VoxelManager is designed to be an abstraction on top of different types of views of both single and multiple images. Given that we don't get new versions of CS3D very often, starting to use the VoxelManager more consistently and perhaps deprecating the use of the full data object would be worthwhile. |
|
I came up with a big trick, it's a huge workload |
Read migration guides
https://www.cornerstonejs.org/docs/migration-guides/intro