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.
| rMITK MITK | |||
| Restricted Differential Revision | rMITKa3d2e8fb0144 Fixed T23741 | ||
| Restricted Differential Revision | rMITKf3fa7f7ca0b9 Fixed T23741 | ||
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.
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?
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.
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.