-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding a pixel size in OMERO metadata #357
Comments
Related, are there any spatialdata examples where the X and Y axes of the NGFF metadata are not |
@keller-mark unfortunately I don't think so as we don't have physical units in the transformations examples yet |
@keller-mark I confirm what Giovanni said, we had this in a very early version but we removed it during a refactoring of the transformations in February and we haven't put it back yet. The reason is that we were designing a final refactoring of the transformations that we postponed because had lower priority of other parts. Anyway, now the design is set and I plan to open a PR on this by the end of the year. This is another issue tracking physical units: #30 For the time being, the scaling factors can be obtained by diagonalizing the transformation after having it represented it as an affine matrix ( In the case in which the affine matrix is not diagonalizable, then formally no pixel-to-unit factor can be defined, but one could maybe still approximate it as the mean of the eigenvalues. I hope that this can unlock you. |
@berombau suggested to be sure to add, when it's available, the units to pixel size value in the OMERO metadata.
This number is redundant as it can be computed from the coordinate transformations, but he said that it would be handy for tools to have a copy of this value readily available from disk, without having to derive it by looking at the eigenvalues of the affine transformation.
The text was updated successfully, but these errors were encountered: