-
Notifications
You must be signed in to change notification settings - Fork 61
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
ENH: revise initialization of TrackingUID #365
base: master
Are you sure you want to change the base?
Conversation
If not provided by the user, initialize it. This can't hurt, but will come handy if measurements are done later using this segmentation.
TrackingIdentifier and TrackingUniqueIdentifier are required. If not specified, TrackingUniqueIdentifier will be initialized automatically by dcmqi. If either one is available in SEG, propagate to link with the measurements. Related PR for dcmqi will make sure TrackingUniqueIdentifier is always created for SEG segments. It does not hurt, but will become useful if those segments are later used for measurements. See QIICR/dcmqi#365.
This potentially can hurt, since if not initialized by the user explicitly in a longitudinal tracking situation, TrackingUID will be different even if the structure is the same, and the user may be unaware of this. It can also happen that the TrackingUID in SR may need to be different from SEG, which will become messy... No longer 100% sure this is a good idea! |
I'd say this is appropriate - if the the user doesn't explicitly affirm that the lesions are the same then the should have different UIDs. |
Well, I think the question becomes what is the significance of something not being said. Let's say we have two time points with segmentations, and there are three situations for SEG (all of which are valid):
Then let's say someone wants to do measurements over that SEG, and that someone wants to assign consistent UID for the timepoints. If option 2 or 3 above is followed, this is possible, but otherwise producer of SR is locked between two unfavorable choices:
The problem is SEG and SR may be created by different entities, with SEG generator not aware of consequences of not populating an optional parameter. I am leaning towards not initializing TrackingUID in SEG by default, unknown to the user. |
If neither TrackingID nor TrackingUID are initialized, then do nothing. If TrackingID is initialized, generate TrackingUID and print a warning alerting user that they should pay attention in case they encode longitudinal data. If TrackingUID is initialized, but TrackingID is not, reuse SegmentLabel as TrackingID, and alert the user about that.
TODO:
|
@fedorov Regarding the "tid1500writer": The setReferencedSegment() method from TID 1411 class also sets (i.e. copies) the tracking information from the referenced segment if parameter "copyTracking" is true (which is the default). Not sure whether this information is helpful, but I just wanted to let you know. |
Thank you Jörg, this is indeed helpful to know! |
If not provided by the user, initialize it. This can't hurt, but will come handy if measurements are done later using this segmentation.