Conversation
This is follow-on work to PR 5468 -- after fixing the TIFF reader, I also turned up some similar issues in other format readers, and this PR addresses the issues in DICOM. Two problems in DICOMInput::seek_subimage(), both of which had been there for as long as the reader has claimed to support subimages. A failed seek left the reader pointing at a subimage it had just refused, similar to what was uncovered for other formats in PR 5468 and 5470. Fixing that is the main point of this patch. Second, along the way it was discovered that every frame past the first was unreachable. The subimage bound came from DicomImage::getFrameCount(), which is the number of frames the DicomImage loaded, not the number in the file. Instead, getNumberOfFrames() is the file's own count and is what we want. But DICOMInput also never overrode current_subimage(), so it inherited the base class's "always 0" -- harmless while there could only be one subimage, wrong for multiple images. Adds a testsuite for the dicom format, which had none. The test writes its own small three-frame file rather than depending on an external image. Each frame is a different constant value, so the per-subimage hashes catch both losing the frames and reading the same frame repeatedly. Assisted-by: Claude Code / Claude Opus 5 Signed-off-by: Larry Gritz <lg@larrygritz.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is follow-on work to PR #5468 -- after fixing the TIFF reader, I also turned up some similar issues in other format readers, and this PR addresses the issues in DICOM.
A failed seek_subimage left the reader thinking it was pointing at a subimage it had just refused, similar to what was uncovered for other formats in PR #5468 and #5470. Fixing that is the main point of this patch.
Second, along the way it was discovered that every frame past the first was unreachable. The subimage bound came from DicomImage::getFrameCount(), which is the number of frames the DicomImage loaded, not the number in the file. Instead, getNumberOfFrames() is the file's own count and is what we want.
But DICOMInput also never overrode current_subimage(), so it inherited the base class's "always 0" -- harmless while there could only be one subimage, wrong for multiple images.
Adds a testsuite for the DICOM format, which had none. The test writes its own small three-frame file rather than depending on an external image. Each frame is a different constant value, so the per-subimage hashes catch both losing the frames and reading the same frame repeatedly.
Assisted-by: Claude Code / Claude Opus 5