-
Notifications
You must be signed in to change notification settings - Fork 35
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
Storage of measurements and qualitative evalutions on ROI objects #19
Comments
Related to #4 |
Yeah that seems like a good idea. With Cornerstone we are storing some tool-specific information like e.g. length, area for each measurement inside the ROI. It would probably be useful to automatically compute them for each type of ROI, but I guess we would have to ask a pathologist which information would be valuable.
I think we should do this at the library and provide sensible defaults, but allow the display function to be configured for each type of annotation (or possibly each annotation itself). Lots of cases have come up where people want to have custom labels, e.g. showing the annotator name that made the measurement, showing the target # for the lesion for the clinical trial, switching the label to another language, but probably 95% of people are using the default "Area X mmˆ2". |
@swederik I agree that it could be useful to automatically compute measurements; however, here I was more generally referring to the ability to store measurements on the ROI object and how we may approach this. According to TID 1411 Volumetric ROI Measurements and Qualitative Evaluations, each Measurement Group contains a reference to one volume. A
Therefore, I thought we could store the information for content items of TID 1411 Volumetric ROI Measurements and Qualitative Evaluations on the Alternatively, we could let an application (e.g. OHIF) handle all of this and provide such functionality outside of the viewer library (e.g. in the dcmjs microscopy adapter.) |
Yes, this makes sense. @swederik and I were digging through this a lot while working on converting the crowds-cure.org data into SR and it would have been great if all the data needed to create a Measurement Group were in the same place and all used the coded concepts for direct serialization. |
To me, it feels like these things should live in dcmjs rather than dicom-microscopy-viewer, because the same code could then be reused across projects/applications. The viewer would then only handle the "bare" spatial coordinates (as it does at the moment). All other high-level information (e.g. measurements) would then be handled at the application-level (potentially using common tools provided via the dcmjs library). What do you think? |
Yes, abstracting measurements away from the specific imaging modalities sounds good. To the extent possible I'd want the in-memory data structure (application state) to mirror the SR encoding as closely as possible so that edits to that state, say from a widget/tool or from editing a parameter form, would be kept in sync and the state could be serialized back to a dicom encoding whenever needed. |
Do we want to store ROI Measurements or Qualitative Evaluations on ROI objects?
The text was updated successfully, but these errors were encountered: