Fail if corrupted image header in the sequence #417
Merged
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.
There is a loss of content in an uncommon situation that applies only to DPX/TIFF/EXR sequences that contain a file where the first 4 bytes are not as expected (e.g. a DPX file where the first four bytes are not the “XPDS” magic value). Such a file is not decodable by any DPX/TIFF/EXR reader, but such invalid files could happen to be within such image sequences. For such a file, a RAWcooked encoding (for versions before 23.08) completely skips the invalid file so it is not represented in the resulting RAWcooked compressed file. For instance, with this sequence:
image_001.dpx (valid)
image_002.dpx (first four bytes are not 0x58504453, aka "XPDS" in ascii)
image_003.dpx (valid)
the resulting RAWcooked compressed file would only depict image_001.dpx and image_003.dpx, even though image_002.dpx may contain valid image data. Decoding that resulting RAWcooked compressed file would not recreate the original image_002.dpx file.