Add support for cancelling/aborting the saving of DICOM image stacks (itk::GDCMImageIO::Write)

[nocnokneo]

Description

Using compression when writing a large stack of slices to DICOM can take a significant amount of time. To allow the end user of a ITK-based application to cancel saving a DICOM image stack there needs to be a way in the itk::GDCMImageIO::Write call stack to abort the encoding process somehow. For example, with JPEG encoding, some sort of abort flag would need to reach all the way into loop in gdcm::JPEGCodec::Code that iterates over slices:

1  gdcm::JPEGCodec::Code                                            
2  gdcm::ImageChangeTransferSyntax::TryJPEGCodec                    
3  gdcm::ImageChangeTransferSyntax::Change                          
4  itk::GDCMImageIO::Write                                          
5  itk::ImageFileWriter<itk::Image<unsigned char, 3u>>::GenerateData
6  itk::ImageFileWriter<itk::Image<unsigned char, 3u>>::Write       
7  itk::ImageFileWriter<itk::Image<unsigned char, 3u>>::Update      

Additional Information

Upstream GDCM feature request which must be done first:

https://sourceforge.net/p/gdcm/feature-requests/40/

[blowekamp]

For reference the itk::ImageIO class is derived from the LightProcessObject which as an AbortGenerateData method. Additionally, a basic ITK process object would call some "progress" reporting methods which would check if the abort flag for the process add been set.

So the way to add the "abort" feature, may be to add a "progress" feature.

[nocnokneo]

So the way to add the "abort" feature, may be to add a "progress" feature

Yes, that can work as long as the "progress" feature reaches all the way into the various GDCM codecs (e.g. gdcm::JPEGCodec::Code which can easily take a minute for a large dataset)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nocnokneo]

This is still an important issue.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.