Repository navigation
fix(dicom): Fix rejected subimages, and reaching every frame - #5474
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Multi-frame capability is not advertised and the required subimage-count metadata is missing for higher-level APIs.
Get a fresh assessment by requesting another Copilot review.
Review effort: Lite
Findings: 1
Open (1)
What changed in this PR
Fixes DICOM multi-frame seeking by tracking the file’s total frame count and decoder position, with a generated three-frame regression test.
Changes:
- Corrects subimage/frame state handling and frame access.
- Adds deterministic DICOM tests with per-frame hashes.
- Registers the test suite when DCMTK is available.
| File | Description |
|---|---|
src/dicom.imageio/dicominput.cpp |
Updates frame seeking and state tracking. |
testsuite/dicom/src/make_multiframe.py |
Generates a multi-frame DICOM fixture. |
testsuite/dicom/run.py |
Runs the DICOM regression test. |
testsuite/dicom/ref/out.txt |
Stores expected dimensions and hashes. |
src/cmake/testing.cmake |
Registers the DICOM test suite. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
lgritz
added
bug
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>
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Collaborator
Author
|
No objections for 2 weeks -> merge |
lgritz
merged commit Sep 29, 2026
a3e4f8f
into
AcademySoftwareFoundation:main
126 of 128 checks passed
lgritz
added a commit
to lgritz/OpenImageIO
that referenced
this pull request
Oct 3, 2026
…SoftwareFoundation#5474) This is follow-on work to PR AcademySoftwareFoundation#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 AcademySoftwareFoundation#5468 and AcademySoftwareFoundation#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>
lgritz
added a commit
to lgritz/OpenImageIO
that referenced
this pull request
Oct 10, 2026
…SoftwareFoundation#5474) This is follow-on work to PR AcademySoftwareFoundation#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 AcademySoftwareFoundation#5468 and AcademySoftwareFoundation#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
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