[Insight-developers] DICOM UID Generation + Mac address

[Stephen R. Aylward]

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