GE ASL The number of volumes in the '*_aslcontext.tsv' for this file does not match the number of values in the NIfTI header. (code: 165 - ASLCONTEXT_TSV_NOT_CONSISTENT)

I am using a 3T GE Discovery 750

It outputs from the scanner/dcm2niix are one asl nifti (one volume) and one m0scan nifti (one volume)

my perf directory looks like:
sub-AMWCER20_aslcontext.tsv
sub-AMWCER20_asl.json
sub-AMWCER20_asl.nii.gz
sub-AMWCER20_m0scan.json
sub-AMWCER20_m0scan.nii.gz

In the aslcontext.tsv file; it reads:

volume_type
deltam

But I have tried also include m0scan as well…

The bids-validator error is

	1: [ERR] The number of volumes in the '*_aslcontext.tsv' for this file does not match the number of values in the NIfTI header. (code: 165 - ASLCONTEXT_TSV_NOT_CONSISTENT)
		./sub-AMWCER20/perf/sub-AMWCER20_asl.nii.gz

	Please visit https://neurostars.org/search?q=ASLCONTEXT_TSV_NOT_CONSISTENT for existing conversations about this issue.

I don’t understand. There is only one volume in for either the asl or m0scan…

What am I missing?

Thank you in advance…

1 Like

Please take a look at the dcm2niix GE ASL notes. Tools like exploreASL and FSL’s BASIL are designed for ASL data from Philips and Siemens scanners where the raw labelled and unlabelled images should result in a single 4D volume. In contrast, the GE product sequence computes the contrast between labelled and unlabelled images in k-space and saves a single derived contrast image. Therefore, the DICOM images generated by a GE scanner are roughly similar to the results that exploreASL and BASIL will derive from raw data.

As mentioned in the note, I am aware of a GE research sequence that will store the raw images, but I have never seen the DICOMs associated with these images. I have no idea how dcm2niix will convert those images. If you do have raw ASL data from a GE scanner, can you send me a personal message? We could try to extract as much meta data as possible from these exotic sequences.

The line in the validator that throws this error checks dim[4] from the nifti header and compares it to the number of rows it was able to load from the tsv file - 1 (for the header).

Can you confirm from the nifti header directly that dim[4] is 1?

Hi rwblair,

Yes, that’s what I would think…

fslinfo sub-AMWCER20_asl.nii.gz

gives:

data_type	INT16
dim1		128
dim2		128
dim3		26
dim4		1
datatype	4
pixdim1		1.875000
pixdim2		1.875000
pixdim3		4.000000
pixdim4		4.720000
cal_max		0.000000
cal_min		0.000000
file_type	NIFTI-1+

So dim4 is 1… weird…

I have a similar situation using a Siemens Prisma pASL sequence/json file. File sub-<‘label’>_ses-<‘label’>_run-<‘label’>_aslcontext.tsv (U-INT8 encoded) produces error identical to problem statement in original post. The .tsv file contains:
volume_type
deltam

Checking the respective Nitfi file outputs:
data_type INT16
dim1 128
dim2 128
dim3 24
dim4 1
datatype 4
pixdim1 2.000000
pixdim2 2.000000
pixdim3 5.500000
pixdim4 4.600000
cal_max 0.000000
cal_min 0.000000
file_type NIFTI-1+

@weberam2 did you ever get an answer to this?

Additionally,

print(len(tsv)) returns 2
print(tsv[2]) returns IndexError

after reading tsv file lines…
print(tsvlines) returns [‘volume_type\n’, ‘deltam’]

No, I never got this to work :frowning:

@weberam2 I found a fix for this with my own dataset. Hopefully, this can work for you too and future users!