Corrupted DICOM JPEG file
Mathieu Malaterre
If anyone is interested, I have placed on gdcm website a DICOM JPEG
file that seems to be corrupted:
http://gdcm.sourceforge.net/thingies/GENESIS_SIGNA-JPEG-CorruptFrag.dcm
I have not yet found a way (if any) to properly read that file.
-Mathieu
kul....@gmail.com
wrote:
This is the error that us get from dcmdump
DcmItem: Element (0043,100a) found twice in one dataset/item, ignoring
second entry
dcmdump: error: I/O suspension or premature end of stream: reading
file: C:\temp\GENESIS_SIGNA-JPEG-CorruptFrag.dcm
Ross
There is that error (an element found twice) however if you modify/remove
the tag you'll also find that the lossless jpeg encoded image does not
decompress properly!
Mathieu, I had a look at it out of curiosity, I'm not sure what's going on
there myself it doesn't seem to be any of the typical lossless codec bugs
that's created it, I got to the point where I felt that the predictors used
to create it were wrong and gave up due to lack of time. Don't know if that
helps at all.
Ross
<kul....@gmail.com> wrote in message
news:546259c0-5a54-4890...@24g2000hsh.googlegroups.com...
Jean-Pierre Roux
Mathieu,
There are two oddities in the file :
- No 'Study Instance UID' element, but an illegal seems-to-be UID
(0020|000a)
- Element 0043|100a appears a second time -at offset 0x4518-.
I patched the file with my favourite hexadecimal editor, but I still
cannot import it in our 'Advantage Widows' GE clinical console
:-(
Jean-Pierre Roux
Mathieu Malaterre
Sorry about that !
I should have remove those issues first, so that people don't get
distracted from the real issue. So -again- here is the issue with a
corrupted JPEG fragment (I have a bunch of them):
http://gdcm.sourceforge.net/thingies/GENESIS_SIGNA-JPEG-CorruptFrag-Cleanup.dcm
This file differs from the previous one, in two things:
1. 0020,000a was manually changed to 0020,000d (this tag *really*
looked like Study Instance UID anyway)
2. As you properly reported, I removed the extra 0043,100a (the second
instance had a VR different from what is in my private dict).
Thanks again for your efforts,
-Mathieu
Mathieu Malaterre
> There is that error (an element found twice) however if you modify/remove
> the tag you'll also find that the lossless jpeg encoded image does not
> decompress properly!
>
> Mathieu, I had a look at it out of curiosity, I'm not sure what's going on
> there myself it doesn't seem to be any of the typical lossless codec bugs
> that's created it, I got to the point where I felt that the predictors used
> to create it were wrong and gave up due to lack of time. Don't know if that
> helps at all.
Hi Ross,
Thanks for looking into it. I had some feedback from someone else
that the issue might be with the huffman table...
I -also- do not have time to spent into that issue, but I leave the
files on gdcm website for a while. I cross posted the issue to
comp.compression.
Thanks again,
-Mathieu
Yves Martel at
I did look at it, and from what I can see:
I do not beleive it is a prdictor error.
The lines are shifted right from time to time, but not in a consitant
way. A predictor error would not skew the image that way.
Each right shif seem to match a pixel value that is outside the range
of the other values. This is why I rather suspect an error in the
Hufman tables...
Yves
Ross
In the past I have seen coding errors with predictors that have caused image
sheer, particularly on calculating the start of line predictors (i.e. off by
one errors).
Having said this you might well be correct, this is supposed to be Pa which
is pretty hard to mess up, I only had an hour spare to have a try with it.
Ross
"Yves Martel" <Martel(at)TomoVision.com> wrote in message
news:epph04h7oo6ipava6...@4ax.com...
Yves Martel at
I agree with you, predictor error is a good "usual suspect".
One of the first thing I tried is to remove all predictor computation
and look at the pixel values directly from the table computation
because, in my opinion, we should never underestimate the capabiliy
of people to mess up ;)
Yes, a predictor error can cause a shift, but in this case, not all
the lines are shifted. There is even a few bunch of lines that are
O.K. from time to time (170 to 174 for example). This is why I do not
beleive the error is not a predictor error, but rather something fishy
in the tables...
Yves
On Sun, 20 Apr 2008 08:43:41 GMT, "Ross" <nor...@blueyonder.co.uk>
wrote:
Ross
Absolutely! You've spent more time on it than I have so I would suspect
you're correct!
Ross
"Yves Martel" <Martel(at)TomoVision.com> wrote in message
news:nmtm0451di273h3pf...@4ax.com...