Re: Overlay in DataSet CompressedSamples^RG3

Bonjour Mathieu,

Yop, TomoVision use PVRG for lossy JPEG decoding. (I had to write my
own decoder for lossless JPEG because of the bugs found in some 16
bits images... Maybe you should add some of these to your "hall of
shame"?)

Indeed this is a compression problem, the pixel in question is
decompressed as "1024", and this is an overflow. The structure is
unsigned with 10 bits, so the largest valid value should be 1023. If
you remove the "overlay" bits, the pixel falls to "0'.

I did patch this some time ago and I now clip the JPEG lossy
compression results to the max values. Are you using an older version
of TomoVision?

And I also "clean up" any "unused" bits. I don't think you can use
the trick with the 0x60xx elements since I did run acros some older
images that had stuff in the higher bits even without the 0x60xx tags
being present.

Yves


On Fri, 4 Jan 2008 06:15:05 -0800 (PST), Mathieu Malaterre
<mathieu.malaterre@xxxxxxxxx> wrote:

hi,

Since the early beginning of GDCM we have always been 'cleaning up'
the unused bits of the Pixel Data just in case an overlay would be
found.
This is extremely time consuming, and I was running some test to
check if I could simply run the cleanup only when a 0x60xx element was
to be found. It works on all but one gdcmData files we have been
gathering.

the only exception is the Dataset CompressedSamples^RG3, from the
compressed jpeg in WG04, see file

ftp://medical.nema.org/medical/dicom/DataSets/WG04/compsamples_jpeg.tar
-> IMAGES/JPLY/RG3_JPLY
(1.3.6.1.4.1.5962.1.1.11.1.5.20040826185059.5457)

Clearly the DataSet does not declare any Overlay, but still one
cannot simply load the dataset without cleaning up the unused bit.
When loading the image, the IJG (the jpeg lib used in GDCM) is
complaining about

"Invalid SOS parameters for sequential JPEG"

I am wondering if the artefact I am seeing is not simply due to a
poor jpeg encoding in which case I could detect that instead of
looping over the whole image in quest for a potential artefact.

* TomoVision is apparently using the PVRG jpeg lib and has the exact
same artefact as we do (a bright spot in the center right image).
* DicomWorks is not properly displaying the image, but does not show
the artefact.
* IrfanView is simply crashing.

Thanks for comments
-Mathieu
.

Relevant Pages

  • Re: Overlay in DataSet CompressedSamples^RG3
    ... TomoVision use PVRG for lossy JPEG decoding. ... pixel is 0, but image is MONOCHROME1 so pixel appears as very bright). ...
    (comp.protocols.dicom)
  • Re: Overlay in DataSet CompressedSamples^RG3
    ... own decoder for lossless JPEG because of the bugs found in some 16 ... you remove the "overlay" bits, ... pixel is 0, but image is MONOCHROME1 so pixel appears as very bright). ... looping over the whole image in quest for a potential artefact. ...
    (comp.protocols.dicom)
  • Overlay in DataSet CompressedSamples^RG3
    ... Since the early beginning of GDCM we have always been 'cleaning up' ... Clearly the DataSet does not declare any Overlay, ... the IJG (the jpeg lib used in GDCM) is ... looping over the whole image in quest for a potential artefact. ...
    (comp.protocols.dicom)
  • Re: Overlay in DataSet CompressedSamples^RG3
    ... TomoVision use PVRG for lossy JPEG decoding. ... you remove the "overlay" bits, ... pixel is 0, but image is MONOCHROME1 so pixel appears as very bright). ... looping over the whole image in quest for a potential artefact. ...
    (comp.protocols.dicom)
  • Re: Overlay in DataSet CompressedSamples^RG3
    ... Jasper decoder because it ... TomoVision use PVRG for lossy JPEG decoding. ... pixel is 0, but image is MONOCHROME1 so pixel appears as very bright). ... same artefact as we do. ...
    (comp.protocols.dicom)