Fix spurious SequenceDelimitationItem in DICOMDecompressor output#40
Open
jmesterh wants to merge 1 commit intojohnperry:masterfrom
Open
Fix spurious SequenceDelimitationItem in DICOMDecompressor output#40jmesterh wants to merge 1 commit intojohnperry:masterfrom
jmesterh wants to merge 1 commit intojohnperry:masterfrom
Conversation
…lement, the post-pixels loop wrote a stale SeqDelimitationItem (fffe,e0dd) left over from the encapsulated pixel-skip logic. Restructured the loop to match the other DICOM processors and filter out FFFE-group delimiter tags.
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.
as noted at https://groups.google.com/g/rsnas-ctpmirc-user-group/c/DtQ8vzkBzCw
Problem
For encapsulated transfer syntaxes like JPEG 2000
DICOMDecompressor.decompress()writes a spurious SequenceDelimitationItem(fffe,e0dd)after pixel data when pixel data is the last element, creating an invalid DICOM file.Root Cause
Commit 2ae3e71 commented out the
fileLengthguard in the post-pixel-data loop across five files. That was fine in the other four since their loop structures naturally advance past stale tags. But DICOMDecompressor is different, after skipping encapsulated pixel data fragments, the parser's last-read tag is still the SeqDelimitationItem. When pixel data is the last element,hasSeenEOF()is false andgetReadTag()returns that stale tag (not -1), so the loop writes it to the output.Fix
I restructured the post-pixel-data loop to match the pattern in the other four files and added a guard against DICOM delimiter tags:
(tag >>> 16) != 0xFFFE— rejects stale delimiter tags (Item, ItemDelimitationItem, SeqDelimitationItem) that should never be written as standalone elementstag != 0xFFFAFFFA/tag != 0xFFFCFFFC— filters Digital Signatures Sequence and Data Set Trailing Padding, matching the other filesAfter this change the output was valid DICOM.