Tif stack exporter (raw data and overlay data)

[jmrk84]

• Export current raw super cube to tif stack
• Export current overlay super cube to tif stack: Allow the export of only the currently selected object (anything else as 0) or all objects in the super cube

Use numpy and PIL for tif export

[unidesigner]

It would be nice to export a Tiff stack for a whole volume in Knossos? Such as this one: https://segem.rzg.mpg.de/webdav/datasets/ek0563/

[orenshatz]

Hi Stephan. Yes, it would be nice. The problem is, at the moment knossos users access data mostly remotely, whereas the data actually loaded in knossos is only a small cubic subset, called "supercube". So this feature can only directly access the supercube, in case data is stored remotely.

We have a standalone python package called datasetUtils (in the knossos_python_tools repo, not knossos repo), where you can directly access a local dataset and perform operations such as you suggested. I do not recall whether a TIF export is available there, but that's where it should reside.

One might consider this an artificial strategic decision, to dedicate knossos to only survey portions of a dataset rather than be able to perform set-wide operations. We already have issues of this sort in another plugin, where a set-wide analysis is required within knossos, and datasetUtils is employed in this context as a helper package within knossos - in order to access this data on a locally attached hard-drive.. But this is consider "external" to the knossos core code or capabilities, until the unspoken consensus design is otherwise revised.

[unidesigner]

Hi! Thank you for the explanation. So this means I could pull all the files from said URL to my local machine and then use the datasetUtils. I looked at the code briefly, should I then use initialize_from_knossos_path to point to the knossos.conf file and then use export_to_image_stack to export to PNG images? That might already do it, I'll try later.

[orenshatz]

I guess that's the way to go, yes, except acquiring remote data on per-file basis is usually extremely inefficient. At least for raw data, which would probably be left unchanged in the future, it would make better sense to compress it first on server side, then transfer the compressed file.