Saving VolView state

[cjh1]

Requirements

• Should be able to write a state file that will contain all necessary data to recreate a session. This would include:
  • The loaded data
  • Camera positions
  • Transfer function selections
  • Select series or image
  • Annotations

Possible Approach

• Use store are primary mechanism to serialize and deserialize state. A lot of the state is already there, anything that is missing should be added.
• The vtk-js ProxyManager also contains state that will need to preserve.
• The state file would be a zip file containing a JSON manifest and the original data files.
• We will need to ensure that there is reliable mapping of file objects to data IDs

[floryst]

Some other considerations:

• DICOM File objects sent to the DICOM webworker will have issues will no longer be readable from the main thread.
• Will need to consider the case where the underlying files become invalid, and notify the user of such when reading.

[cjh1]

Yes, for the DICOM file object, we might want to add a call to allow us to get the data again, it should just be siting there in memory?

[floryst]

I was thinking about the DICOM data and state, and I think I have an approach that changes how we store raw DICOM files in such a way that we can save raw files in the state, and be able to load them back up as needed.

• DICOM DB on the main thread. We can persist the File objects in the main thread, and use those as the source of truth. Whenever we need to actually read them, we just call file.arrayBuffer(), which will create a copy of the file in arraybuffer form.
• itk-wasm is only used for sorting, tags, and building volumes. We pass itk-wasm array buffers instead of file objects. Having ArrayBuffers as Transferable means the copy is fast (at the expense of needing to read every time the file is converted from File to ArrayBuffer).
• We retain a mapping between the set of File objects used to construct a volume, and the volume ID. When loading a state, we first read and load each collection of files separately, and assign the saved volume ID to the output vtkImageData.

The above avoids the issue of having to somehow pull the DICOM files from out of the itk webworker side. Additionally, this will simplify the amount of code that resides on the itk-wasm side.

[cjh1]

This all sounds good to me. I like the idea of keeping the single source of truth on the main thread. Should we extend the approach to include non-dicom files, as in keep the original file objects for those as well?

[cjh1]

Would you like me to take a look at implementing these changes or is thing something you would like todo?

[floryst]

Yep, the idea would be to keep those around for all files, including ones originating from the network.

[floryst]

Would you like me to take a look at implementing these changes or is thing something you would like todo?

Let's sync on a call to figure out sub-tasks for this.