Rename Resolution to Mag

[knollengewaechs]

In this PR, the term "resolution" is replaced with "mag"/"magnification" in a lot of places.

• For the backend, see this comment below. The DB schema was adjusted, too.
• In the frontend code, method names, their parameters, types, properties, error messages and console prints were adjusted. Function or local scoped variables were not adjusted, because this would make the changes way too large to review. As I am not familiar with the shader code, I didnt change *.glsl.ts files either.
• In the UI, the term "resolution" is only being used in the context of animations after this PR. Other than that, "magnification" or sometimes "mag" is (or should be) used in toasts, tooltips, modals, sliders etc.

URL of deployed dev instance (used for testing):

• https://magalltheway.webknossos.xyz/

Steps to test:

• Test that everythings works as before by trying to test features that depend on mags.
• This includes:
  • Opening an annotation, zooming in and out
  • Creating an annotation with restricted mags
  • Creating a volume layer with restricted mags
  • Testing all tools in the toolbar
  • Create & Edit task type with magRestrictions, create task + open it, should only have the allowed mags
  • reload dataset list from disk

TODOs:

• backend
• frontend
• rename files, too
• fix frontend tests
• fix e2e tests
• add some explanation to info tab tooltip

backup branch: https://github.com/scalableminds/webknossos/tree/backup-rename-resolution-to-mag

Issues:

• contributes to Rename Resolution to Mag (in UI and code where possible) #7378

---

• Updated changelog
• Updated migration guide if applicable
• Removed dev-only changes like prints and application.conf edits
• Considered common edge cases
• Needs datastore update after deployment

[fm3]

@dieknolle3333 I pushed a commit changing a lot of usages in the backend. This changes the protocol in a couple of ways (please adapt the frontend):

• resolutionRestrictions → magRestrictions (everywhere, e.g. tasktype json, AnnotationLayerParameters. just search for all occurrences)
• volumeTracing proto → resolutions → mags
• skeletonTracing proto → node.resolution → node.mag

There are also a couple of spots where a change might be expected but cannot be easily done without breaking backwards compatibility with hard-to-migrate data. I did not change:

• CreateNodeSkeletonUpdateAction.resolution
• DataLayer.resolutions (this is a big one. we need to get rid of the datasource-properties.json eventually)
• WKWDataLayer.wkwResolutions

I also did not yet change the postgres tables. I might add this later if I manage to find time. That should not have impacts on the frontend-backend protocol though. For me to test that I don’t break anything there, it would be nice if everything else worked again first.

Please ping me again if anything seems out of place. I might have missed some spots of course.

[knollengewaechs]

thank you so much! 🙏 I will get back to you once I am done with the frontend or if I have a question about the backend part.

[knollengewaechs]

after trying to rename "resolution" in a lot of places, I came to the conclusion that I will have to narrow the scope. I will rename the most important types and methods, but not do it everywhere. This also means that I will probably rebase.

[knollengewaechs]

@fm3 from my side, the first iteration for the frontend is done. I renamed most methods and most parameters and added some sentences to the UI.
Do you want to adjust the DB tables?

[fm3]

Did that now :) From a first glance, it looks like things still work fine 🙌

Could you elaborate a bit on how you narrowed the scope? What areas/things did you skip? I guess this is related to the things I didn’t want to change in the backend as listed above?

[fm3]

I fixed the snapshot tests, added a changelog entry and slightly updated the PR description. Once you described the scope as I mentioned above, this should be ready for a first review round :)

[knollengewaechs]

@fm3 or @MichaelBuessemeyer: there were merge conflicts in the migrations because the worker name already had no. 121. So I gave the migration in this PR no. 122 and changed it in MIGRATIONS.unreleased.md, and renamed the files in conf/evolutions/122-resolution-to-mag.sql and /reversions/. I hope this was correct!
edit: nvm, the pipeline turned red

[fm3]

Yes, thanks! I see you found the various pitfalls of schema versions 😅 I added a commit also adapting the sql reversion (It is not checked in the CI, but could become important if we need to roll back after deploying this)

[MichaelBuessemeyer]

Nice, thanks you two :)

I didn't do another "extensive" testing session as only local vars were changed.

But sadly I noticed that the mag restrictions setting of task types is now buggy on this branch. @dieknolle3333 could you please fix this before merging? I just identified a potential reason for this.

How to test / reproduce:
1.

• create a new task type with mag restrictions (e.g. min 1, max 2)
• edit this task type -> the mag restriction setting should be empty -> broken

• create a task with this task type
• open such a task and try to zoom out of the valid range. On the master a warning toast is shown, but on this branch no toast is shown.

[MichaelBuessemeyer]

Hej, I just noticed that the following messages aren't used in the code base

• dataset.mag_mismatch
• tracing.volume_mag_mismatch

Could you maybe double check this and in case you have the same result remove them? I'd say there is no use in keeping and maintaining them.

[knollengewaechs]

no, they are not used. I also noticed this. I'll remove them

[MichaelBuessemeyer]

Awesome thanks 🙏

The fix works and thanks for removing the unused messages