Currently, most of the example scripts directly launch napari and visualise results on the fly. While this can be great for some use-cases one also very often wants to perform batch analysis of many files. In this case it is better to run ultrack headless, e.g. on a computer cluster, and save everything that would be needed for visualisation and QC to disk. And then, after it ran, visualise the results, e.g. using napari (or Fiji).
I think most functionality already exists but examples are missing. It would be great if some example scripts could be added where the computation and visualisation functionalities are clearly separated like example1_run_ultrack.py and example1_view_ultrack_results.py, example2_run_ultrack.py and example2_view_ultrack_results.py....
In fact, it may even be good to specify two different conda environments for the two tasks. Practically, we are currently facing the issue that the computational environment where we run ultrack is not compatible with the environment where we would like to view the ultrack output. So for us, I think the best may be to install ultrack twice, once on a computational hardware setup and once on a visualisation hardware setup, where the latter would only need anything needed to view the results.
Long term perspective/dream (not reachable right now) would be, by the way, to save all the ultrack output into an OME-Zarr that could be visualised by many viewers.
Currently, most of the example scripts directly launch napari and visualise results on the fly. While this can be great for some use-cases one also very often wants to perform batch analysis of many files. In this case it is better to run ultrack headless, e.g. on a computer cluster, and save everything that would be needed for visualisation and QC to disk. And then, after it ran, visualise the results, e.g. using napari (or Fiji).
I think most functionality already exists but examples are missing. It would be great if some example scripts could be added where the computation and visualisation functionalities are clearly separated like
example1_run_ultrack.pyandexample1_view_ultrack_results.py,example2_run_ultrack.pyandexample2_view_ultrack_results.py....In fact, it may even be good to specify two different conda environments for the two tasks. Practically, we are currently facing the issue that the computational environment where we run ultrack is not compatible with the environment where we would like to view the ultrack output. So for us, I think the best may be to install ultrack twice, once on a computational hardware setup and once on a visualisation hardware setup, where the latter would only need anything needed to view the results.
Long term perspective/dream (not reachable right now) would be, by the way, to save all the ultrack output into an OME-Zarr that could be visualised by many viewers.