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?

• 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)

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.

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)

@mnoergaard new commit :-)

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

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

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

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

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.

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