Re: Building a DICOM Series
I ran into the same problem Christoph had below of building a series of
dicom images from another image format. Im using imtntodc to create
DICOM files from imatron images.
The approach I used is use imtndump to retrieve the number of images in
a given imatron file. Then based on that I use -image to create a
dicom image for each slice in the imatron file. This created all the
slices but they did not belong to the same series, causing each slice
to be its own DICOM series and even its own study.
I then found your post below which detailed to use the -stamp option.
When using this option the DICOM files now belong to the same Study and
series, but also each dicom file now has the same SOPInstanceID causing
my dicom viewer to import/show only one of the dicom files when
importing the whole series. I believe it thinks that each dicom file
is the same one and importing only one.
Am I using imtntodc and the -stamp option properly ( i.e. imtntodc
-image 1 -stamp $stamp 12345.1ab 1.dcm) ? Is there another way to
Christoph Thomas wrote:
> Hi all,
> I am a DICOM-newbe and I'm using a perl script calling dctopnm and
> rawtodc from dicom3tools to manipulate pixel-data of a number of
> DICOM-CT-images and to build new images.
> Naturally, rawtodc tool builds single, in terms of UID independent
> images. What do I have to do to connect these into a series, like
> their templates are?
The default UID generation in this family of tools is relatively
primitive and makes use of a UID root (that you have to specify
in advance before configuring and compiling the tools), a
timestamp and successive numeric values derived crudely from
the StudyID, Series Number and Instance Number.
Multiple invocations of the tool will use different timestamp
In a script to make multiple instances that need to have the
same timestamp across Study, Series and Frame of Reference,
I usually use the -stamp command line argument to specify
the value to be used for the timestamp, and set it to
that includes not only the time but also the process number
in case there are two simultaneous invocations on the same
Note that for your UIDs to be globally unique, which is
mandatory, you must have your own UID root, which you specify
during the configuration phase by:
1. get a (free) UID root; see for example:
2. editing "config/site.def-p" to specify a definition for
your UID root
3. during installation, as described in INSTALL, do an
"imake -I./config -Dxxxx", where xxxx is the definition you
created in "config/site.def-p" to invoke use of your UID root