Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NIfTI/JSON metadata consistency checks #79

Open
effigies opened this issue Mar 15, 2019 · 1 comment
Open

NIfTI/JSON metadata consistency checks #79

effigies opened this issue Mar 15, 2019 · 1 comment
Labels
enhancement New feature or request

Comments

@effigies
Copy link
Contributor

Based on a discussion in: bids-standard/bids-specification#138

The JSON metadata fields PhaseEncodingDirection, SliceEncodingDirection have corresponding values in the NIfTI header field dim_info:

JSON NIfTI
"PhaseEncodingDirection": "i[-]" (dim_info >> 2) & 0x03 == 1
"PhaseEncodingDirection": "j[-]" (dim_info >> 2) & 0x03 == 2
"PhaseEncodingDirection": "k[-]" (dim_info >> 2) & 0x03 == 3
"SliceEncodingDirection": "i[-]" (dim_info >> 4) & 0x03 == 1
"SliceEncodingDirection": "j[-]" (dim_info >> 4) & 0x03 == 2
"SliceEncodingDirection": "k[-]" (dim_info >> 4) & 0x03 == 3

Additionally, SliceTiming can be consistent or inconsistent with the following fields:

    slice_duration = If this is positive, AND if slice_dim is nonzero,
                     indicates the amount of time used to acquire 1 slice.
                     slice_duration*dim[slice_dim] can be less than pixdim[4]
                     with a clustered acquisition method, for example.

    slice_code = If this is nonzero, AND if slice_dim is nonzero, AND
                 if slice_duration is positive, indicates the timing
                 pattern of the slice acquisition.  The following codes
                 are defined:
                   NIFTI_SLICE_SEQ_INC  == sequential increasing
                   NIFTI_SLICE_SEQ_DEC  == sequential decreasing
                   NIFTI_SLICE_ALT_INC  == alternating increasing
                   NIFTI_SLICE_ALT_DEC  == alternating decreasing
                   NIFTI_SLICE_ALT_INC2 == alternating increasing bids-standard/legacy-validator#2
                   NIFTI_SLICE_ALT_DEC2 == alternating decreasing bids-standard/legacy-validator#2
  { slice_start } = Indicates the start and end of the slice acquisition
  { slice_end   } = pattern, when slice_code is nonzero.  These values
                    are present to allow for the possible addition of
                    "padded" slices at either end of the volume, which
                    don't fit into the slice timing pattern.  If there
                    are no padding slices, then slice_start=0 and
                    slice_end=dim[slice_dim]-1 are the correct values.
                    For these values to be meaningful, slice_start must
                    be non-negative and slice_end must be greater than
                    slice_start.  Otherwise, they should be ignored.
@effigies
Copy link
Contributor Author

Guess I forgot to finish this up, and the "Edit" button isn't working for me right now.

It would be good to validate consistency at least insofar as the NIfTI metadata should not directly contradict the JSON metadata. In many cases, the NIfTI header will have \x00 bytes in these fields, so that should probably not fail the check. Additionally, some values permissible in the JSON metadata may not be representable in NIfTI (e.g., the polarity of the phase encoding direction is not specifiable in NIfTI), so we should be aware of that in any checks proposed.

@effigies effigies added the enhancement New feature or request label Nov 5, 2024
@effigies effigies transferred this issue from bids-standard/legacy-validator Nov 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant