feat: add text box group to TID300 measurements #429
Conversation
✅ Deploy Preview for dcmjs2 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Hi @pedrokohler - I missed the last coordination meeting, but did you run this by David and Andrey? |
Hi @pieper, this isn't related to IDC. A client wants to add functionality to save the textbox positions of annotations in their OHIF fork, and they'd like to contribute this back to the open-source project. However, to achieve this, we also need to make a few changes in both Cornerstone and dcmjs. |
|
Thanks Pedro. I ask because we want to keep the dcmjs implementation as standards-compliant as possible and it seems that code 111030 is "Image Region" and not "Annotation Position". I believe the code meaning text is meant to follow the standard exactly and not to encode different information. I understand the need to serialize the text position though. It may be that there is no standard way to do that. If that's the case, I suggest that Cornerstone / OHIF will probably need to just add private tags to the top level of the SR describing the annotation positions and maybe other settings that don't have a standardized DICOM representation. |
|
@pieper I see. Sorry I didn't double check the code meaning. I understand your concern and I agree. But maybe we can find a valid alternative within the standard. Checking the link you provided I was able to find this:
Do you think we can use it? Maybe @wayfarer3130 can also come up with suggestions. |
|
I guess using an annotation note would be sort-of okay, but also maybe not really keeping with the standard since those are probably meant to be human readable. Plus I'm sure once people get started they will want to save things like the font size or color in addition to the position. In the extreme people could put long xml strings or something. I think a toolkit-specific set of private tags are unfortunately the only think I know can be used here in spirit of the standard. Yes, if @wayfarer3130 knows better, that would be great. We can also raise this to David C or Chis B since maintaining dcmjs/cs3d/ohif dicom correctness is within the IDC mission. |
|
Actually I think if we included hte annotation note text itself, as well as the point data it would probably be closer to the intention of the standard than the hack that is currently used to store custom annotation notes in OHIF and Microscopy viewer. However, I'd like to pass this by David C. and see what he suggests. |
|
Let me try tagging him here @dclunie |
|
t @wayfarer3130 what microscopy hack are you referring to? @pieper The way that OHIF and the dicom microscopy viewer library use the Findings on annotations with a custom schema and free text in the value to describe an annotation note. Both of them can also use real finding codes, but the hack is that it just puts free text in the "Code Value" field with a Coding Schema that is a microscopy or cornerstone identifier. AFAIK, the right way to do that is to add an annotation note with the text encoded as part of that note. |
|
I think you mistakenly updated @pieper's comment. |
|
|
Presentation states are intended for this - see https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.10.5.html |
That presupposes that one is willing to have multiple representations of annotations, and to split the data across multiple files. The SR format is a single contained format for creating structured annotations for sharing as annotations/measurements. Presentation states are really about the display of the annotation data. The existing SR measurements have a way to store the position of the annotation, eg by storing the start and end points of a caliper length measurement. They also have a good way to store finding codes and the finding site codes. I'm not sure how they should store freeform text that is associated with the finding/measurement. Currently OHIF uses a custom finding code whose value is the freeform text - that seems like a bad idea to me. Also, that text can be moved around, and we'd like to have a way to store the position it gets moved to within the single SR file so that all the data for the measurements is stored in one file rather than trying to split and correlate them across multiple files. |
|
If you want to say something (a text comment) about a region, then SR is the way. There is no (within SR) mechanism to indicate how or where that text is displayed, and that is intentional. If you want to place a text comment somewhere on the image as displayed, that is what PR is for. That's why PRs contain an annotation mechanism in the first place. That's the way the standard is designed, and the semantics of PR is interoperable (in terms of expected behavior - "put text here"). If you abuse SR by using location information that is supposed to define the location of "things" simply to attempt to "place" arbitrary text, then you cannot expect any other system receiving the data to behave in a predictable way (regardless of what codes you use to attempt to describe it). In a sense they are different "types" of "annotations" and either or both can be used (in combination for some use cases). You may not like this, and it may not be convenient or expedient, and you may want to abuse it, but that is the way it was designed, for better or for worse. |
This PR adds the ability to store the position of a textbox or label within an SR.
With this enhancement, libraries such as OHIF and Cornerstone can save and reload the textbox positions that users manually set.
Currently, this isn't possible, as textbox positions are lost when saving the SR.