[Insight-developers] DICOM UID Generation + Mac address

[Lorensen, William E (Research)]

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