How to create a valid dicom image

[Martin]

Hi,

I am trying to feed the Philip's Achieva MR scanner with postprocessed images. I send the original images to the dcmtk's storescp and execute a script which filters the images. Then I use dcmdump -> dump2dcm -> dcmodify approach to generate new valid dicom images
from the original data and store them in a dicom node from where I can fetch back to the scanner.

The problem is how to generate a valid dicom header, which the scanner would accept as a new image series. Initially I only modified SeriesDescription, SeriesNumber and the ProtocolName and kept all the UIDs as in the original images. If the original images where NOT on the scanner, the scanner accepts the filtered images. However, it refuses
them if original is in the database and it complains that a duplicate image objects are being inserted to the database. I searched Google's dicom discussion group and found that I should also changed the UIDs. So in dcmodify I additionally used -gse -gin options to generate new UIDs. But now the scanner refuses the filtered images complaining about UIDs.

I am sure that someone on this list has already been through this kind of problem, so I would appreciate if I could be pointed to the right direction.

Thanks a lot in advance,

Martin

[Marco Eichelberg]

At the very least, you should exchange the Series Instance UID plus the SOP instance UID for each postprocessed image. The Series Instance UID needs to be changed consistently (i.e., only one new UID generated and then assigned to all post-processed images that had the same Series Instance UID before), while the SOP Instance UID should be generated uniquely for each instance (file).

[Michael Onken]

Hi Martin,

it is correct to generate new UIDs for the postprocessed images. What kind of error does the scanner report, when you are sending images with the new UIDs? Could you give a verbose error message or something?

Regards,
Michael

[Martin]

Thanks for your answers, Marko/Michael,

I had a tough time to get to the scanner today. Lot's of exams, but finally. The log on the scanner says it exactly where is the problem:

• Application name invalid in the input data object: Non-Philips dicom onject detected. SOPInstance (1.2.276.0.7230010.3.1.4.0.17094.1164271409.2) Non-native Philips object detected; skipping.

The SOPInstance is of course the same as the one in the image.

Any ideas, how to get (safely) around this. I spent really a lot of time getting this together and it has significant impact on what we are doing.

Thanks a lot.

Martin

[Marco Eichelberg]

Non-Philips dicom object detected

This sounds to me as if the scanner is checking whether or not the SOP Instance UID of the image is from the Philips UID space (which is typically starting with 1.3.46). If this is the case, then

• There is no safe way of generating UIDs that the modality will accepts, since you cannot just use the Philips UID space which is their intellectual property, registered with ISO exactly for the purpose of preventing anyone else from using it in an arbitrary manner
• This is also a violation of the DICOM standard which explicitly forbids applications to assume any specific structure or meaning within a UID.

That said, as long as you keep the images for yourself and don't ever make them available outside your institution, you could of course try to generate UIDs that look as if they come from a Philips system and see if that helps. The easiest way to do this is to compile DCMTK from soure code with a pre-defined value to SITE_UID_ROOT. After running configure or CMake (depending on the operating system you are working on), you could edit dcmtk/config/include/dcmtk/config/cfunix.h or cfwin32.h and add

Code: Select all

#define SITE_UID_ROOT "1.3.46.670589.9999"

and then compile DCMTK as usual. The resulting tools will always generate UIDs starting with this sequence of characters, which is from the UID space allocated to Philips Medical Systems. As noted above, legally speaking you are not allowed to create and use such UIDs, so the resulting objects should never be published, and if sending such objects to the PACS causes problems, then you'll be on your own.

[Martin]

Hi Marco,

thanks for suggestions and warnings. I WILL take them seriously. I would be happy to see the filter in "production", but not in price of any kind of troubles.

I set the SITE_ROOT_UID, regenerated the images, fetch them on the scanner and it accepted them. However, when I tried to fetch also the original images along with the newly generated ones, the scanner refused to store the second series, complaining that I am trying to store a duplicate object in the database. Here is how I use dcmodify to regenerate UIDs and few other tags:

Code: Select all

dcmodify -ma SeriesDescription="${SERIESDESCRIPTION}" \
         -ma SeriesNumber="${SERIESNUMBER}" \
         -ma ProtocolName="${PROTOCOLNAME}" -gse -gin ${INPUT}.dcm

You may remember, I use MRe images, so the whole image dataset is tored in a single file. I checked the modified tags with dcmdump and I found that SeriesDescription, SeriesName and ProtocolName are modified correctly. However, not all the SeriesInstanceUID and SOPInstanceUID where chnged. I found 4 instances of 0020,000e in my file and only the last one was regenerated. For the SOPInstanceUID, I have $NUMBER_OF_FRAMES + 1 instances of 0008,0018 and only the first one is modified. So I was wondering, if dcmodify is MRe "enabled" and if multiple and unmodified UIDs could be the reason, why the scanner resfuses to insert the second series object?

Thanks for help in advance,

Martin

[Michael Onken]

Hi Martin,

dcmodify uses no intelligence for specific SOP Classes. When using the -gse and -gin options, just the attributes at the main level are modified - attributes nested in sequences are not touched by these options.

I'm not familar with the MRe objects, but I wonder that there could be the same information (Series Instance UID, SOP Instance UID) at the main level and also in a sequence? Or do these sequence attributes reference some series and instances with a different value? In the second case, you should leave those values in sequences alone to preserve the references. For the first case, you have to patch dcmodify (mdfdsman.cc), and change the startInsert() call in the generateXXXUID() functions to a call to modifyAll.

One also could use the -ma function on the command line for changing all the occurences of an UID, too. For this, you would have to write a mini program, that generates a UID on demand and then use this new UID in every call to dcmodify as UID value input for -ma option to modify Series and Instance UID.

Regards,
Michael

[Martin]

Thanks for help Michael,

hacking to the dcmtk sounds challenging, but I went so far with this work that I accept it. Let's see where I can get.

Martin