Add chunk entity to MRI datatype

[jcohenadad]

Your idea

The chunk entity was introduced for the 'Microscopy' datatype in BEP031 #881. Given that the acquisition of multiple 'chunks' is not uncommon in MRI (eg: different slabs of the brain or spinal cord that are then stitched together), I would welcome having the chunk entity available for the MRI community as well.

Related issues:

• https://github.com/bids-standard/bids-validator/issues/1582
• How to split large datasets #935

[CPernet]

could be, should the ChunkTransformationMatrix be defined in the nii header and json ; how is this usually done?

[jcohenadad]

could be, should the ChunkTransformationMatrix be defined in the nii header and json ; how is this usually done?

no need, this is what the qform is for. This is the beauty of the world coordinate system 😊

[CPernet]

sorry, that's what I meant - ie chunks are already aligned , but we will need to explicitly state it

[effigies]

I'm +1 on this, but we need to be clear on what this means for curation. There is no plausible way for a validator to actually check that two MRI images share a world space that may or may not overlap.

How do these images come off the scanner? Are they scanner-aligned and require manual curation to bring into a common space? Or are there scanner protocols that will annotate the images with their relative alignment?

We have these options (via nifti1.h) for qform/sform codes:

Code	Name	Description
0	NIFTI_XFORM_UNKNOWN	Scanner-based anatomical coordinates
1	NIFTI_XFORM_SCANNER_ANAT	Coordinates aligned to another file's, or to anatomical "truth".
2	NIFTI_XFORM_ALIGNED_ANAT	Coordinates aligned to Talairach-Tournoux Atlas; (0,0,0)=AC, etc.
3	NIFTI_XFORM_TALAIRACH	MNI 152 normalized coordinates.
4	NIFTI_XFORM_MNI_152	Normalized coordinates (for any general standard template space)
5	NIFTI_XFORM_TEMPLATE_OTHER

Would 1 or 2 apply? Or possibly 5? We should probably require at least one of qform_code or sform_code to be non-zero. Would 1 indicate that the images came off the scanner aligned, or have yet to be manually aligned?

[jcohenadad]

There is no plausible way for a validator to actually check that two MRI images share a world space that may or may not overlap.

I don't see a problem with this. Regardless if there is overlap or not, the point is to be able to describe two different FOVs acquired during the same session, that could or could not be analyzed jointly.

How do these images come off the scanner?

I'm not sure I fully understand the question because my answer would be trivial: they come off the scanner exactly the same way any MRI image comes off the scanner. Example of scenario:

1. loca
2. T1w MPRAGE covering c-spine
3. T1w MPRAGE covering t-spine (same params as previous scan, only the FOV was moved).

So, when running dcm2niix on the output DICOMs, three NIfTI files are created, and the NIfTI for 2 and 3 have different qform. See below an example of qforms for two different FOVs (notice the difference in the Tz):

FOV1

qto_xyz:1	1.000000 0.000000 0.000000 -87.195183 
qto_xyz:2	0.000000 1.000000 0.000000 -114.000000 
qto_xyz:3	0.000000 0.000000 1.000000 -142.887939 

FOV2

qto_xyz:1	1.000000 0.000000 0.000000 -87.195183 
qto_xyz:2	0.000000 1.000000 0.000000 -114.000000 
qto_xyz:3	0.000000 0.000000 1.000000 -441.000000 

Are they scanner-aligned

Yes, they should be treated as 'regular' images (see my comment above).

and require manual curation to bring into a common space?

They could, but not necessarily. Eg, offline stitching could be performed.

Or are there scanner protocols that will annotate the images with their relative alignment?

Again, I'm not sure I understand the question. If the word 'protocols' refers to the description of the sequence/parameters, the answer is no. If it refers to the protocol decided by the local radiology team, then sure, they might want to decide to eg. name a particular scan (DICOM 'SeriesDescription' 0008,103e) ''MPRAGE_head", but I don't think this is relevant in the context of BIDS. As mentioned above, the relative alignment is found via the absolute alignment (ie: qform).

Would 1 or 2 apply? Or possibly 5? We should probably require at least one of qform_code or sform_code to be non-zero. Would 1 indicate that the images came off the scanner aligned, or have yet to be manually aligned?

I think that each image should be treated exactly the same was as if there was only a single FOV. Ie: NIFTI_XFORM_SCANNER_ANAT as should be the case for any 'regular' MR image being niftified.

[CPernet]

because the validator is not going to check this - I'd more interested to see some info in jsons indicating if chuncks are aligned or not

[jcohenadad]

 I'd more interested to see some info in jsons indicating if chuncks are aligned or not

Just to be sure I understand, by "chunks are aligned", are you referring to chunks that are acquired at two different spatial location, and that are adjacent (or slightly overlapping)? If so, this information is de facto included in the qform matrix.

[CPernet]

yep basically in 99% of cases they are aligned because that's what nifti q form does -- but imaging a patients need to stop scanning and move in/out for reason x, you might not have the two chuncks aligned although 'easily' done off line ; just to be double cautious

[jcohenadad]

yep basically in 99% of cases they are aligned because that's what nifti q form does -- but imaging a patients need to stop scanning and move in/out for reason x, you might not have the two chuncks aligned although 'easily' done off line ; just to be double cautious

good point-- although the concept of 'two chunks acquired during the same session' is then debatable. If the subject goes out and in again, with another laser centerline, I would not consider this the same session. Moreover, if we keep the 80/20 BIDS philosophy, I would suggest we move forward with accepting chunk for MRI sooner rather than later.

[jcohenadad]

Hello, just following up to make sure it doesn't slip through the cracks-- does anybody have an objection about my team implementing this feature in a PR?

[Remi-Gau]

I would say go for it by taking into account what was suggested in this issue.