Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add SCOORD to a Measurement in SR (TID 320) #306

Open
Fedalto opened this issue Sep 25, 2024 · 4 comments · May be fixed by #307
Open

Add SCOORD to a Measurement in SR (TID 320) #306

Fedalto opened this issue Sep 25, 2024 · 4 comments · May be fixed by #307
Labels
enhancement New feature or request

Comments

@Fedalto
Copy link

Fedalto commented Sep 25, 2024

Hi, is it possible to add spatial coordinates to a Measurement in SR?

I'm looking at TID 320 Image or Spatial Coordinates, specifically row 3 and 4.

If it's not currently possible, I could work on a PR to add it.

But I could use some pointers on how to best implement it.
As I understand, the referenced_images parameter in sr.Measurement implements the first row of TID 320 (inferred from image).
What's the best solution to add the other options? Should a new parameter in sr.Measurement be added for each one? Or the referenced_images type could be changed to Optional[Sequence[SourceImageForMeasurement | SourceScoordForMeasurement]]?

@CPBridge CPBridge added the enhancement New feature or request label Sep 25, 2024
@CPBridge
Copy link
Collaborator

CPBridge commented Sep 25, 2024

Hi @Fedalto, thanks for the question

This is not supported right now but I would certainly consider a PR to add it.

However, have you considered whether using already supported behaviour of PlanarROIMeasurementsAndQualitativeEvaluations (or VolumetricROIMeasurementsAndQualitativeEvaluations if you want SCOORD3D coordinates) could be used for your use case? In these cases you can specify the referenced_region (or referenced_regions) as highdicom.sr.ImageRegion when constructing the template, along with measurements that go along with it.

So this is sort of the the "other way up" to what you propose. You specify an image region and then, within it, measurements that relate to that region. Would that work for your use case? I would like to better understand in what scenarios TID 320 would be prefereable.

@Fedalto
Copy link
Author

Fedalto commented Sep 26, 2024

Hi @CPBridge.

I'm using the ImageRegion as well.
My understanding of SR is that I can create a "TID 1411 Volumetric ROI Measurements and Qualitative Evaluations" that represents an ROI, and inside it I use many ImageRegions (1 for each axial slice) to define a 3D contour of the ROI. I then add many measurements for that ROI using the "TID 300. Measurement" template. One of those measurements could be a Diameter. What I want to do is define the diameter line, the coordinates of the start and end points. That looks possible using the row 3 of TID 320 ("INFERRED FROM SCOORD") and that will also link to the image with "SELECTED FROM". Here, I'm not sure when "R-SELECTED FROM" could be used instead.

So, in the end, the SR structure would be like

└── ROI (TID 1411)
    ├── 1..n Image Regions that defines the contour of the ROI
    └── 1..n Measurements like a diameter (TID 300)
        └── INFERRED FROM SCOORD like MULTIPOINT x1,y1,x2,y2
            └── SELECTED FROM IMAGE, here a reference to the original image

Fedalto pushed a commit to Fedalto/highdicom that referenced this issue Sep 26, 2024
This adds support for row 3 and 4 from TID 320.

Resolves ImagingDataCommons#306
Fedalto added a commit to Fedalto/highdicom that referenced this issue Sep 26, 2024
This adds support for row 3 and 4 from TID 320.

Resolves ImagingDataCommons#306
Fedalto added a commit to Fedalto/highdicom that referenced this issue Sep 26, 2024
This adds support for row 3 and 4 from TID 320.

Resolves ImagingDataCommons#306
Fedalto added a commit to Fedalto/highdicom that referenced this issue Sep 26, 2024
This adds support for row 3 and 4 from TID 320.

Resolves ImagingDataCommons#306
@Fedalto Fedalto linked a pull request Sep 26, 2024 that will close this issue
@Fedalto
Copy link
Author

Fedalto commented Sep 26, 2024

Hi @CPBridge,

I just sent #307 which should solve this. I'm not sure about the API though. Any feedback is appreciated.

@CPBridge
Copy link
Collaborator

Thanks for the PR I'll take a look at some point in the next few days! Your use case makes sense to me, just wanted to check that there wasn't a simpler way to solve your problem :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants