Re: debian OID / dicom3tools packaging
On Tue, Jan 27, 2009 at 2:22 PM, Andreas Tille <tillea@rki.de> wrote:
> On Tue, 27 Jan 2009, Mathieu Malaterre wrote:
>
>> the ideal solution would be indeed that a conf file would indicate
>> what is the root UID being used. GDCM has one, DCMTK has one. David
>> Clunie (author of dicom3tools) has one, SIEMENS, GE, Philips, my
>> actual company.
>>
>> the problem is for one time user, converting a MINC file to DICOM. Any
>> larger organisation would have there own UID, but would need to
>> -painfully- recompile dicom3tools.
>
> I'm actually not positively sure whether I understood the problem right
> but it sounds like the UID is compiled into the binary code but has to
> be specific to the user who is using the software.
Works just like DCMTK / GDCM. When you distribute your produced DICOM
file out there, you are saying "hey this instance is unique, and it is
using this particular UID".
> So IMHO having a
> Debian UID means that a user with a debian.org address might use the
> package but no user of the Debian package who is working for SIEMENS,
> GE, Philips, etc.
I am using GDCM root uid all the time. But I see not reason to use
this root, when using dicom3tools, that is not required.
> If a user has his own UID it makes no sense to compile this into the
> package, right?
For large institution that would make sense. this allow them to track
their own instance more easily. For most user, they see DICOM as an
image format, so I do not see the point. For instance I can bet you
there has never been any report for such feature for dcmtk. By default
it is using the one compiled in and so far so good :)
> So *if* my interpretation of things is correct I see two options:
>
> I. Ask upstream to enable putting the UID in a configuration file.
> This most probably is a clean, safe and flexible solution.
Again no one ever complained for DCMTK/GDCM.
> II. Enable the user to make recompilation much less painful.
> Well, this is surely not a really nice solution, but if there
> is no other option something like this comes to mind:
>
> 1. Build a wrapper package which via debconf asks for a
> UID and unpacks a source tarball
> 2. Patch the source to include the UID.
> 3. Setup build dependencies properly in a chroot / use
> pbuilder to compile the package.
=O
I am /not/ volunteering for that. :)
> Well this sounds really stupid compared to I. and thus I would
> definitely prefer I. but I see no other option if the UID is *really*
> included in the binary.
Nothing restrict you for running your dicom3tools generated image
through let say dcmtk --uid-always / gdcm to regenerate new uids if
you really want to control those kind of low level details.
--
Mathieu
Reply to: