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.
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.