Hi @LiuYuchen,
I’ve moved your question to a new thread since the original thread was very old, and having a thread with a dedicated title might make it easier to find for others encountering the same issue.
What command could generate the bvec and bval for the dwi_b3000.mif?
Something like this would do:
mrinfo dwi_b3000.mif -export_grad_fsl bvecs bvals
@jdtournier’s usage in the original post (to which I assume @LiuYuchen was referring):
dwiextract dwi.nii.gz -fslgrad bvec bvals -shell 0,3000 dwi_b3000.mif
The -fslgrad option is an import option. So these were simply the bvecs / bvals files that must have been provided alongside image dwi.nii.gz in that case, i.e. coming from whatever software was used to convert DICOM to NIfTI.
I used dwiextract to extract all b0 images from my dwi data and mean them to get one single B0 image, then I want to merge it with the rest b1500 images.
It’s not clear to me exactly why you would want to collapse your b=0 data into a single image volume, but then retain all of the individual b=1500 images. If your intention is to pass these data through dwi2adc, then you would need a mean b=0 volume and a mean b=1500 volume.
mrconvert AP_PA_denoised_degibbs_eddy_biascorrect_meanB0.mif AP_PA_denoised_degibbs_eddy_biascorrect_meanB0.mif -fslgrad meanB0.bvec meanB0.bval -force
Version 3.0.0 onwards does permit use of the same image for input and output; but it’s nevertheless worth being sceptical about when in the context of trying to fix erroneous behaviour.
dwiextract -no_bzero -shells 1500 AP_PA_denoised_degibbs_eddy_biascorrect.mif AP_PA_denoised_degibbs_eddy_biascorrect_B1500.mif -force
You should not need to use the -no_bzero command-line option here. That’s principally in place for utilisation by the dwi2response script wrapper to handle the myriad algorithms at its disposal with all of their different expectations of input data.
It is weird that the B0 image only has one image, how comes the 49 images?
I can’t provide any insight into this myself; I would recommend checking the contents of “command_history” in the image header to make sure that the production of that image does indeed match what you have provided here.
It’s also worth noting I’d previously added a feature request whereby the dwishellmath script should ideally write an updated gradient table for the output image, containing one row per shell (corresponding to the one volume per shell that that script produces). This would mean that the output of dwishellmath mean could be provided directly to the dwi2adc command. Given the potential for confusion around this command I’ve now added a second feature request such that DWIs could be fed directly into the dwi2adc command without having to deal with explicit generation of trace-weighted images.