Task #12740 (new)
Bug: Miscellaneous OMETiffReader defects
|Reported by:||rleigh||Owned by:|
While doing the C++ conversion, I noticed a few small problems, mostly confined to initFile.
- "i" and "s" are both used to refer to the current series in a loop. s is assigned from i in the loop but both are identical. Suggestion: Remove s, rename i to s. Even better, rename i to series so it's obvious what it is.
- TiffData? processing has O(n!) complexity. Reduce to O(2n) by moving the plane clearing loop out of the TiffData? loop so it's two single passes only. In the C++ code this was done by changing exists from a boolean to an enum to differentiate between the states so we only clear unknown planes.
- In "verify that all planes are available" loop, if the reader is null and the planes are reinitialised, there's no explicit break to exit the loop and prevent the process happening again. Shouldn't in practice but it would make the intent clearer.
- At the end of initFile null series are removed. This breaks indexing when restoring dates, etc. This should be the last operation in initFile to avoid indexing errors.
- [zct]OneIndexed? only cope with indexing starting at zero or one. The code can be trivially generalised to support arbitrary index starts, done in the C++ code, which will make it a bit more robust.
- Several checks use data from IFD 0, even when they are doing a check for something in a completely different series, which could likely be using completely different values, so several things could break if using multi-series data where the series are not the same. To fix, it needs to use an IFD from the series in question.