problem with scaling (RGB multiframe)

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
GabrielBianco
Posts: 21
Joined: Tue, 2006-03-21, 00:06

problem with scaling (RGB multiframe)

#1 Post by GabrielBianco »

I have some problems scaling a multiframe RGB image:

1) If the file is compressed (lossless jpeg) and I attempt to scale it down it outputs the same file (no scaling was done).

2) Doing the same as above but if the output file is the same as the input file, it seems to create an invalid image. The file seems to be OK, but ezDicom can't process the pixeldata properly ("Unable to read this file - is this really a JPEG image?")

3) If the file is not compressed, the image gets scaled but the colors are wrong.

Heres the code I use:

Code: Select all

DcmFileFormat fileformat;
OFCondition error = fileformat.loadFile( input );

... // deal with bad input

DcmDataset *dataset = fileformat.getDataset();

DicomImage* di = new DicomImage( &fileformat, dataset->getOriginalXfer() );

DicomImage* rescaledDi = di->createScaledImage( oColumns, oRows, 1 );
		
bool b = rescaledDi->writeImageToDataset ( *dataset, 1 );

fileformat.saveFile( output );
		
delete di;
delete rescaledDi;
I'm not using the returned value of 'writeImageToDataset()'. I just assume if the output file is created it is alright, which might not always be a good assumption but I don't think that's the matter here...

I get similar results with dcmscale.exe:
Using "dcmscale.exe +Sxv 500 input out" I get an error if the input file is compressed ("ERROR: cannot change to unencapsulated representation for pixel data !").
If it is not compressed, the image is scaled down, but the colors are wrong.

You can get the image I'm using here (3MB):
http://rapidshare.com/files/2545784/scaling_trouble.rar (JPEG Lossless)

What am I doing wrong?

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1435
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#2 Post by Marco Eichelberg »

In order to work with compressed images in the DicomImage class, you have to register the decompression codecs (in your case, the JPEG decompression codec) at application startup. Essentially, this is a single call to

Code: Select all

DJDecoderRegistration::registerCodecs(opt_decompCSconversion, EUC_default, EPC_default, debugMode);
Secondly, if I decompress the image with dcmdjpeg before feeding it to dcmscale, the scaling works correctly for me - all colors look right.

GabrielBianco
Posts: 21
Joined: Tue, 2006-03-21, 00:06

#3 Post by GabrielBianco »

hmmm... Still doesn't work here...

Added this at the top of my scaling function

Code: Select all

DJDecoderRegistration::registerCodecs(); // register JPEG codecs
It does create file, but with a new bug :P
The created file is larger than the input and ezDicom can't read it. Its transfer syntax is set to JPEG Lossless, even though it is actually larger than the input file (it was scaled down). After manually hacking the transfer syntax to Explicit Little, ezDicom can read it but the colors are still messed up...

