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

[FIX] PET Spec; added known DICOM tags, fixed tag error, updated citation, clarified scale factor. #1021

Merged
merged 17 commits into from
Mar 31, 2022

Conversation

bendhouseart
Copy link
Collaborator

Small updates to the PET spec:

  • Added references/correspondences between all known dicom tags relating to PET entities
  • Clarified scale factor to, hopefully, avoid double scaling of images converted to nifti.
  • Fixed typo on injection start
  • Updated citation to include PET BIDS Paper

Added dicom tag description for `InjectionStart`
Copy link
Collaborator

@CPernet CPernet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good to merge IMO assuming i did not forget brackets or commas :-)

@CPernet CPernet marked this pull request as ready for review March 4, 2022 08:43
@CPernet CPernet requested a review from tsalo as a code owner March 4, 2022 08:43
Copy link
Member

@tsalo tsalo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some minor formatting issues with the macro calls, and I have one question about the updated definition for ScaleFactor. Thanks!

@@ -2293,7 +2293,7 @@ SamplingFrequency:
ScaleFactor:
name: ScaleFactor
description: |
Scale factor for each frame.
Scale factor for each frame. Values must be set if the imaging data (.nii) are unscaled, otherwise set to 1.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you explain this a bit for me? I don't do PET, so I'm a little confused. It sounds like you're saying that this field is REQUIRED if the data are unscaled, but also required if they aren't.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to have to refresh my memory on this as well, but I seem to recall that we ran into some double scaling occurring as a result of converting to nifti (this smells of ECAT). And we wanted to preserve that scaling history in some way in the spec.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see how you would need the scaling factor in that case, but I'm still confused about what the update to the description is meant to convey.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it makes explicit something that was implicit - some conversion wrote the scaling values in the json and applied to the data then what should a user do then? with that change we know

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still confused. Perhaps the source of my confusion will be clearer if I break the added sentence down.

Part 1: "Values must be set if the imaging data (.nii) are unscaled"

My interpretation: If the data are unscaled, ScaleFactor is required.

Part 2: "otherwise set to 1."

My interpretation: If the data are scaled, ScaleFactor is required.

The combined interpretation would thus be, regardless of whether the data are scaled or not, ScaleFactor is required. But then, in the table, ScaleFactor isn't required, it's recommended.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the concern is that by updating ScaleFactor to required will break the few currently passing datasets that are out there. @mnoergaard had some concerns regarding this so I will let him weigh in on this.

Copy link
Member

@tsalo tsalo Mar 15, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, that would break backwards compatibility. How about something like this?

This field MUST be defined if the imaging data (.nii[.gz]) are scaled. If this field is not defined, then it is assumed that the scaling factor is 1. Defining this field when the scaling factor is 1 is recommended, for the sake of clarity.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be in favor of such a suggestion - thanks @tsalo! @CPernet what do you think of this?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep perfect thx @tsalo

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated here, should be gtg.

bendhouseart and others added 9 commits March 4, 2022 11:01
- Fixed markdown formatting in src/01-introduction.md
- Removed dicom tag description for InjectionTimeStart in src/04-modality-specific-files/09-positron-emission-tomography.md
  as there is some disagreement on whether dicom tag Radiopharmaceutical Start Time (0018, 1072) should be referenced.
@@ -154,8 +154,8 @@ which we divide into several categories:

{{ MACROS___make_metadata_table(
{
"TracerName": "REQUIRED",
"TracerRadionuclide": "REQUIRED",
"TracerName": ("REQUIRED", "Corresponds to DICOM Tags (0008,0105) `Mapping Resource` and (0008,0122) `Mapping Resource Name`."),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why aren't we putting these in the metadata.yaml directly?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well some were in yaml some were in spec, and there is no rule to decide --so being lazy i pushed all new ones there

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rule I would use is whether the BIDS term unambiguously corresponds to a DICOM tag (so would be sensible to render any time the term is rendered), or if it corresponds to a DICOM tag in the specific context of a particular table.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not confident enough to say that these tags should belong in the metadata.yml as many of these terms are often more explicitly defined (or known....) by the experiment designer/performer or simply not present in the dicom headers. Adding them to the tables provides a bread crumb for a user to extract this info if they're not omnipotent concerning the experiment or the metadata.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Corresponds to DICOM Tag" doesn't say to me "MUST be derived from DICOM Tag". I think linking the concepts in the term definition helps clarify.

That said, I won't die on this hill. We can move these into metadata.yaml in the future as well.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Corresponds to DICOM Tag" doesn't say to me "MUST be derived from DICOM Tag". I think linking the concepts in the term definition helps clarify.

That said, I won't die on this hill. We can move these into metadata.yaml in the future as well.

Agreed. Have already noticed in this PR that it's very easy 🙄 to add something into these tables and duplicate what's in the metadata.yaml or vice versa.

@CPernet CPernet requested a review from tsalo March 11, 2022 14:58
Update Scale Factor description to consensus
@sappelhoff sappelhoff changed the title [FIX] - PET Spec; added known DICOM tags, fixed tag error, updated citation, clarified scale factor. [FIX] PET Spec; added known DICOM tags, fixed tag error, updated citation, clarified scale factor. Mar 29, 2022
Copy link
Member

@sappelhoff sappelhoff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to merge once my minor suggestions have been incorporated.

@sappelhoff
Copy link
Member

@tsalo you still have a "changes requested" blocking review. Could you please confirm that your concerns have been addressed (seems like it) and re-review?

Copy link
Member

@tsalo tsalo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Collaborator

@mnoergaard mnoergaard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! thanks!

@sappelhoff sappelhoff merged commit 4428fd3 into bids-standard:master Mar 31, 2022
@sappelhoff
Copy link
Member

Thanks @bendhouseart and @CPernet and all reviewers :-)

Copy link

codecov bot commented Aug 28, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.50%. Comparing base (6043989) to head (6744126).
Report is 1464 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff             @@
##           master    #1021       +/-   ##
===========================================
+ Coverage   34.05%   71.50%   +37.45%     
===========================================
  Files           8        9        +1     
  Lines         834      930       +96     
===========================================
+ Hits          284      665      +381     
+ Misses        550      265      -285     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@sappelhoff
Copy link
Member

#1021 (comment)

very funny to receive a codecov report here, more than two years after the last push 🤔

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

Successfully merging this pull request may close these issues.

6 participants