View in #ohif on Slack
@Veljo_Lasn: What is the “correct” way to directly access a StreamingImageVolume’s scalar data (or its vtkImageData object) nowadays?
Iirc. we used to be able to .getScalarData() but that seems to have changed since the introduction of voxelManagers.
I was able to get our logic to work temporarily by creating a new, intermediary vtkDataArray from the output of voxelManager.getCompleteScalarDataArray() but that feels like a workaround and is computationally expensive
@Alireza_Sedghi: getCompleteSclaarDataArray is the correct way
if you need the full thing
but there is a good chance that you can make it work with its methods such as getAtIndex and getAtIJK
@Veljo_Lasn: Ideally I’d prefer direct access to the full volume or scalar’s getPointData return value for some custom vtk-filter-based 3d crop and resampling ops
My usecase is piping an isotropically resampled subset of the volume’s voxel values into a different service
I’ll poke around voxelManager’s codebase a bit more tomorrow, perhaps we can contribute this as a small PR
@Alireza_Sedghi: I understand the usecase, you should create the vtkDataArray + getCompleteScalarDataArray as you said originally
@Veljo_Lasn: Alright, thanks!
Out of curiosity… In my experience, a common driver for creating abstractions like this is decoupling logic from vendor(vtk in this case)-specific impl. details and making space for alternative implementations, all while keeping the user(extension developer)-facing interfaces stable. Is there something along these lines being planned or already in the works?
@Alireza_Sedghi: It is that + our memory managements for stack and volume
https://cornerstonejs.org/docs/migration-guides/2x/core#new-pixeldata-model-and-voxelmanager
@cornerstonejs/core | Cornerstone.js
@Veljo_Lasn: Awesome, this document answers the majority of my questions!
As a sidenote, I found the new (new-to-me at least) localVolume and segmentation apis very nice to work with for rendering segmentations with different properties (spacing, bitdepth etc) than the acquisition/source image volume. We were previously using createDerivedVolume and doing a lot more work & allocating more memory than we needed to 