sum loading: Stop defaulting to 1nm/px when pixel to nm scaling cannot be found. #181
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #181 +/- ##
==========================================
+ Coverage 74.62% 79.93% +5.30%
==========================================
Files 8 12 +4
Lines 607 927 +320
==========================================
+ Hits 453 741 +288
- Misses 154 186 +32 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
ns-rse
left a comment
ns-rse
left a comment
There was a problem hiding this comment.
Sounds sensible but I wonder if we should log an error and return None for that image rather than fail?
It might mean that dictionary/list of images to be processed would then continue to be processed by TopoStats.
Another thought is whether we are likely to see similar problems with other file formats too? Should we also handle those in a similar manner?
| if px_to_real[0][0] == 0 and px_to_real[1][0] == 0: | ||
| pixel_to_nm_scaling = 1 | ||
| logger.info(f"[{filename}] : Pixel size not found in metadata, defaulting to 1nm") | ||
| raise ValueError(f"[{filename}] : Pixel to nm scaling could not be determined from metadata.") |
There was a problem hiding this comment.
I wonder if instead of raise ValueError we might consider LOGGER.error()?
My thinking is that if there is a directory with multiple images and only one fails then we should still be able to process the other images in that batch.
|
Oh interesting, just found out that the real scan size in nm, and the number of pixels (px) are accurate, so we can just also directly calculate it on the fly if it's not present. I'll look into it. |
|
Also agree, no output, with a warning rather than crashing. |
Closes #180
Does as described. Don't think it has any extra effects?
It's important to crash when the file doesn't have a pixel to nanometre scaling, since it is better to not process, than to process and have wrong values for measurements. :)