Dear experts,
A couple of months ago we decided to add gibbs correction to tractoflow using your implementation.
I’ve got a user who reported me that the output from mrdegibbs is quite big compare to the original dwi (18Mo → 150Mo). We’ve been using mrdegibbs 3.0.4 in our container. I checked the datatype using mrinfo and it’s seems to be the same. The results are quite nice but I would like to know if it’s something normal. I don’t really understand why I’m getting a file almost 10 times bigger than the original. Thank you in advance for your help and feedback.
Arnaud
@jdtournier, when you have some time can you tell me if the size of the output make sense please ?
Thank you in advance.
Arnaud
Hi @arnaudbore,
Sorry, that’s a new one for me… My best explanation is that the original data was stored in a compressed format with integer values (even if stored as floats), which would compress very well. The output on the other hand will compress much less easily as the floating-point values being produced won’t fall into neat integer values any more. This might be what you’re seeing – but without access to the data, I won’t be able to confirm.
Would that make sense in your case?
Cheers,
Donald.
Hi @jdtournier ,
Thank you for you quick answer. It does not seem to be the case with my data. Here is a link to dowload it. Here it is what I have:
→ mrdegibbs dwi_denoised.nii.gz dwi_denoised_g.nii.gz
mrdegibbs: [100%] uncompressing image “dwi_denoised.nii.gz”
mrdegibbs: [100%] performing Gibbs ringing removal
mrdegibbs: [100%] compressing image “dwi_denoised_g.nii.gz”
→ ll -h
total 172M
drwxrwxr-x 2 bore bore 4.0K Jul 17 09:50 ./
drwxrwxr-x 22 bore bore 4.0K Jul 17 09:47 …/
-rw-rw-r-- 1 bore bore 154M Jul 17 09:51 dwi_denoised_g.nii.gz
-rw-rw-r-- 1 bore bore 19M Jul 13 17:13 dwi_denoised.nii.gz
Thanks again for your help.
Best,
Arnaud
Hi @arnaudbore,
Thanks for sending the data through. It’s more or less what I thought: the data are compressed, and the file sizes before & after mrdegibbs are as you stated:
$ ls -lh dwi_denoised*
-rw-r--r-- 1 donald donald 154M Jul 17 15:54 dwi_denoised_g.nii.gz
-rw-r--r-- 1 donald donald 19M Jul 17 15:48 dwi_denoised.nii.gz
But by the time the data are uncompressed, they are in fact identical:
$ gunzip dwi_denoised_g.nii.gz
$ gunzip dwi_denoised.nii.gz
$ ls -lh dwi_denoised*
-rw-r--r-- 1 donald donald 215M Jul 17 15:54 dwi_denoised_g.nii
-rw-r--r-- 1 donald donald 215M Jul 17 15:48 dwi_denoised.nii
Looking at the data in detail, the reason seems to be primarily because the background in the input image is zero’d out, so all of that will compress to essentially nothing. By the time it’s been run through mrdegibbs, it’s no longer exactly zero, and certainly not constant – so that won’t compress anywhere near as well.
I hope that all makes sense…?
Cheers,
Donald
I didn’t take a look at the background 
Would it make to have an optional mask for mrdegibbs ?
Thank you again
Arnaud
To be honest, I’m surprised to see an input with the background masked out: in theory, that would affect the performance of the Gibbs ringing removal… If you want to mask the output after mrdegibbs, I don’t think that would be a problem though…
Cheers,
Donald
Great thank you for your input.
Arnaud