Page MenuHomePhabricator

Specify default UID generation method
Closed, ResolvedPublic

Description

The default method for UID generation must be specified and provided that can be used when implementing IIdentifiable.

If possible it would be great if this default UID is already a valid DICOM UID and could be directly used.

  • specifiy the UID generation.
  • implement it

Revisions and Commits

rMITK MITK
Restricted Differential Revision
Restricted Differential Revision

Related Objects

StatusAssignedTask
OpenNone
Resolvedkislinsk
Resolvedkislinsk
Wontfixkislinsk
OpenNone
Resolvedkislinsk
Resolvedkislinsk
Resolvedkislinsk
DuplicateNone
Resolvedkislinsk
Resolvedfloca
Resolvedfloca
OpenNone
Resolvedkalali
Resolvedfloca
Resolvedfloca
Resolvedfloca
Resolvedkislinsk
Resolvedkislinsk
Resolvedkislinsk
Resolvedkislinsk
Resolvedfloca
OpenNone
Resolvedfloca
Resolvedkalali
Resolvedfloca
Resolvedfloca
Resolvedfloca

Event Timeline

floca renamed this task from Specifiy default UID generation method to Specify default UID generation method.Nov 17 2017, 11:08 AM

We should improve/adapt mitk::UIDGenerator, as it is already used by mitk::DataNode and mitk::BaseData for UID generation.

Currently all DICOMPreloadedVolumeTests and DCMPreloadedVolumeTests fail because the UID isn't read but generated on the fly, resulting in different UIDs when comparing the same data loaded twice. We need to update the readers to set the UIDs.

Tests no longer fail as there is no longer a uid property.

UID generation in general

I think UID generation is a common thing, which we should not implement on our own, but instead use a well-tested cross-platform library.

Here is a blog about some cpp libraries for UID generation: https://mariusbancila.ro/blog/2018/02/27/stduuid-a-cpp-library-for-universally-unique-identifiers/

A new library called stduuid is proposed which shall be added to the std namespace. At least the author has written a comprehensive proposal here.
The blog also mentions the Boost Uuid library and the crossguid library.

Using boost can be a fast way to get a result, because it is already included in the superbuild.
I think we should avoid being dependent on boost for too many things, as the build has sometimes trouble with Boost?

UID for DICOM

As mentioned here: https://stackoverflow.com/questions/46304306/how-to-generate-unique-dicom-uid

the standard defines in Part 5 (Data Structures and Encoding) UIDs in two ways:

The organizationally derived UID would require to follow a pattern which encodes the country code, organization, manufacturer, and such things.
The UUID derived UID would fit more to "...dynamically created UIDs, such as SOP Instance UIDs..." as mentioned in the standard.

floca edited projects, added Noteworthy, MITK (2020); removed MITK.

For mitk::UIDGenerator I have decided to base it internally on boost::uuid (name_generator).

Reasoning:
I second @steint point, that it makes no sense to implement a UUID generation code on its own.

Using boost can be a fast way to get a result, because it is already included in the superbuild.
I think we should avoid being dependent on boost for too many things, as the build has sometimes trouble with Boost?

This is not a valid argument in the current master as (1) boost is a dependency of MITKCore anyways and (2) boost::uuid is nowadays header only, so no new problems are introduced.
Further, I hided boost::uuid as an implementation detail so, we build no further dependencies and can change it later one.

The other proposed options crossguid and stduuid would introduce further additional 3rd party dependencies (like Microsoft GSL). So I see no benefit in try to avoid boost (wich already is a core dependency) by introducing even more dependencies.

DICOM UUID:
This we will also need. But I think it is cleaner to manage that on the DICOM module level (and not the core) then we can also use DCMTKs or GDCMs implementation.

IMPORTANT: Switching to UUIDs the possibility to define the digits/entropy of the UID makes no sense anymore. Thus the constructor signature of mitk::UIDGenerator is changed, which ,may imply a breaking change for code that uses that UIDGenerator.

I would say so. Thanks for pointing it out.