[Insight-developers] DICOM UID Generation + Mac address

Thu Jan 20 16:03:39 EST 2005

gdcm has a UID generator. Right now (recently), itkGDCMImageIO uses the gdcm
generator to generate UIDs without any application knowledge. I'm advocating
that we take that code out of itkGDCMImageIO and put it in a class that will
be accessible outside of the reader/writer mechanism.

Bill

-----Original Message-----
From: Stephen R. Aylward [mailto:aylward at unc.edu]
Sent: Thursday, January 20, 2005 2:05 PM
To: Lorensen, William E (Research)
Cc: 'Mathieu Malaterre'; Miller, James V (Research); Insight Developers
Subject: Re: [Insight-developers] DICOM UID Generation + Mac address

Hi,

I think this is a great idea.  Also - Luis has developed a "unique token 
generation class" that is used by the IGSTK toolkit.

Perhaps there is enough commonality to have a set of methods (classes) 
for unique ID generation - the UID generator would be a subclass...

Stephen

Lorensen, William E (Research) wrote:

> I have a suggested solution to the dicom UID issue. As David Clunie
pointed
> out, there are some apliication level decisions that affect UID's. I
propose
> an itk filter that will allow you to specify a patient/study/series/image
> hierarchy. It would populate the MetaDataDictionary of the input with the
> appropriate info (the Dicom subclass of this filter would generate UID's).
> The filter would pass the output through along with the new meta
dictionary.
> This way we can isolate the "application specific" UID fields. For
example,
> when I process images in batch, one file at a time, I could pass the
> patient, study, series into the application. Also, validation of the DICOM
> tags could take place. We could also add an anonymization subclass
> eventually...
> 
> Let's discuss at tomorrow's t-con.
> 
> Bill
> 
> -----Original Message-----
> From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
> Sent: Wednesday, January 19, 2005 3:21 PM
> To: Miller, James V (Research)
> Cc: Insight Developers
> Subject: Re: [Insight-developers] DICOM UID Generation + Mac address
> 
> 
> Jim,
> 
> 	See my comments interlaced,
> 
> 
>>So we want to send the prefix 
>>
>>1.2.826.0.1.3680043.2.1125.1.
>>
>>to the GDCM generation code.
> 
> 
> Sorry I forgot. This is done in my local dir (not commited yet).
> 
> 
>>I don't think you need to tack the image number onto the instance UID.
> 
> Are
> 
>>you
>>concerned that the clock value will not have enough resolution to ensure a
> 
> 
>>unique value for two adjacent images?
> 
> 
> See (*),
> 
> 
>>Along these lines, there shouldn't be a reason to tack any particular
>>suffix onto Study Instance UID, Series Instance UID, and Frame of
> 
> Reference
> 
>>UID. The UID's are not meant to be parsed.  So the only important thing
>>that the UID's are unique.  If the algorithm of MAC + Date + Time will
>>give a unique UID, then there is no need to use the additional UID space
>>to distinguish the type of UID.
> 
> 
> Seems like Study / Serie Instance UID have to remain the same while 
> writting the serie. And looking at the image header in 
> Testing/Input/Data we need to differenciate Serie from Study. So the 
> generation order could be:
> 
> //mutex_lock
> study = CreateUniqueUID()
> serie = CreateUniqueUID()
> //mutex_unlock
> 
> while(images)
>    imageid = CreateUniqueUID()
>    WriteImage( study, serie, imageid)
> 
> 
> 
>>Are you ensuring that the UID's do not exceed the size limit of a UID?
> 
> 
> I also forgot this one. I put a check if size if above 64 characters. 
> But for now I don't have any implementation in mind to rehash the uid 
> (without prefix). I thought of md5 but I am not sure it's portable. Any 
> ideas/comments ?
> 
> 
> 
>>Finally, what about multitasking environments where two processes might
>>try to write a DICOM image (albeit a different image) at the same time?
>>Based on a MAC+DATE+TIME algorithm, two processes could generate the same
>>UID.  Should we encode the "process/task number" into the UID? (I guess 
>>this could be taken a step further where a single process has multiple
>>threads where each thread may write out an image (albeit a different
> 
> image)
> 
>>at the same time.  In this case, we would need to encode a "process +
> 
> thread
> 
>>number" into the UID.
> 
> 
> I try to implement this. The process ID is easy to get on POSIX system, 
> and there is a Win32 call to find it. But the thread id is really far 
> from trivial to find. Furthermore they are both express as unsigned int. 
> Which is way too much information for us. Practically this shouldn't be 
> too big, but for a system with a big uptime I though this number could 
> reach the limit of int...
> 
> Since we only need an identifier which would be different from one 
> thread to the other, I think we only need a global identifier. For 
> example a static function (with mutex lock) which would increment a 
> number. Therefore we are garantee to start from 0 at begining and the 
> number is always incremented (even within a thread).
> 
> How does that sound ? (*)This is just the fancier version of my previous 
> image number increment...
> 
> Finally there is a definition of what should be a UUID:
> http://www.opengroup.org/onlinepubs/009629399/apdxa.htm
> 
> Which seems to implemted for:
> http://linux.about.com/library/cmd/blcmdl3_libuuid.htm
> 
> It's too bad it's platform dependant but looks rock solid to me (and 
> they don't seems to be using thread/process id).
> 
> As a side note I never tested gdcm in a multi threaded environment...
> Mathieu
> 
> 
>>-----Original Message-----
>>From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
>>Sent: Monday, January 17, 2005 4:32 PM
>>To: Insight Developers
>>Subject: [Insight-developers] DICOM UID Generation + Mac address
>>
>>
>>Hello,
>>
>>	Ok I think I am pretty much done with the DICOM stuff in ITK for the
>>
>>release. I just want to double check with you it's alright.
>>
>>1. GDCM take also in account the "Serie Instance UID". Therefore even if 
>>there are two seriies (same study) within the same dir, only one will be 
>>picked.
>>
>>2. GDCM now uses the new ITK DICOM radical to generate the DICOM files. 
>>So far I overrides:
>>
>>[SOP Instance UID]
>>[Media Stored SOP Instance UID]
>>[Study Instance UID]
>>[Series Instance UID]
>>[Frame of Reference UID]
>>
>>And the algorithm is:
>>
>>uid = s1 + s2 + s3
>>
>>s1 = 1.2.826.0.1.3680043.2.1125 // ITK radical
>>
>>s2 = Mac address
>>
>>s3 = Date + Time
>>
>>
>>Then for "SOP Instance UID" I also append the image number. I did a 
>>static int, and I increment it each time I write the image.
>>
>>The only remaining -potential- problem is for Study Instance UID, Series 
>>Instance UID and Frame of Reference UID. I am not sure what people 
>>usally append to those strings. I'll investigate, meanwhile I just put a 
>>different number for those 3. (any comments David?)
>>
>>
>>The implementation for the Mac address gave me a lot of troubles, so 
>>there is a chance it does not work on your plateform. So far I only 
>>tested it on Linux, MacOSX, Sun Sparc and Win32.
>>
>>Mathieu
>>
>>
>>_______________________________________________
>>Insight-developers mailing list
>>Insight-developers at itk.org
>>http://www.itk.org/mailman/listinfo/insight-developers
>>
> 
> 
> 
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers

-- 
===========================================================
Dr. Stephen R. Aylward
Associate Professor of Radiology
Adjunct Associate Professor of Computer Science and Surgery
http://caddlab.rad.unc.edu
aylward at unc.edu
(919) 966-9695