jcfr
(Jean Christophe Fillion Robin (Kitware))
September 21, 2020, 6:34pm
1
Tomorrow, we will be having our next weekly hangout at 10:00 AM ET until 11 AM ET.
Anyone is welcome to join to ask questions at https://bit.ly/slicer-googlemeet-hosted-by-kitware
Agenda (10:00 - 10:30):
Slicer 5 + VTK 9 checkin
Discuss the creation of a standalone project to maintain Slicer Volume Rendering presets. More details below. (cc: @forrest.li @Sankhesh_Jhaveri )
Agenda (10:30 - 11:00):
We will be brainstorming ideas for what a fully virtual January project week could look like.
Feel free to post to this thread to request/suggest a topic!
Thanks
Sam and J-Christophe
Standalone project for organizing volume rendering presets
Goal : Streamline maintenance and distribution of the presets to facilitate (1) re-use and (2) integration of improvements.
Proposed approach
Create a repository called Slicer/SlicerVTKVolumeRenderingTransferFunctions
distributed (for example) as:
git submodule, cmake external project (e.g faciliate integraiton in any project)
python package (e.g support re-use in Jupyter env.)
npm package (e.g to streamline integration in vtk.js )
VTK remote module (e.g to streamline interation in VTK or paraview based applications)
Open questions
Which distribution mechanism should we implement first ?
Requirements
Add versioning, changelog, contributing, license and documentation
Add thumbnail for each preset
Distribute as both XML and json files
lassoan
(Andras Lasso)
September 21, 2020, 7:53pm
2
Sounds good. Volume rendering presets are not just about transfer functions but also shading, material properties, mode (composite, minimum intensity projection, maximum intensity projection), jittering, shader properties, etc. So, the name should be more general, something like SlicerVTKVolumeRenderingPresets
.
Instead of reinventing yet another custom file format, it would be nicer if we could build on an existing one. For example, we could define custom glTF extension for storing volume rendering presets.
Minor detail, but probably it will be better to focus on a single format and do it well.
pieper
(Steve Pieper (Isomics, Inc.))
September 21, 2020, 8:05pm
3
We could be inspired by the material property definitions and extensions in glTF:
On a related topic, we should look at how to standardize encoding of metatdata in glTF.
It would also be great to investigate volumes in glTF, but the standard states:
Implementation Note glTF 2.0 supports only 2D textures.
lassoan
(Andras Lasso)
September 21, 2020, 8:33pm
4
It would be nice if 3D volumes were standard glTF but it is not a big issue if we need to define custom extensions for volume storage.
pieper
(Steve Pieper (Isomics, Inc.))
September 21, 2020, 8:35pm
5
Yes, we’ll need custom extensions for our metadata anyway.
Sam_Horvath
(Sam Horvath (Kitware))
September 22, 2020, 1:40pm
6
I’d like to also look at the launchProcess crash: https://github.com/Slicer/Slicer/issues/5078
jcfr
(Jean Christophe Fillion Robin (Kitware))
September 28, 2020, 6:24pm
7
1 Like