Closed jboulanger closed 2 years ago
thanks for the issue and the data @jboulanger. I think you're running into the same thing as #88 ... which was just fixed in #90
I'm not sure why nd2 sometimes has internally inconsistent metadata (where the widthPx is sometimes not a clean multiple of widthBytes * bytesPerPixel)... but your dataset appears to be one of them.
On the main branch, with #90 merged, nd2.imread
appears to work fine for your file:
I'll cut a new release soon
thanks
releasing now... will take 30-60 mins to be available on pip. Closing this "optimistically" ... but feel free to reopen if the new version doesn't fix your issue
Just tested again on the image, the original image (tif or loaded with bioformat) had a width of 4801 but the one opened with the new version has an extra column at the end (width=4802).
Yeah, I can add something to crop that I suppose. I think that at this point, it becomes a bit of a matter of choice with how to deal with the fact that the image metadata itself says that the data on disk is 4802 pixels. Let me try to learn a bit more from LIM (the company that created the nd2 format) about these relatively rare cases where the metadata is internally inconsistent, to see how they would "officially" have it be interpreted (rather than just mimicking bioformats choice, which may also just be one person's decision). thanks for letting me know!
If it helps deciding: the TIFF file was exported directly from NIS Elements where is the image is also 4801 x 4801.
Yeah thanks, and the nis viewer also opens it at 4801
merged a better fix in #92, and it will be in v0.4.2 which is building now
Amazing!
Description
Loading a nd2 image leads to corrupted data. Rows are shifted by 1 pixels and there is a residual error even after shifing rows back compared to the image decoded by bioformats and a tif exported from NIS Elements.
Data accessible from here: https://cloud.mrc-lmb.cam.ac.uk/s/jJMMtqAaRALnnTq
What I Did
Max absolute error with tiff reference: [2707.0, 1564.0, 0.0, 0.0]