Conquest and Ultrasound

I also found problems with certain Accuson US images when using Conquest with NKI private compression. This is most certainly caused by the fact that NKI uses private tag 7fdf,0010 for pixel data whereas Accuson uses the same private tag for other data.

In my opinion, the desicion to use a private tag for pixel data was not a good one in the first place. A more appropriate way would have been to use a private transfer syntax and store images with a meta header.

And even with a private tag for pixel data, you should not have used 0010 because the first unused element in a private group is reserved for a private code mark to specify the creator of this group (in order to avoid the above problems).

Regards,
Andreas

I checked the first set of US images and they displayed correctly in K-PACS. Sending to Conquest (1.4.12) and receiving from Conquest worked as well. You should activate advanced debuglog in Conquest in order to catch the stops and lock ups.

The multiframe (cine) US image is strange. Although it says 43 frames, K-PACS seems to fail to find the frame offsets. I will check what is going wrong.

Regards,
Andreas

The Cine series is indeed strange. There are 43 files, although the header says 43 frames, every file contains only one frame. This is in violation of the DICOM standard.
Even more problematic is the fact that every file has the same SOPInstUID which is definitively a violation of the standard.

Regards,
Andreas

Hi Lambert,

Quote

AndreasKnopke wrote:
In my opinion, the desicion to use a private tag for pixel data was not a good one in the first place. A more appropriate way would have been to use a private transfer syntax and store images with a meta header.

Quote

And then hope that every vendor will support that transfer syntax; not very realistic...

No, there is no nead at all that this transfer syntax is supported by a third party. These file are for internal use only and this could remain that way.
With a private TS you could avoid the use of private tags (which might be occupied) and give a third party application a chance to reject the image without having to find out what the transfer syntax is by advanced investigation. When sending the images via C-Store, Conquest uncompresses the image and recreates the metaheader.

You could even propose your private TS in a C-Store association (along with LittleEndianImplicit). Marcel once implemented NKI support in K-PACS's viewer class. We could use NKI for a faster image transfer.

Regards,
Andreas

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

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

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

in order to find out why the iQServer fails to store the images you can start it manually in verbose mode.

To do so open a windows command shell (start->run->"cmd") and go to the server's directory ("cd" for change directory)
run it like

iqserver.exe -d -dw -od "c:\program files\iq-View\server\database" -aet iQSERVER 104

Make sure that iQSERVER is not already running

Please post the command shell logs.

Regards,
Andreas

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

Yes, the server complains about a lot of non standard VR's. The parser probably looses offset because auf an invalid group length.

What you could try is the following:
since iQSERVER is a modified OFFIS STORESCP.exe, all OFFIS parameters work for it as well.

run the server manually again and try different options, for instance

iqserver.exe -d +B +xi -dw -od "c:\program files\iq-View\server\database" -aet iQSERVER 104

for bit preserving (write dataset exactly as received) and implicit only transfer.

You could also try the +g option (create group length)

If it still fails to receive the images, please mail me the logs with the different options again. If not, then tell me the parameter you used that I can implement it into the server administration as a compatibility option.

Regards,
Andreas