Use new mesh API for animation job

[hotzenklotz]

This PR adds support for passing the required mesh information to use mesh API (PR #7587)for animation jobs.

URL of deployed dev instance (used for testing):

• https://___.webknossos.xyz

Steps to test:

• Set up worker with PR https://github.com/scalableminds/voxelytics/pull/3472
• Enable worker in WK
• Test view mode with a dataset containing a segmentation.
  • Both ad-hoc and pre-computed meshes should work
• Test annotation:
  • Load some pre-computed meshes for an existing segmentation layer
  • Load some ad-hoc meshes for an existing segmentation layer
  • Create a second volume layer, brush some and load the resulting meshes
• If you are really diligent:
  • Test switching the ad-hoc meshing mag quality
  • Load meshes from different pre-computed meshfiles

TODOs:

• AdHoc Meshing
• Testing with mappings etc

Issues:

• Follow up to Add route to load full mesh stl of a segment/agglomerate #7587 and Add Render Animation Worker Job #7348

---

(Please delete unneeded items, merge only when none are left open)

• Updated changelog
• Updated migration guide if applicable
• Updated documentation if applicable
• Adapted wk-libs python client if relevant API parts change
• Removed dev-only changes like prints and application.conf edits
• Considered common edge cases
• Needs datastore update after deployment

[philippotto]

didn't test yet, but looks good already 👍 added some minor comments.

[philippotto]

Suggested change

	const axis = "";
	// Currently, additional coordinates are not supported for this rendering job
	const axis = getAdditionalCoordinatesAsString([]);

would be a bit cleaner.

[fm3]

note that if the command args change, the job list view code in the frontend also needs to be adapted (currently the existing layer_name is used to render the job description. compare also getJobs in admin_rest_api

[fm3]

we also need to ensure backwards compatibility for this job list view rendering (or migrate old jobs in postgres)

[hotzenklotz]

Good catch. I wasn't aware of this connection... will undo the renaming then.

[fm3]

I tested again and most cases work for me now 🎉

I noticed two more small problems

This message already crops up on pageload when viewing a dataset without color layers. It would be nice if that would happen only once you actually clicked on create animation.

And: sometimes seedAdditionalCoordinates is not included in the mesh info json (in my test this happened in a proofreading annotation). Since the python code expects this field to be present (although null is a valid option), it fails at that point. Not sure if it should be adapted here or there.

[hotzenklotz]

I noticed two more small problems

This message already crops up on pageload when viewing a dataset without color layers. It would be nice if that would happen only once you actually clicked on create animation.

I fixed this.

And: sometimes seedAdditionalCoordinates is not included in the mesh info json (in my test this happened in a proofreading annotation). Since the python code expects this field to be present (although null is a valid option), it fails at that point. Not sure if it should be adapted here or there.

I have a hard time to reproduce this. I played around with proofreading annotations but the request always includes a an empty array for the seedAdditionalCoordinates which should be fine?

[philippotto]

Since the python code expects this field to be present (although null is a valid option) [...]

I played around with proofreading annotations but the request always includes a an empty array for the seedAdditionalCoordinates which should be fine?

I think, it would be easiest to adapt the python code so that a missing value is also okay. Alternatively, we would need to turn seedAdditionalCoordinates? into seedAdditionalCoordinates in BaseMeshInformation, but that probably requires touching several code spots.

Without doing one of these options, rare hiccups are bound to happen at some point, since the property is typed as "may be missing".