VTKjs: Compressing Textures?

banesullivan · April 10, 2019, 4:12pm

I’m curious if there is a way to further compress textures associated with actors when using the ParaView VTKjs export script found here. Please note that I have heavily modified this script for exporting vtki rendering windows here.

Whenever I export a scene that has a texture, the texture takes up quite a bit of memory and causes the scene to load very slowly in the standalone viewer.

I have some really awesome visualizations I’m trying to share online (see link below) with VTKjs and I’m currently limited to not using the textures because they take far too long to load/take up too much memory in the scene file for websharing.

http://forge-3.pvgeo.org

This same scene has a texture for the topography surface that makes a big difference:

I’ve tried downgrading the resolution of the PNG files I’m using to have a size of about 6.6 MB but the VTKjs scene file has a size of ~144 MB (note that all other data in the scene accounts for ~6-10MB - that’s the size of the scene file with no texture) which means the 6.6 MB PNG file loaded as a texture accounts for ~135 MB in the VTKjs scene file - what’s happening here?

Sebastien_Jourdain · April 10, 2019, 6:14pm

The textures are converted as vtkImageData and only compressed via the zip bundling. It would be nicer to keep them as jpeg in the zip when possible. And then the loader will just have to manage true image in the vtkjs rather than only expecting vtk datasets.

banesullivan · April 10, 2019, 6:16pm

Would this be an appropriate feature request/issue for the VTKjs repository?

Sebastien_Jourdain · April 10, 2019, 6:21pm

Sure, but ParaView 5.7 has a new native vtkjs export. This could be a an improvement to encode textures as jpeg and handle them at load time.
Also I think the vtkjs format that pv natively support now is a bit more advanced than what the default viewer can handle while ParaViewGlance will be just fine with it.

Such feature will be too close to the release to make the final 5.7 cut, so the macro can still be an option but would need some cleanup to start leveraging the new code and capability.