Posts by dclunie

I got the CD image thanks.

It contains no problems with the encoding of the multi-frame images; further all of the images (formerly JPEG presumably) have been decompressed, since the CD is presumably written to the General Purpose CD Profile, which does not allow compression. The color space had also been transformed to RGB, which means anything can view them, which is nice. There are some ultrasound-specific header attributes that are bad but that is presumably propagated from the original Acuson, and they are relatively harmless.

So obviously the Centricity has good data inside and is capable of processing it "properly" when writing a CD.

Why the other "export" mechanism you described screws up remains a mystery (you should file a bug report about that with your local GE FE, if I didn't already mention that).

As for transferring to Conquest, it would seem expedient to try and find a way to have Conquest refuse the JPEG transfer syntaxes from this source (or at all) ... that would force the Centricity to do the decompression and hopefully color space transformation as well. Since I don't use Conquest, I do not know off hand how to do that, but I am sure there is a way.

David

rapidshare says the file has been deleted

If you want, you can put it on my site at:

http://idisk.mac.com/dclunie-Public/

if that is less hassle than rapidshare.

David

Quote

Within centricity, I exported the series to be stored on my desktop in dicom. I zipped it and uploaded it.

This step certainly does not seem to be producing valid DICOM files as per the previous discussion - when you performed this export, did the application offer you any options with respect to how the export was to be performed (e.g., as a single DICOM multi-frame file or seperate single frame files ?). Regardless, whatever errors are present in this export process may not be relevant to your primary question, which is how to transfer these over the network. You should report this incorrect export as a bug to your GE field engineer.

You might also try burning a CD of the exam from within Centricity, and then passing along the files that are stored on that CD - that might work better than using the "export" function (or maybe not).

As far as the network transfer is concerned, the dump from the GE workstation would seem to imply that the images is a JPEG lossy YBR_FULL_422 image with all the frames in a single object, which should be fine - perhaps the receiver you are using just doesn't support this correctly; have you tried sending the images to another open source tool, say the OFFIS dcmtk storescp utility - it allows you to be selective about what transfer syntaxes are accepted so you could explore what works and does not work with Centricity. You could probably also obtain a "correctly exported" version of the multi-frame JPEG file (use +B bit-preserving option in storescp to get this) that you could share for others to test with, which would be a more accurate representation of what Centricity is trying to send over the network.

David

Andreas brought this discussion thread to my attention.

I would concur with his assessment that if a private form of pixel data compression is to be used then a private transfer syntax is required.

It is not legal in DICOM to transfer a standard SOP Class with the image pixel data encoded inconsistently with the standard Transfer Syntax, whether that pixel data be buried in a private attribute or in the standard (7FE0,0010) attribute; it is required that (7FE0,0010) be present and encoded in a manner consistent with the transfer syntax.

I have observed this before with Conquest and the NKI compression, but decided not to make an issue of it, but since the question was asked ... I would strongly advise that this inappropriate NKI behavior either be removed from the code completely or implemented "properly" using a private transfer syntax. It would be extremely improper for folks to start accumulating archives full of images that claimed to be in a standard transfer syntax but were actually not.

Also, I did take a look at those very wierd ultrasound images in the CINE.zip file that was posted ... some system (presumably Centricity) has really screwed those up, by splitting them into single frames in separate files; as Andreas noticed, the UIDs are the same ... actually the entire header for each file is the same, and if you cut out the pixel data and concatenate it and reassemble them into a single file with the same header it makes a not perfect but displayable US multi-frame image; the remaining problem is that it has an incorrect Photometric Interpretation - specifically if claims to be YBR_FULL_422 but is really YBR_FULL.

Anyway, I mention this file because I would be interested in knowing the exact heritage of the file (how ti was passed from system to system), primarily so as to know whether or not I should start ragging on the Centricity guys about incorrect handling of US multiframe images or not.

David