-
Notifications
You must be signed in to change notification settings - Fork 23
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
Improve units conversion in EMD velox files #243
Comments
@ThorstenBASF This is related to how the data is loaded downstream: rosettasciio/rsciio/emd/_emd_velox.py Lines 715 to 723 in 0646b2c
Moving this issue to Rosettasciio. |
@ThorstenBASF for opening this issue. Indeed, even if the current behaviour is still correct, it is not convenient and it would be better to keep the same units when possible (same dimension). This could be improved by checking that both units are different and pick one of the two. What criterion should we use to pick one of the two? As a workaround, it is possible to change the units of the axes using the AxesManager |
@ericpre Thanks for taking care and moving the issues the the right place.
Most of time you want a scalebar for the X axes. So, I would prefer to pick units from the X axes.
Thanks! I just used one more line and set Y=X for scale and units :) |
I see, I just read a bit into the code. The units used for calculations are only from the X axis anyway. rosettasciio/rsciio/emd/_emd_velox.py Line 323 in 0646b2c
So, instead of convert scale_x and scale_y, only x would be necessary. And set Y=X. In addition there is a bug with the offset calculation. Here also the offset units could differ from the scale unit, but scale unit is used for both. (As in my case, the X offset should be -730 nm, not -0.73). So offset needs an additional conversation to same units as the units from scale_x[1], before it is extended to 'axes'. rosettasciio/rsciio/emd/_emd_velox.py Lines 358 to 391 in 0646b2c
|
@ThorstenBASF, would you be interested to make a pull request to do these changes? If so, there are some guidance contributor guide (which mostly refer to the hyperspy contributor guide). |
I can't promise anything. I will first have to read me into all the "convert" commands and handling. Besides, this would be more or less private "joy". :) But, I will see what I can do. |
Hope this can be closed. :) |
Describe the bug
If an image has a different number of pixels in X and Y, it can happen that axes are set to different units.
In my case I had an image of 256x512 with an original pixelsize of 5.1e-09m.
This is converted to 5.1nm in X and 0.0051µm in Y.
This leads to an error while I want to save the image with a scalebar, due the sanity check of the file_writer.
(see io_plugins/image.py, line 147)
To Reproduce
(The testfile contains confidential data, so i can't share, if nessessary I could creat one with public data.)
Steps to reproduce the behavior:
Expected behavior
Not sure where to fix it. I think best would be to have same units even if X Y has a ratio of 1:2, but here I didn't checked(found) the code.
The santiy check could also be extended to compare different units, but that would be much more effort.
Python environment:
Additional context
Images of original_metadata and axes.
As a workaround I just set [1]=[0] for scale and units.
The text was updated successfully, but these errors were encountered: