WIP: retrieving metadata from bids-formatted json files #27
Conversation
get_metadata_val is splitted into 3 functions: get_metadata_val_classic -- original code of get_metadata_val get_metadata_val_header -- retrive metadata from nifti get_metadata_val_bids -- retrive metadata from bidsified json The get_metadata_val checks if recieved structure contains 'acqpar' and based on it colls one of 3 functions
Added: - isDWI from filename suffix - AllDiffusionDirections from bvec file - AllDiffusionValues from bval file In order to get this info, added a new field to meta structure: 'filename' containing the path to data file. bval and bvec are retrieved by changing extension
When possible the metadata structure is loaded and passed to the 'classic' or 'BIDS' get_metadata_val subfunctions.
Since there should not be any direct call to this function with a filename, one can remove the reloading of the mstruct based on a filename.
This is NOT in BIDS spaces but could be useful for some old data. It's only an added features and does not break back compatibility.
After looking for the 'TotalReadoutTime' field, one need to load the associated value then proceed.
…liy-get-metadata-bids Synchronising master branches
lukeje
changed the title
|
FYI, based on https://bids-specification.readthedocs.io/en/stable/04-modality-specific-files/01-magnetic-resonance-imaging-data.html I think "AccelFactorPE" corresponds to "ParallelReductionFactorInPlane" with "ParallelAcquisitionTechnique=GRAPPA". There seems to be no variable for parallel reduction factor in 3D, so AccelFactor3D might have to go in "MultibandAccelerationFactor" (though I'm not particularly happy with that, as the physics is actually different between multiband and 3D GRAPPA). |
Slightly more informative error message if number of images and angles don't match; using assert syntax (rather than "if X, then error"); replaced a couple of "echo1", "echo2" in comments that had been missed; matched indexing of P to the rest of the code (avoiding potential errors if P given as 1xN array); no longer need to account for possibility of "extra" elements in the P array (because of explicit assert statement).
|
These was a really stupid mistakes |
Yes, exactly. It first searches local scope for any functions with that name, then searches for files with that name and calls the first function defined in the file, regardless of what it is "called". |
… structs instead of char arrays. Added extra assert statement to check image pairs provided.
Added reordering of B1 maps following their fa
get_metadata_valis splitted into 3 functions:get_metadata_val_classic-- original code of get_metadata_valget_metadata_val_header-- retrieve metadata from niftiget_metadata_val_bids-- retrieve metadata from bidsified jsonThe get_metadata_val checks if received structure contains 'acqpar' and based on it calls one of 3 functions.
This is needed because BIDS forces SI units in his metadata, while hMRI uses most convenient units (often ms).
Some of field names coincides between hMRI and BIDS, so we must know beforehand if which data is it.
get_metadataadds new fieldfilenameto returned structure, containing the filename of current file.It is not the most elegant solution and can hide some fields in structure.
But it is needed because BIDS stores some information in filename (for ex modality) and separate files (bval and vec).
I tested it on one file and it returns same values for hMRI header and BIDS values for majority cases. Exceptions are:
RepetitionTimes-- not defined in BIDS, in local (CRC) bidsified are stored inRepetitionTimeSeriesEchoTimes-- same as aboveProtocolName-- not defined in BIDSPhaseEncodingDirection-- in hMRI results contains space 'ROW ', while in BIDS it is without (not sure if it is important)NumberOfMeasurementsnot BIDSNumberOfSlicesnot BIDSPATparametersnot BIDsAccelFactorPEnot BIDS (possibly corresponds to MultibandAccelerationFactor)AccelFactor3Dnot BIDS (possibly corresponds to MultibandAccelerationFactor)WipParametersnot BIDSDiffusionDirectionretrieved from bvec with some indexingBValuesame as aboveepiReadoutDurationrelated toTotalReadoutDurationbut not exactly the same