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
For the volume image slice we currently do the interpolation in the shader. For arbitrary planes we probably want to do it on the CPU side (or just disable?).
The answer this depends on whether we think significant computation will be necessary for the slice generation that benefits from it being in the shader.
for simple slices you can get away with doing this on the CPU
for slices generated by projecting data normal to the slice you may benefit from the GPU
The need for projection to be part of the slicing mechanism enables
overcoming SNR constraints in individual slices
visualising larger volume regions on the slice whilst maintaining the defined 3D->2D mouse->plane intersection for interaction
I don't know that doing this in the shader is strictly necessary for real-time performance, I just know that my implementation in the shader in napari is significantly faster than the CPU implementation of the same behaviour in dynamo_tomoslice, a viewer based on similar principles.
@arose also mentioned that for controlling the position/orientation of this plane we need a dedicated ParameterControl - I don't yet fully understand what this is but it looks like it's implemented here
We can obtain the grid cell of the original volume when mouse over a slice pixel which should give us the data to build a UI and storage for it.
I think it's important that this intersection be available in continuous coordinates rather than giving the center of the nearest grid cell - sometimes pixel sizes get larger than ideal with the data I work with and we are doing lots of things on this data which require subpixel precision
The text was updated successfully, but these errors were encountered:
This is a high value feature for volume visualisation identified in #1086
@arose said in #1086
The answer this depends on whether we think significant computation will be necessary for the slice generation that benefits from it being in the shader.
The need for projection to be part of the slicing mechanism enables
I don't know that doing this in the shader is strictly necessary for real-time performance, I just know that my implementation in the shader in napari is significantly faster than the CPU implementation of the same behaviour in dynamo_tomoslice, a viewer based on similar principles.
My shader implementation can be found here
https://github.com/vispy/vispy/blob/9b0f58907b151a1114fce708212ced59ddb7c1cc/vispy/visuals/volume.py#L326-L363
Looking at the direct volume fragment shader it should be relatively quick to get the same logic going using this shader if we agree on that strategy
molstar/src/mol-gl/shader/direct-volume.frag.ts
Lines 8 to 364 in 10a3f92
@arose also mentioned that for controlling the position/orientation of this plane we need a dedicated
ParameterControl
- I don't yet fully understand what this is but it looks like it's implemented heremolstar/src/mol-plugin-ui/controls/parameters.tsx
Line 43 in 10a3f92
It is important that we can obtain the intersection of the mouse with these planes to enable annotation tools which work on the plane
@arose said in #1086
I think it's important that this intersection be available in continuous coordinates rather than giving the center of the nearest grid cell - sometimes pixel sizes get larger than ideal with the data I work with and we are doing lots of things on this data which require subpixel precision
The text was updated successfully, but these errors were encountered: