 |
Csaba and I talked about this. He will look at this and report more information. I would say that if the studyUID is different than it should be considered a different study. |
 |
I basically need to investigate why the StudyInstanceUID of the exported series does not match the original study UID and fix it. |
|
|
Right now the plugins are responsible for creating study instance UIDs, and they will need to support adding exported series to existing study. See conversation |
|
|
How I imagine supporting this on the DICOM export level: the study nodes need to store their UIDs if imported from DICOM, and if it exists, then the exporter only exports the new series under that, passing the study UID to the plugins. |
|
|
Fixed in the RT export plugin, see further information Need to see how it works for scalar volume export. |
|
|
Scalar volume exporter seems to generate new study instance UID every time. There is no trace of re-using study instance UID neither in DICOMExportScalarVolume.py nor in CreateDICOMSeries.cxx. It seems that itk::ImageFileWriter<Image2DType> with itk::GDCMImageIO generates a new one each time. Also the Study ID (which is just a string) is set to a fixed SLICER10001, so apparently by design it is not possible to append to existing study. |
|
|
We should really consider re-writing the CreateDICOMSeries.cxx functionality. It was put together by the team at GE long ago with the very restricted goal of getting a particular GE system to read the data. It would not be hard to meet or exceed those goals with a little work and we could avoid needing to work around existing limitations. |
|
|
That was my conclusion as well. However I don't have the capacity to work on this in the foreseeable future unfortunately. |
|
|
Understood. We may end up with some building blocks from the qiicr / dcmqi project or similar that will make this easier. |
 |
Retargeting stale issues to backlog. |
- Anonymous
