handle case when there is no sequence delim but null's

[kwach]

We've came across an error with missing sequence delimiter at the end of the file.

I happens quite often (in a range of hundreds of cases). I suspect dcm4chee version 1.4.xxx

This is limited to pixel data elements with compressed TS as only then it is encoded as a sequence

(7fe0,0010) OB (PixelSequence #=2)
  (fffe,e000) pi (no value available)                     #   0, 1 Item
  (fffe,e000) pi ff\d8\ff\e0\00...                            # 39430, 1 Item
(fffe,e0dd) na (SequenceDelimitationItem)               #   0, 0 SequenceDelimitationItem (missing)

This class of errors is divided between those two file endings in hex

00000000: 5781 62d5 1110 2600 0000 0000 0000 ffd9  W.b...&.........

That can be fixed with dcmconv and combination of options like so: +Ep --ignore-parse-errors try to recover from parse errors +rd --replace-wrong-delim replace wrong sequence/item delimitation items

Hovever the second fil ending I've encountered a lot is like this:

00000000: 0809 3bff 00ff d900 0000 0000 0000 0000  ..;.............

Note: Ending of JPLL pixel payload is 0xffd9

All things like element length are ok, just there is too much padding (as in missing tag fffe,e0dd (4b + 4b of zeros)

This reults in CorruptedData error and critical failure. That file won't be parsed nor converted+fixed.

I'm presenting a possible fix for this situation. newTag is read as 0x0000,0x000 which is DCM_GenericGroupLength with VR UL and has to be handled in dcmpixelseq parser

[jriesmeier]

Thank you for the report and sorry for the late response. Could you make one or two sample files available for further analysis and testing a possible fix?

[kwach]

series-000001.zip

check out attached test cases. I've recreated issues by hand on publicly available files

[jriesmeier]

Thank you, we'll look into it.