MRXS: handle output of newer scanners #283
Conversation
But instead use that as an indicator that no stitching is needed. Also clean up some logging.
| for (int i=0; i<listOffsets.length; i++) { | ||
| listOffsets[i] = indexData.readInt(); | ||
| //int depth = Integer.parseInt(hierarchy.get("HIER_" + i + "_COUNT")); | ||
| int depth = pyramidDepth; |
There was a problem hiding this comment.
As the depth is identical for all hierarchies and set to pyramidDepth, what is the rationale for
1- defining a separate variable and
2- using a long[][] rather than a long [] as previously
Or is this effectively kept over from the investigation?
There was a problem hiding this comment.
Partly left over from investigation, partly so that less arithmetic is required to index into listOffsets. Can clean up the commented-out line and separate variable though.
| } | ||
|
|
||
| // read offsets to pyramid pixel data tiles | ||
| for (int h=0; h<nHierarchies; h++) { | ||
| for (int i=0; i<pyramidDepth; i++) { | ||
| for (int h=0; h<1; h++) { // TODO |
There was a problem hiding this comment.
Is this still TODO and what is the impact of not reading the offset for all hierarchies?
There was a problem hiding this comment.
Cleaned up in a790719.
|
Note I have not reconverted all of the data for this issue with the last 2 commits, but have spot-checked with a couple of the relevant datasets together with https://openslide.cs.cmu.edu/download/openslide-testdata/Mirax/CMU-1.zip (to make sure older data is still OK). That means it is extra important to double-check conversions with whichever commit is the last to pass code review. |
There was a problem hiding this comment.
From a code review, the latest commits address the few cleanup suggestions.
Given the nature of the changes proposed here, I suggest the functional testing should not be limited to the datasets that prompted this work but also cover some historical MRXS datasets to make sure there is no regression in terms of either data integrity or conversion performance.
|
5a38975 should be specific to FL data, so should not affect the previous test data for this PR as that was all BF. Relevant test data for this last commit is https://zenodo.org/records/16962727, see #285. |
Expected to fix #258.
This does a few things:
StitchingLevelForHWCoordsection, and if present, ignores the stored positions for each tile and instead places each tile in a regular grid with no overlapTRACEandDEBUGlogging, in case similar issues come up againIn all test data available, converting to OME-TIFF with this change and latest raw2ometiff then opening in QuPath 0.6.0 does not show any obvious tile boundaries or other stitching errors. More eyes would definitely be useful though.
I have not bothered to clean up the commit history here, in case intermediate commits are useful in future for seeing what was tried and rejected.