Rescale layers for different voxel sizes on remote import

[frcroth]

URL of deployed dev instance (used for testing):

• https://differentvoxelsizes.webknossos.xyz

Steps to test:

• See Support adding multiple layers with different voxel sizes separately #6821 (add color, then add clahe as another layer -> notice that they are aligned in the resulting dataset)

To-dos:

• Frontend @philippotto

Issues:

• fixes Support adding multiple layers with different voxel sizes separately #6821

---

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

• Updated changelog
• Needs datastore update after deployment

[philippotto]

@frcroth I just pushed the necessary frontend changes. let me know if you need anything else 📫

[frcroth]

@philippotto
Not sure what the problem is right now. You can also test it for the two layers in the issue. The backend gets the preferred voxel size correctly and returns a datasource with a coordinate transformation, but it does not seem to affect the frontend, so the datasource configuration does not include a coordinate transformation.

[philippotto]

@philippotto Not sure what the problem is right now. You can also test it for the two layers in the issue. The backend gets the preferred voxel size correctly and returns a datasource with a coordinate transformation, but it does not seem to affect the frontend, so the datasource configuration does not include a coordinate transformation.

If I see it correctly, the backend defines the coordinate transformations once for the entire datasource. However, the transformations should be defined per layer. For example, if there are two layers (with differing voxel sizes), the first shouldn't have a transformation, but the second should get one so that it matches the 1st. Does this make sense?

[frcroth]

@philippotto Yes, thank you, your comment helped me and now it works 🎉

[fm3]

Backend looking good, just left two cosmetic suggestions.

As I mentioned before, this variant is not going to be able to register situations where e.g. the segmentation exists only starting at mag2 (but theoretically has the same voxel size). With this, it will register both starting at their individual mag1 with a transformation. In that particular case, my guess is that we would prefer calling it mag2, and have a uniform voxel size. However, I don’t know how to properly distinguish which case we want, with the limited information we are getting.

@philippotto Do you have an idea how this distinction could be made? I guess we could look for power-of-two divisibility, but that may yield false positives.

Otherwise, I’d say it is fine as is. One could also argue it is more correct to always call the “finest” existing mag of a layer mag1.

[philippotto]

@philippotto Do you have an idea how this distinction could be made? I guess we could look for power-of-two divisibility, but that may yield false positives.

I've thought a bit about this and think that this is a pretty good heuristic. In the rare event of a false positive, the rendering should still be fine. Enumerating the mags differently could still be seen as a plausible way of bringing two layers together, in my opinion.

[fm3]

I've thought a bit about this and think that this is a pretty good heuristic.

Ok, in this case, I’d like to ask you @frcroth to add this heuristic. I assume an epsilon check is needed for checking the divisibility.

For a test dataset, you could use the zarr streaming links from a webknossos instance (directly link to a mag, so no ngff metadata is used)

[fm3]

If I read the code correctly, the rounding of minVoxelSize/preferredVoxelSize the could be a problem. If one layer has 2.3 times the other’s voxel size, this might be wrongly detected as mag2, right? I think the isPowerOfTwo check has to be done on the doubles there, possibly with epsilon comparison.

Apart fromt hat, it looks good to me now :)

[frcroth]

@fm3 Was this what you had in mind?

[fm3]

Yes, perfect!