I’m trying to load some DICOM segmentation file, similar to “Unable to load DICOM segmentation file”. I am running into the same issue of not being able to load these files. The files do have reference images that I also have, with the correct UID references, but it makes no difference with loading. (I assume it would only matter for their positioning in any case)
However my problem seems to be one option mentioned by issakomi, where the SEG here has SOPClassUID = 1.2.840.10008.5.1.4.1.1.66.5
Is there any update since that topic that allows me to load these files without trying to fiddle with extra scripts? I already tried using the script that issakomi linked at the time, however I did not have any success. The actual data here is a couple of registration points coming from a registration pointer tracked by a Brainlab Curve system.
You can try with the latest Slicer release and if you still have issues it would be good for you to post data (but don’t post PHI) publicly together with exact descriptions of the software used to generate the files.
I tried with both 5.8.1 and the 5.9 preview, both have the same result as with 5.8 (doesn’t work). I have posted an edited version of the DICOM file here. I hope just one of them is enough (there are 7 points) to figure out how to make them load. If anything is wrong with the data I posted please let me know.
I have replaced possible remnants of sensitive data with “Assume this is correct” and other sample answers.
The data is obtained from the Brainlab Origin Software, I don’t really have the exact version of it but I will post when I get find out, although I think the data inside the DICOM might have some information about the version.
Okay, thanks for sharing that file. This is a SurfaceSegmentationStorage, which has historically been very rare (I wrote a prototype reader 9 years ago and the topic has only come up once or twice since then, for example in the thread linked below.
It would be great if someone wants to dig this up again and make sure it works with the latest Slicer with some sharable data.
I have the script to load SEG mesh, but it works with triangle meshes, Triangle Point Index List (deprecated) or Long Triangle Point Index List should be available. In your file it is empty, there is Vertex Point Index List (deprecated, Long Vertex Point Index List should be used). I think it is not a mesh, but a set of points (one point in your file), it is easy to read the points, but not yet sure how visualize.
I have tried to modify the script to work with your data, s. here. Probably the points could be visualized much better, also not sure about the file, but your can check. I have modified the file to have 5 points, with one point it is difficult to test. (Caution with LPS/RAS space, s. option in the script)
Thanks a lot for the work :]. I tried editting the script you posted before, but didn’t have much success myself, hopefully I understand it better now. I’ll test myself next week to see how I can implement it such that I can load the points into Slicer directly.
The actual data is 7 separate files, with 1 point each. My main goal is to just easily load the positions of the points in world coordinates, as afterwards I can change the visualization to Markup.
Storing a single point in a SurfaceSegmentationStorage is a very unusual choice. Segmentation is intended to store 3D shapes, hence the name “Surface…” (a single point is not a surface). The much more common SegmentationStorage representation stores 3D shapes, too.
@David_Clunie is this kind of use of surface segmentation valid or we should ask the vendor to stop exporting data objects like this and stick to the usual measurements storage instead (Structured Report with TID 1500)?
If the single points are registration landmark points (fiducials), there is a specific IOD for that, the Spatial Fiducials IOD, which defines fiducials in either 3D (frame of reference relative) or 2D (image pixel data relative) space. Fiducials do not have to be points, but they can be - see Shape Type.
I would not recommend using SR or the surface segmentation objects for this.
Please contact BrainLab engineers and clarify this: Did they really save registration landmark positions in a Surface Segmentation IOD? What was their rationale? What would be a timeline for the fix?
If it turns out that this is indeed an inappropriate use of Surface Segmentation IOD then I would rather not make Slicer legitimize it (and waste time with implementing some temporary solution that later need to be replaced). But of course if your project cannot afford to wait for correct solution then you can go and add a very simple Python scripted DICOM plugin that recognizes these odd DICOM objects and creates markups from them. You would implement something like the structured report plugin but much simpler, because you would just need to read a single point per instance (you would not need to ready many markups and you would not need to be able to read a proper Surface Segmentation IOD). If you implement this then you can submit it to a related extension, such as SlicerIGT to make it easily available without adding a new Slicer extension.
I will contact someone at Brainlab today, hopefully will get some response before end of the week.
I plan to make a quick reader this week to load the data I am working with, however after that I will look into making that an addition for SlicerIGT. Will update as soon as I have something new, thanks again for all the help.
This does indeed work just fine. After having a proper look at what was going on in the code, I realised that I really just missunderstood where the data for the points was being extracted from in the DICOM file. The DICOM viewer only shows the X value (no Y or Z), however through the code I can see that Y and Z are also in the PointCoordinatesData attribute. At the moment I am just loading the coordinates through that, and adding the points into a MarkupFiducial. Thank you again for the script @issakomi .
If I get a response from Brainlab about the issue, I will post an update here, however for now I will continue using this, and in the weekend try to find where in SlicerIGT I can add a code snippet to handle this specific DICOM file edge case. Thank you all for the help :].
