Open manzt opened 7 months ago
It is not clear how to implement lazy loading for local 4D data since I believe this relies on HTTP range requests.
Visualization
@kolibril13 please have a look closely at this. Note how infrequently addVolume/addMesh are called in real world examples compared to loadVolumes/loadMeshes.
I think adding all the volumes/meshes should be the priority, the other "add" APIs can be added later (as an optimization, as i mentioned above).
Great progress! I like your systematic approach, these charts give a good overview of the project! I was thinking that the next todos could be to investigate this example and adding
to class Volume(ipywidgets.Widget)
https://niivue.github.io/niivue/features/additive.voxels.html
var volumeList1 = [
{ url: "../images/mni152.nii.gz" },
{
url: "../images/narps-4965_9U7M-hypo1_unthresh.nii.gz",
colormap: "red",
cal_min: 2,
cal_max: 4,
},
{
url: "../images/narps-4735_50GV-hypo1_unthresh.nii.gz",
colormap: "green",
cal_min: 2,
cal_max: 4,
},
];
It is not clear how to implement lazy loading for local 4D data since I believe this relies on HTTP range requests.
@manzt , niivue does support loading specific volumes from 4D data using loadFromFile
. It's just controlled by the limitFrames4D
property.
However, this only works for NIFTI files (when the code detects). If not NIFTI, then the entire data range is loaded
However, i'm not sure if loadFromFile
is used in the jupyter notebook implementation. Are files served via a local python server, or is data communicated by other means?
Volumes are serialized to binary data and send in one shot to the front end (over a websocket). We are using the new NVImage(arrayBuffer, ...)
API with the array buffer from the iamge.
Ok, I've been trying to go through the examples listed in niivue/ipyniivue#50 to understand the usage of APIs exposed by Niivue.
For the time being, our priorities are motivated by basic multi-planar, envisioning a Pythonic API for this:
Additionally, updating properties on the images should happen through getters/setters for the properties on the created volumes (rather than inconsistent
nv.setColormap(volumeId, ...)
ornv.setOpacity(index, ...)
. For the viewer rendered above should update with:This primarily focuses on Volume for now, but we will do a similar audit of features necessary for Meshes. The following are the TODOs:
Volumes
opts
traitlet for all options (can later add methods to updateopts
specifically in Python) niivue/ipyniivue-experimental#4load_volumes
with_volumes
traitlet niivue/ipyniivue-experimental#4nv.volumes[idx]
reactive foropacity
,colormap
, ~visible
~ niivue/ipyniivue-experimental#4More reactive APIs like
add_volume
can be added on top of this infrastructure, but complicate implementing the essential features.Meshes
Find a similar example to
basic multi-planar
and audit the necessary APIs.Observations
I took a look in the
demos/
directory and a very high-level summary of the APIs in use fromnv
instances:I would recommend making decisions about next steps based on the prevalence and usage of each of these APIs. In the context of Python, I don't know if many of them make sense and many are essentially aliases for
nv.opts.<property> = x
and re-rendering, which should be covered by anyopts
traitlet we have.