dcmdjpeg of Acuson US images giving strange colors

[mday]

We are running into a strange problem where some of our US images that we decode with dcmdjpgeg end up with strange colors when viewed on our PACS (Impax) or with eFilm. These are UltrasoundImageStorage SOP instances, stored with a JPEG Lossless, Non-hierarchical, 1st Order Prediction transfer syntax, and YBR_FULL photometric interpretation. Neither of these SCPs will accept the native transfer syntax, so we decode them with dcmdjpeg into big endian explicit, and transfer them with our tools that are built on dcmtk (3.5.3), or with storescu. I've tried both the dcmdjpeg default of converting them to RGB, as well as using the +cn flag to prevent conversion from YBR_FULL to RGB. We get the incorrect colors in both cases.

I have access to a 'ddo_expand' command on our IMPAX system which will also decode the JPEG transfer syntax into an uncompressed one, and when I use this to decode the files and then send them with storescu, I get correct colors on the remote end. Either there was an error in the original encoding, and the Mitra ddo_expand knows how to compensate for it, or dcmtk is having a problem with converting this particular data. If I were a betting man, I would bet on the former explanation, but I don't have the tools/expertise to determine which of these explanations is correct. Has anyone run into a similar problem with Acuson files? Any insight on what a fix might be, or how I could characterize where the decoding may be going wrong?

Thanks,
Mark Day
UCSF

[Jörg Riesmeier]

You could send the image (both compressed and "properly" uncompressed) to dicom/at/offis/dot/de. This would allow us to check what the problem might be.

[mday]

That's a very kind offer, but unfortunately these images have burned in patient identifiers, and institutional and federal HIPAA rules prevent us from sending such images without a business associate agreement. I've investigated the matter a little more, and I can ddo_expand the images, then dcmcjpeg / dcmdjpeg them without problem. We're currently evaluating all of our options, but are leaning torward putting all 900,000 of the images through the ddo_expand -> dcmcjpeg 'cleansing' process, and storing them back in our archive.

The other interesting tidbit I've learned s that the time frame for images that have these problems coincides with when we upgraded from IMPAX 3.5 -> 4.0. It could be that the images were compressed incorrectly on IMPAX 3.5 (and not on the modality), and the IMPAX 4.x code knows how to workaround this bug in the encoding.

[Marco Eichelberg]

You might also try out two command line options in dcmdjpeg which modify the way the tool handles color space conversion:

Code: Select all

    +ca   --conv-always          always convert YCbCr to RGB
    +cn   --conv-never           never convert color space

You should note, however, that enabling these options may cause incorrect color output with perfectly correct compressed images, so you would have to somehow recognize the incorrect images and use dcmdjpeg with this option only on those. Usually there are some header fields that could be used to detect the incorrect images).