Using the latest dcmtk binaries (redownloaded them 5 minutes ago to make sure I'm not using the wrong version):
dcmdjpeg.exe compressed uncompressed
dcmscale.exe +Sxv 500 uncompressed scaled

It works in the same way I described before (the colors are not right)... :(

Maybe a screenshot will help...
http://img227.imageshack.us/my.php?image=ssmo7.jpg

GabrielBianco
Posts: 21
Joined: Tue, 2006-03-21, 00:06

#4 Post by GabrielBianco »

Can anyone else give this a try? Anyone really, no need to be a dcmtk developer :-)... Just to make sure it isn't something I'm doing wrong, since Marco said dcmdjpeg + dcmscale works...

Download the latest dcmtk Windows binaries, download the image I linked in the first post, unrar it, and rename it to "uncompressed".

Then execute:
dcmdjpeg.exe compressed uncompressed
dcmscale.exe +Sxv 500 uncompressed scaled

And then compare "scaled" with "uncompressed" in your favorite DICOM viewer...

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1435
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#5 Post by Marco Eichelberg »

The "wrong colors" might very well be a problem in ezDicom. The only difference I can see in the definition of the Image Pixel Module between the unscaled and the scaled image is that the latter uses color-by-plane ordering of the pixel data wheras the source image uses color-by-pixel (this can be modified through the parameters passed to the JPEG decompressor during initialisation).

The "new bug" is not really a bug in DCMTK - you have changed the pixel data, but not told DCMTK that you have actually changed the transfer syntax of the DcmFileFormat object. You should simply pass one of the uncompressed transfer syntaxes in your call to saveFile (there are various optional parameters) and this should work.

GabrielBianco
Posts: 21
Joined: Tue, 2006-03-21, 00:06

#6 Post by GabrielBianco »

Hmm... The colors are wrong in our own viewer too. IrfanView (with Dicom plugin) also shows the wrong colors.

Changing this
dcmdjpeg compressed uncompressed
to
dcmdjpeg +px compressed uncompressed

Should give us a colored by pixel image, right? But the results are the same...
Using +pl results in the same wrong color image...

Are you really really sure the scaled image is fine? How did you visualize it?

And about the "new bug", you are correct. I assumed that the call to createScaledImage() wouldn't change the TransferSyntax...

GabrielBianco
Posts: 21
Joined: Tue, 2006-03-21, 00:06

#7 Post by GabrielBianco »

By the way, the issue really doesn't seem to be with ezDicom (or any of the other viewers I tested) not supporting color by plane... They properly render the uncompressed and compressed images. The problem comes after scaling...

GabrielBianco
Posts: 21
Joined: Tue, 2006-03-21, 00:06

#8 Post by GabrielBianco »

This seems wrong:
The only difference I can see in the definition of the Image Pixel Module between the unscaled and the scaled image is that the latter uses color-by-plane ordering of the pixel data wheras the source image uses color-by-pixel (this can be modified through the parameters passed to the JPEG decompressor during initialisation).
We are scaling an uncompressed image, so there is no need to even register the JPEG decoding codec. The scaled image has it's Planar Configuration set to 1, but that had nothing to with uncompressing.

The gray areas in the image look right... Is there a way to get a rescaled image colored by pixel? We are out of ideas here...

GabrielBianco
Posts: 21
Joined: Tue, 2006-03-21, 00:06

#9 Post by GabrielBianco »

Okay, so we have managed to render the image properly... We were expecting it be like this (3 frames/3 pixels):
RRR GGG BBB RRR GGG BBB RRR GGG BBB

Instead it is:
RRR RRR RRR GGG GGG GGG BBB BBB BBB

Now the question is: is this how it should be for a multiframe colored by plane image? I'm not familiar with the DICOM specification in this point.

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1435
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#10 Post by Marco Eichelberg »

So, if I understand you correctly, our code is storing all R components of all frames followed by all G components of all frames followed by all B components of all frames, whereas your software expects separate RGB planes per frame. I need to look up the standard to see how (and whether at all) the expected encoding of multiframe images for PhotometricInterpretation=1 is defined.

GabrielBianco
Posts: 21
Joined: Tue, 2006-03-21, 00:06

#11 Post by GabrielBianco »

Yes, that's correct...

One more problem :P: to work around this I decided to, after scaling, if the image was compressed, I compress it again (because createScaledImage() is decompressing it). Problem is, that seems to work only with lossless compression.

So if I do this:
dcmcjpeg.exe scaled.dcm scaled_lossless.dcm
dcmcjpeg.exe +eb +q 100 scaled.dcm scaled_lossy.dcm

scaled_lossless.dcm is perfect, but scaled_lossy isn't (wrong colors).

So the lossless compression codec expects the multiframe colored by plane image to be in the way you described (all R components of all frames followed by all G components of all frames followed by all B components of all frames), but the lossy codec expects it in the other way (same way our software does). I would have to compress it to lossless before compressing it to lossy... Which is really no good :P

All this work could be cut off if there was a way to set the default PlanarConfiguration used by createScaledImage() to be 0. Is there a way to do this? I can't see anything in the parameters anywhere, but maybe somewhere inside DiColorImage?

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1435
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#12 Post by Marco Eichelberg »

Your problem description is correct. In fact the DCMJPEG module creates, uses and expects the same "layout" of pixel data as your viewer does, whereas the dcmimage module (which has been created by another developer of our team) uses a different one. The problem only manifests in uncompressed color multi-frame images with PlanarConfiguration=1, which seems to be a very rare encoding, since this problem has been in the code for about 8 years, without anybody ever noticing it.

Part of the problem is that the definition of the encoding of Pixel Data with PlanarConfiguration=1 is ambiguous in DICOM and allows for both interpretations. We probably need a CP in the DICOM standard to clarify which encoding is correct, and which is not.

Finally, unfortunately the scale method (and, correspondingly, dcmscale) does not permit to store images with PlanarConfiguration=0 (which would avoid the problem indeed), because the tool essentially stores the internal representation of data into the pixel data element unmodified, and the internal representation is color-by-plane.

GabrielBianco
Posts: 21
Joined: Tue, 2006-03-21, 00:06

#13 Post by GabrielBianco »

In fact the DCMJPEG module creates, uses and expects the same "layout" of pixel data as your viewer does, whereas the dcmimage module (which has been created by another developer of our team) uses a different one.
But what about that workaround I described?
So if I do this:
dcmcjpeg.exe scaled.dcm scaled_lossless.dcm
dcmcjpeg.exe +eb +q 100 scaled.dcm scaled_lossy.dcm

scaled_lossless.dcm is perfect, but scaled_lossy isn't (wrong colors).
Doesn't that mean that even the DCMJPEG module sometimes expects the pixeldata in one way and sometimes in another?

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1435
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#14 Post by Marco Eichelberg »

Doesn't that mean that even the DCMJPEG module sometimes expects the pixeldata in one way and sometimes in another?
Well, kind of. When used with lossy compression, the image is passed through an instance of class DicomImage inside DCMJPEG, and with lossless compression it is not, thus creating the inconsistency you correctly describe. It is clear that at least one implementation must be wrong (the one in dcmimage or the one in dcmjpeg and probably other modules as well), but the standard does not clearly say which one :?

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Bing [Bot] and 1 guest