effigies
commented
1 year ago The way I see it is that every BIDS dataset is an approximation of a description of a study, and every additional piece of metadata improves that approximation. A recommended or optional piece of metadata does not invalidate the obligatory metadata but might modify the final interpretation.
From this perspective, pixdim is authoritative because it is obligatory. A dataset missing AcquisitionVoxelSize would be "correctly" handled using only the pixdim, but the presence of AcquisitionVoxelSize could induce a tool to improve its processing.
I agree it's worth stating explicitly, and I suppose we need agreement from the ASL leads who introduced this (@patsycle, @HenkMutsaerts) that this is correct and then some spec-worthy verbiage.
I also think the description of acquisitionvoxelsize should provide some details to its correspondence to DICOM tags to clarify how users can determine this.
I agree, if these are available. I hope the ASL leads also have suggestions here.
neurolabusc
In general, it seems like a general rule of BIDS is to only describe a variable once, to minimize confusion if there same information occurs twice. Therefore, the original BIDS specification did not include distance between voxel centers in the JSON sidecar, as this is found in the NIfTI header as
pixdim. However, the original specificaiton included the thickness field in the sidecar, to handle the common case to insert spatial gaps between centers.More recently, a new field acquisitionvoxelsize that reports the raw voxel size, which is voxel size excluding slice gaps. With an uninterpolated image without any gaps, this will be identical to the NIfTI pixdim, and for an un-interpolated image with gaps this will be equal to [pixdim[1], pixdim[2], pixdim[3] - slicethickness]. I understand the utility of keeping a single array that stores this, but I worry that this now means one needs to explicitly specify some rule about precedence. Perhaps the easiest solution would be to add the rule that a sidecar must include either acquisitionvoxelsize or slicethickness. Alternatively, one could add the rule that if both exist acquisitionvoxelsize will be given precedence.
I also think the description of acquisitionvoxelsize should provide some details to its correspondence to DICOM tags to clarify how users can determine this . A challenge is that DICOM tends to only report interpolation interpolation is present or absent, so inplane interpolation needs to be inferred by comparing tags that vary between manufacturers and software version.