-
Notifications
You must be signed in to change notification settings - Fork 121
feat: add text box group to TID300 measurements #429
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
base: master
Are you sure you want to change the base?
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. |
@pieper - What about adding $QualType and $ImagePurpose arrays from https://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_A.html#sect_TID_1501 So, I believe that second example is exactly what the cornerstone free text is intended to apply to, while the first one can be used for other purposes, but one of the possible imagePurpose is to specify a possible location on an image for text. It is only possible, nad can be used in other ways. Examples:
The right way to specify freeform text location associated with this measurement group $ImagePurpose entry
One way to specify freeform text location associated with this measurement group $ImagePurpose
|
Did I understand it correctly that you are suggesting to use the combination of TID1501 rows 10c (to encode location of the text box) and 11 (to assign text to be displayed)? I don't think this could ever be interoperable, but I agree this may be a way to (ab)use the template to achieve your goal, without creating an invalid object. I guess this would be equivalent of using private tags but at the level of SR content tree. |
I don't have a strong preference of methods. As long as you are using a 99 coding scheme and publish the meaning somewhere (perhaps in github and include the URL in the SR somewhere) there's a good chance people (or AIs) will be able to sort out what was intended. |
I agree it is better to do this than using private tags (at least with private coding schemes, the meaning is available within the instance, one one won't need to chase down the non-existent conformance statement to figure it out! But you should make sure in all cases you have the complete |
Yes, that is what I'm proposing.
It might be interoperable if we get agreement from IHE, perhaps as part of the AIRAI standard - I have a contact working on that right now, so I'm going to talk with her about adding a couple of things to the proposal. |
It was mostly a quick example of roughly what I was thinking about rather than the exact final version. |
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.