Closed HsupoLeng closed 2 years ago
Merging #94 (3aa57d1) into master (0065ef6) will not change coverage. The diff coverage is
100.00%
.
@@ Coverage Diff @@
## master #94 +/- ##
=======================================
Coverage 95.07% 95.07%
=======================================
Files 6 6
Lines 264 264
=======================================
Hits 251 251
Misses 13 13
Impacted Files | Coverage Δ | |
---|---|---|
src/parsing.jl | 97.50% <100.00%> (ø) |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 0065ef6...3aa57d1. Read the comment docs.
Hi @HsupoLeng :wave:, thanks for writing up this detailed PR and coming up with a potential fix. Just so I understand the layout of this image, you have 3 XYCT images that you took every 20mins that consist of 512x512 images with 2 channels and 10 timepoints?
I think you've diagnosed the problem correctly. Your image was resetting the IFD ids between each "cycle" so OMETIFF was blindly overwriting the IFD_index
. I believe a more general solution than the one you proposed is to set prev_ifd
to the maximum previously observed IFD index instead of relying on the number of files.
Do you mind opening a PR against https://github.com/tlnagy/exampletiffs? It would be nice to add some tests with those images so we can avoid any regressions in the future.
Hi @tlnagy , you are mostly right about the image's layout. These are 3 XYCT images that I took every 20 seconds that consists of 512*512 images with 2 channels and 11 timepoints.
Your solution still perfectly resolved my issue. I agree that your more general fix works better: It's more appropriate to use ifd_index
than obs_filepaths
, considering the case where the same IFD is split across files or the case where tiffdata["IFD"]
is non-zero. About the dense numbering assumption, I am not familiar enough with ome.tiff to add more information.
I will open a PR against https://github.com/tlnagy/exampletiffs soon - I would like to first prepare a smaller set of images that shows the same case. I will also add a few tests for them.
:+1: Glad to hear that it works for you. Yeah, in your case the original solution happens to work because each IFD is in a new file so length(obs_filepaths) == length(ifd_index)
but that isn't required to be always true.
I documented the dense numbering assumption so that if I happen to run into a weird edge case in the future where this assumption causes problem, I can diagnose the problem more quickly.
I opened a pull request to exampletiffs with a small set of example images and added test against the example in my latest commit. I tested load and image dimensions following most other tests, but please feel free to update if there are cases that I didn't consider.
Great! Thanks for following up and adding the tests. I merged https://github.com/tlnagy/exampletiffs/pull/2 and restarted the tests. Hopefully they'll all be green now.
I'll squash and merge once it passes.
Once the tests pass again on master, I'll tag and release v0.4.1
, which will feature your fix.
Hi there,
I recently started using OMETIFF for dealing with my microscope recordings in Julia. The package worked great for most of my data, but failed in the case where I collected multiple cycles of time series. Each cycle share the same imaging parameters, and were collected as automatic repetitions over the same FOV. As a neuroscientist, I perform this type of acquisition as I change the experiment condition for each cycle, so I can ask the effect of experiment condition on the neurons in the FOV. This should be a fairly general user case.
Back to the package, I looked into the code and seemed to have found an one-line bug with potentially broad impact.
Error
When there are multiple image nodes in the same ome.tiff, calling load() results in BoundsError. See error message below.
Root cause
When there are multiple image nodes (
containers
) in the dataset, the functionifdindex!
is called for the corresponding number of times.ifd_indices
and two other outputs are shared acrossifdindex!
calls, but in each call, the indicesifd
andprev_ifd
always restart from 1 and 0. As a result, the outputs have the size equal to only one container; information from later image nodes overwrites earlier ones. At the same time, the last index inifd_indices
(pos_idx
) increments to track container/Image ID. Whenifd_indices
were later used to access an one-container-sized array in functioninmemoryarray
, BoundsError is triggered.Fix
Initialize
prev_ifd
inifdindex!
as the length ofobs_filepaths
, to reflect the number of existing ifds.Test
The fixed version passes all existing tests in
runtests.jl
. I have provided a folder of dummy images that should allow the error to be reproduced here, but have not included them in a test, because of the relatively large number of images.