[ENH] add metadata to PET calibration factor: "DoseCalibrationFactor"

[CPernet]

As we are working on MATLAB and Python nibabel converter - we realize quantitative PET means multiplying data by the scanner calibration factor ; while not essential, it would be nice to have this information in the json file (in the table as a recommended tag)

[ChristophePhillips]

As we are working on MATLAB and Python nibabel converter - we realize quantitative PET means multiplying data by the scanner calibration factor ; while not essential, it would be nice to have this information in the json file (in the table as a recommended tag)

I am all in for more clarity about the data description but what is this "calibration factor" about? When/where would it be useful to know about this?

[CPernet]

• every PET scanner has a calibration - for a known dose of radioactive element, the machine counts x, and you multiply by that calibration factor to get the right quantitative value (turns out scanners are re-calibrated every so often, the older the less you need it as crystals are more stable, so I've been told - but I'm no expert in that)
• by default in nifti data would be multiplied already (in old fashion analyze you'd put it in the header) but if you wanted to get back to the basic count value, with that info you can (say for a static FDG scan - agreed unlikely)

[mnoergaard]

Hi @CPernet,
I would suggest to move it down to the "other" factors in the reconstruction, and rename it to DoseCalibrationFactor, and maybe update the description so it is more in line with (http://dicomlookup.com/lookup.asp?sw=Tnumber&q=(0054,1322)), including a referral to the DICOM tag. For most dicom files, the conversion is already carried out to e.g. Bq/mL, and hence the calibration factor becomes slightly redundant, as the required units of the image are in Bq. But I agree with you that the calibration factor is needed to go back to counts/sec, I am just not convinced of any use-cases where this would be done.

[CPernet]

yes, thx @mnoergaard - I knew you'd be the man for a good review :-) note that in ecat (HRRT) this is not applied to the data, but stored separately - I'll do the suggested changes thx (and yes hard to see why you would want count/sec in general, but maybe for some more method work)

[CPernet]

@mnoergaard new commit :-)

[mnoergaard]

This looks good to me - thanks @CPernet. Next we need to update the validator in a separate PR.

[CPernet]

@ChristophePhillips @mnoergaard you need to 'approve' in the review
@sappelhoff or @Remi-Gau can then confirm the merge? (yes checking the validator too)

[sappelhoff]

I have problems understanding the description. Could you please split this up into sentences with each sentence conveying a meaning?

Let me clarify what I find confusing:

Value used to calibrate radioactivity count

--> is "radioactivity count" metadata that corresponds to some already existing field? If yes, can you reference that one, please?

• value already applied to the data as a multiplication factor that scales them from counts/sec to Bq/ml (dicom tag 0054,1322).

does that connect to the previous sentence? Or is it a standalone statement? Or an example / clarification?

Lastly:

• We have agreed not to use latin abbreviations in the BIDS specification, see: https://the-turing-way.netlify.app/community-handbook/style.html#avoid-latin-abbreviation --> so please remove/replace the latin
• The table pipes of this table need to be aligned (currently not the case, hence CIs are failing)

[mnoergaard]

Thanks for pointing this out @sappelhoff. I have now updated the description, so it is very much in line with the dicom description, and then referring to the dicom tag. Then it is possible to make a dicom lookup, if one wants to search for more information. This also removes the latin abbreviations, and then I have aligned the table pipes.

[CPernet]

thx @sappelhoff pushed it (sorry on top of martin, updating at the same time)

[sappelhoff]

I made a slight change in wording, see: 7319961

Other than that, it looks fine to me - given that a couple of more people look at it and agree that we need it.

[CPernet]

@sappelhoff this is now approved - the only bug I see is a link related to ASL???

[sappelhoff]

Yes there has been some fluctuation with the OSIPI URL the last days https://www.osipi.org cc @HenkMutsaerts

I haven't merged this yet so that more people may see it and chime in before it goes in --> in accordance with our 5-day rule: https://github.com/bids-standard/bids-specification/blob/master/DECISION-MAKING.md#rules

Sometimes maintainers can break that rule according to their own judgment, but in this case, I think there is no harm done leaving it for other people to see for two more days. Unless I hear otherwise, let's merge this on Saturday evening or Sunday.

[sappelhoff]

Thanks @CPernet for getting this started and everybody else for the reviews!