You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have some test files which I think are non-compliant, but wondering if dicomParser's handling is optimal. These files have encapsulated pixel data with one defined length item containing the pixel data stream. However, it appears that the pixel data sequence delimitation item (FFFE,E0DD) has length = 4294967295 (undefined), rather than 0. I believe a length of 0 is required per the standard: https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_7.5.2.html
dicomParser, however, takes whatever length is given and tries to seek to that position, which results in a buffer overrun error being thrown. Why doesn't dicomParser just assume a length of 0 for the FFFE,E0DD element as required by the standard? Relevant code here:
I have some test files which I think are non-compliant, but wondering if dicomParser's handling is optimal. These files have encapsulated pixel data with one defined length item containing the pixel data stream. However, it appears that the
pixel data sequence delimitation item (FFFE,E0DD)
haslength = 4294967295
(undefined), rather than0
. I believe a length of 0 is required per the standard: https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_7.5.2.htmldicomParser, however, takes whatever length is given and tries to seek to that position, which results in a buffer overrun error being thrown. Why doesn't dicomParser just assume a length of
0
for theFFFE,E0DD
element as required by the standard? Relevant code here:dicomParser/src/findEndOfEncapsulatedPixelData.js
Line 50 in 7d20843
Example file: https://drive.google.com/file/d/1tqXGAdfSq3H4oJA_w_dbhWJG2JrPapEx/view?usp=sharing
The text was updated successfully, but these errors were encountered: