DICOM @ OFFIS

That worked... Thanks, Michael

The only difference in your test is the OS. It's probably something specific to the Windows code... C:\>dcmcjpeg_ori +un +ho +rm +q 90 +eb xa_original.dcm xa_lossy.dcm -v -d reading input file xa_original.dcm Convert DICOM file to compressed transfer syntax <--- crashes after this C:\>dcmcjpeg_ori -...

I'm trying to compress a file using the precompiled Windows binaries. It's a XA multiframe file, you can download it from: http://rapidshare.com/files/142877809/xa_original.zip.html Lossless compression works fine, but lossy compression does not. This is the command I use: dcmcjpeg +un +ho +rm +q 90...

Just reporting a tiny bug... I have an image generated by a Toshiba Aquilion that has empty pixeldata (zero length). That's weird but not the point :P Compressing this image works, decompressing it does not (DcmFileFormat::saveToFile() fails). So I have a Dicom server that received, compressed and s...

That link doesn't work here... But the reason makes perfect sense. Matter of fact, I remember thinking about that when I was writing the code for the UN conversion.

Thanks for the help, Michael :-)

Ohh, I see ... But why is that? Whats the reason to always use implicit VR?

And what about dcmcjpeg and dcmdjpeg?

I had an image in Implicit Little that my application encoded as Explicit Little. I wanted my code to treat an unkown data element (not in my dictionary) with undefined length as a sequence, but I made a mistake and it encoded it as UN. I wanted it to be SQ. Here is the resulting image http://rapids...

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 s...

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 sca...

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 famili...

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 t...

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...

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 th...

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 i...

hmmm... Still doesn't work here... Added this at the top of my scaling function 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...