Hello,
I am investigating possibility and of saving segmentations in correct format. So far I have encountered 3 options:
I dont have experience with them in ITK. I would like to know which is the correct way to implement this and whether the itk implementation is available and stable.
For good DICOM compliance, you might want to look at dcmqi. Better DICOM write support is one of the currently needed features in ITK.
To complete @dzenanz, you can have a look at this example, ResampleDICOM, to have and idea of the current DICOM manipulation in ITK.
Also, ITK relies on third party libraries (GDCM by default, or DCMTK) to manipulate DICOM so you can check their documentation.
Tim
The itkimage2segimage command line executable from dcmqi offers a quick way to get started.
CC: @jcfr
Both DICOM Segmentation IOD and Surface Segmentation IOD are valid options. As most segmentations are created from images, Segmentation IOD is often the preferred choice and probably more commonly used.
RT structure set is a really old format with several fundamental issues. If you don’t need compatibility with legacy systems then it is better to avoid it.
@Hrabalski I don’t think there is a general answer to the question what object type to choose. It depends on what kind of segmentations you are working with, what is important for your use case, why you started to think about DICOM for storing segmentations in the first place. If you give a bit more context, it might be easier to help you.
Support in tools might be another factor to consider, but, again, I don’t know how important this is for you.
DICOM Segmentation image object is supported by several tools (both commercial and open source), you can see a summary here: https://qiicr.gitbooks.io/dicom4qi/, and you can use dcmqi for conversion.
DICOM RT Structure set is widely supported in the radiotherapy workstations, and there open source tools for conversion - Plastimatch http://plastimatch.org/ and SlicerRT (you have to google the link, since as a new user I can only insert two links in a post…).
I am not aware of tools supporting DICOM Surface object.
Thank you for all the answers.
I am pushed to use DCMTK library by now, but in case there was any high level solution implemented in ITK, I would prefer using it.
The idea for the moment is to store segmentations from multiple stages of treatment. Prefered way to store them is single DICOM image.
So far I am using CT image SOP class with secondary image tag, but this doesnt seem to be the best way.
DICOM Segmentation object is represented by a family of classes in DCMTK that you can use to implement your own conversion in the DCMTK dcmseg library.
dcmqi is a separate library that builds on top of dcmseg to implement a higher level solution.
If your multiple stages of treatment are spread over time, you cannot put all of them into a single DICOM Segmentation object. In DICOM, you will have segmentation(s) stored in a series that can belong to a single DICOM study. You can store multiple segmentation labels, which can overlap, within a single DICOM segmentation object. You cannot store segmentation labels that correspond to different imaging studies in a single object.
Yes, this is a commonly used practical approach, and will maximize the chances of your series being rendered by the PACS viewers and off the shelf components. However, it provides no place to encode the semantics of the object, and it has multiple other limitations
So, again, you have to decide what is important in your situation.
Hi all!
Apologies for bringing such an old topic up, but I’m currently facing exactly the same challenge as the original poster and would like to know if there has been any development in ITK around this since 2017?
We have some binary 3D segmentations and need to export them into DICOM segmentation storage format. Exporting the segmentations as images would be easy, of course, but then their type would be incorrectly detected by the next software in the pipeline. Segmentation storage SOP class also offers some useful additional properties like segmentation labels, so that’s what we want to use. However, there doesn’t seem to be any tools in ITK to write DICOM segmentation storage, right?
Also, do you know if there are any new tools to do the job in addition to dcmqi and DCMTK’s dcmseg? I had a quick look about these two and I’m not sure yet if either one for them is the optimal choice for our needs. update: It seems highdicom is something we’re looking for, but we need it in C++.
Thanks!
/Harri
I do not think there is anything other than DCMTK/dcmqi, if you are looking for C++ tools.
@hapap DCMQI works robustly. If comes with a free, permissive license, so if you find any shortcomings (e.g., you would like to improve its performance, change input/output data formats, etc.) then you can implement those improvements yourseld and preferably also contribute it it back for the benefit of the medical image computing community.
I heard that highdicom had some serious performance issues (it took minutes to load a segmentation with 100 segments), it had limitations around overlapping segments, time sequences, etc. so if you consider using it then check out if these limitations still around and whether they impact you.
Currently, dcmqi is very slow for large number of segments, since every segment is loaded into a separate volume, and is written to a separate file. I have a PR in progress to allow saving non-overlapping segments into a single file, but I have been struggling to complete it, since there are many related issues that need to be addressed due to the initial assumption made that each segment should go into separate file (to simplify the less common case of overlapping segments): Add support for saving segments in a single file by fedorov · Pull Request #464 · QIICR/dcmqi · GitHub. The branch in that PR is functional, and you can experiment with it if you need to handle large number of segments (feedback/contributions are welcome!).
In defence of highdicom, it is a lot more flexible to add functionality, and is more actively developed. Some of the issues Andras mentioned might have already been addressed - it doesn’t look like Chris Bridge is on this list, so I will reach him via email and ask to comment, if there are such relevant updates.
dcmqi provides the level of abstraction that I still think is superior to highdicom for users who need a basic conversion tool, but when something is missing in dcmqi that requires significant rework or additions, it is less likely to happen, due to limited resources to maintain it. But if there is a need and motivation, I may try to find additional resources - so please do let me know if you use dcmqi and you find it helpful!
Hi @lassoan
I’m one of the authors of highdicom. The rumours are true that highdicom suffers/has suffered from performance issues with large segmentation images. Consequently, I have been very focused recently on improving the situation. Since release 0.21.0, you should find that this situation is very considerably improved for reading existing segmentations and extracting the relevant pixels from them. Unfortunately, we are still hitting on limitations in the performance of the underlying pydicom library, which mean that just reading in the file using pydicom takes several seconds (this is related to the parsing of large DICOM Sequences being slow at the pydicom level). However, the highdicom-specific part following this is now pretty efficient.
However, highdicom is still slow for the creation of new segmentations when there are a large number of frames. I have been working on this in the last couple of weeks and I have a branch where I’m addressing this and seeing around 10x speed-up in a test case with 100 segments and 600 CT frames (it’s down to around 10s in this case from over 100s). After a few more sanity checks, I’m hoping to get this merged and released in the next couple of weeks. It’s in a functional state and you could try testing it out if you are interested.
Note also that this branch has a considerably improved user guide for segmentations that you may find useful if playing around with them.
We do not currently support time series. Hopefully we will add this in the future but it is not currently a top priority. However, we absolutely support overlapping segments for both creation and parsing and have done all along so I’m not where you heard this and would encourage you to play around with it if this is what is preventing you from using the library (the new docs branch mentioned above would be a good place to start reading about this).
Happy to answer any questions you have and grateful to receive issues (including those related to performance) on the Github repo’s issue tracker.
I’ve been using pydicom-seg for a few projects. I have not tried for storing large seg objects, but it has performed well on data from TCIA and storing results that can then be loaded into other viewers:
To see this working with ITK to read data from TCIA, see section 4B in this jupyter notebook
@CPBridge Thanks a lot for taking the time to describe the latest status and what’s coming in the near future. It’s all very promising!
It would be nice to get performance that is comparable to using .seg.nrrd files (reading 100 segments with all metadata in 0.25sec), but for this probably some simplifications would be needed in the DICOM standard.
Indeed, I think we would all like that! But there are two limiting factors right now:
Yes, I’m looking forward to working on SEG with the group at Project Week (and online). Others are welcome to join. Currently we have bottlenecks working with 100 segments, but we should have in mind use cases with thousands of segments. I agree with @lassoan that we should aim to have DICOM SEG be as fast or faster than using a seg.nrrd or nii.gz file, while retaining all the benefits of DICOM metadata. We also need to keep space efficiency in mind as well, since most SEG files are currently orders of magnitude bigger than compressed formats.