Broken JPEG from GE station
Mathieu Malaterre
Ok here it is for those of you who beg for it ;-P
David if you read this thread, could you please verify this is indeed a
bug different that the one you patched in your custom PVRG.
http://www.creatis.insa-lyon.fr/~malaterre/gdcm/GEMS/
Of course any information (GE people are you reading this newsgroup?)
on this bug would be very welcome.
Happy hacking,
Mathieu
David Clunie
I ran it through the PVRG code as well as whatever codec is
used in the JAI JIIO codecs, as well as through TomoVision's
DICOMatic and it produced an obviously incorrect decompressed
image all cases.
The folks involved at GE with the earlier bug were myself and
Bill Edens, neither of whom works there any more, so there
is no help from that avenue; anyway, this does not seem to
be the same bug and has probably been produced by a different
codec than the one we were fixing.
I will forward this to someone at GE who might want to follow
this up, but first I would need to know all the manufacturer
and model name and software version information for this image
(which has all been stripped out of your sample files
unfortunately).
Also, what is the heritage of this image, i.e., how to it get
out of the scanner this way ... on the network, on MOD, on
CD or via some other third party software ... I ask because
it may not be a GE bug if it did not come directly from the
scanner.
I see mention of Dicom Objects (presumably from Dave Harvey)
in the meta-information header, but perhaps that is just
because you anonymized it with his tools or something.
David
PS. Some software that this image has passed through has also
created invalid UIDs, which is not cool:
(0x0008,0x0018) UI SOP Instance UID VR=<UI> VL=<0x000e> <9.99.999.9999>
(0x0020,0x000d) UI Study Instance UID VR=<UI> VL=<0x000e> <9.99.999.9999>
(0x0020,0x000e) UI Series Instance UID VR=<UI> VL=<0x000e> <9.99.999.9999>
(0x0020,0x0052) UI Frame of Reference UID VR=<UI> VL=<0x000e> <9.99.999.9999>
Mathieu Malaterre wrote in <news:comp.protocols.dicom>:
mathieu wrote:
> Hello there,
>
> I recently received some GE DICOM image that are encoded in JPEG:
>
> D 0002|0010 [UI] [Transfer Syntax UID] [1.2.840.10008.1.2.4.57] [JPEG
> Lossless Non-Hierarchical (Process 14)]
>
> I was not able to read some images of the serie properly using:
> - gdcm
> - DicomWorks
> - Osiris
> - DICOM Eye
> - TomoVision
> - dcmtk
> - xmedcon
>
> I tried using the PVRG + ge patch from David Clunie web page, without
> any success.
>
> Could someone please give me the information of the people at GE who
> where involved in the ge-patch of PVRG ? I would like to gather some
> information, and if possible a patch for IJG+lossless path to hopefully
> support those broken JPEG files.
>
> Thanks for your help
> Mathieu
>
> Using djpeg I get the following information:
> Independent JPEG Group's DJPEG, version 6b 27-Mar-1998
> Copyright (C) 1998, Thomas G. Lane
> Start of Image
> Start Of Frame 0xc3: width=512, height=512, components=1
> Component 0: 1hx1v q=0
> Define Huffman Table 0x00
> 0 2 2 3 1 1 1 1
> 1 1 1 1 0 0 0 0
> Start Of Scan: 1 components
> Component 0: dc=0 ac=0
> Ss=6, Se=0, Ah=0, Al=0
> Must downscale data from 16 bits to 8
> End Of Image
>
Dave
I have looked at this file, and it was indeed LAST written out with my
toolkit (DicomObjects), so I agree with David's earlier comments that
it is important know exactly HOW the image has got from the original
equipment to the file that you have made available. In particular, I
would be very interested to know in which transfer syntax it had been
encoded when read/received by my tookit, as DicomObjects only recodes
where strictly necessary, so I would very much like to know whether
this ws simply "passed through" unchanged, or whether the problemmatic
encoding is my fault (in which case I would wish to check this out
throroughly). Interestingly, I can read and display the image fine,
but that does not men it is OK, as I have many workarounds for known
common errors in other codecs (such as the old GE one which we all know
about!).
Can you please reply directly to me as well as the newsgroup, as I will
be travelling for the next few days, and may not be following the
newsgroup.
BTW - I plead not guily on the UIDs.....I have plenty of proper ones to
use !
Dave Harvey
Medical Connections
Yves Martel
I looked at the image and I did found the problem :o)
The image advertise a predictor (Ss) value of 6, but if I change this
to 2 it is O.K.
Now the question is: is the image wrong or is it my code?...
I'll keep digging a little more...
Yves
Mathieu Malaterre
> Bonjour Mathieu (and the rest of the gang...)
>
> I looked at the image and I did found the problem :o)
>
> The image advertise a predictor (Ss) value of 6, but if I change this
> to 2 it is O.K.
>
> Now the question is: is the image wrong or is it my code?...
>
> I'll keep digging a little more...
Just for the rest of the gang.
Using Ss=2, kind of gives a much better result, but this is not enough.
When using Ss=2, the center of the image becames wrong, whereas it seems
to be properly decompressed, when using an unpatched jpeg lossless
decompressor.
Mathieu
Mathieu Malaterre
> Mathieu,
>
> I have looked at this file, and it was indeed LAST written out with my
> toolkit (DicomObjects), so I agree with David's earlier comments that
> it is important know exactly HOW the image has got from the original
> equipment to the file that you have made available. In particular, I
> would be very interested to know in which transfer syntax it had been
> encoded when read/received by my tookit, as DicomObjects only recodes
> where strictly necessary, so I would very much like to know whether
> this ws simply "passed through" unchanged, or whether the problemmatic
> encoding is my fault (in which case I would wish to check this out
> throroughly). Interestingly, I can read and display the image fine,
> but that does not men it is OK, as I have many workarounds for known
> common errors in other codecs (such as the old GE one which we all know
> about!).
As a side note anyone here as an example of this bug, I'd like to add a
sample DICOM file to gdcm test suite. Thanks.
> Can you please reply directly to me as well as the newsgroup, as I will
> be travelling for the next few days, and may not be following the
> newsgroup.
>
> BTW - I plead not guily on the UIDs.....I have plenty of proper ones to
> use !
Well I guess gdcm anonymizer is not very good at anonymising. I'll have
to review the process.
Sorry for troubles,
Mathieu
Mathieu Malaterre
> Mathieu,
>
> I have looked at this file, and it was indeed LAST written out with my
> toolkit (DicomObjects), so I agree with David's earlier comments that
> it is important know exactly HOW the image has got from the original
> equipment to the file that you have made available. In particular, I
> would be very interested to know in which transfer syntax it had been
> encoded when read/received by my tookit, as DicomObjects only recodes
> where strictly necessary, so I would very much like to know whether
> this ws simply "passed through" unchanged, or whether the problemmatic
> encoding is my fault (in which case I would wish to check this out
> throroughly). Interestingly, I can read and display the image fine,
> but that does not men it is OK, as I have many workarounds for known
> common errors in other codecs (such as the old GE one which we all know
> about!).
As a side note anyone here as an example of this bug, I'd like to add a
sample DICOM file to gdcm test suite. Thanks.
> Can you please reply directly to me as well as the newsgroup, as I will
> be travelling for the next few days, and may not be following the
> newsgroup.
>
> BTW - I plead not guily on the UIDs.....I have plenty of proper ones to
> use !
Well I guess gdcm anonymizer is not very good at anonymising. I'll have
mathieu
away. Nice job Yves!
The patch for ijg+lossless patch can be found here:
http://www.creatis.insa-lyon.fr/~malaterre/gdcm/GEMS/yves.patch
Mathieu