mriconvert: lcni-users: FSL/Nifti output and Minnesota multiband -- IMPORTANT!!

[Jolinda Smith]

MRIConvert does not check whether applying the rescale slope & intercept will cause data loss, nor does it change to output data type when rescaling is applied. This will be rectified when the other issue is fixed (at the very least a warning message will be added, but we should be able to put in a real fix). If the output type is nifti, there's no need to apply the rescale slope and intercept anyway, since those items are written to the nifti header.

Still no word from the FSL mailing list on whether FSL now supports 16 bit unsigned data. Perhaps it was a bad idea to post a question on a Friday evening.

Jolinda

On Tue, 24 Feb 2015 03:48:30 -0800, Andreas Bartsch <bartsch at radvisory.net> wrote:

> Hi,
>
> yes  the latter would be good to know. I always assumed that there is no
> loss involved.
> Hope all is well,
> best regrads-
> Andreas
>
> Von:  "jolinda at uoregon.edu" <jolinda at uoregon.edu>
> Antworten an:  MRIConvert user's list <mriconvert at lists.uoregon.edu>
> Datum:  Dienstag, 24. Februar 2015 12:11
> An:  MRIConvert user's list <mriconvert at lists.uoregon.edu>,
> "lcni-users at lists.uoregon.edu" <lcni-users at lists.uoregon.edu>
> Betreff:  Re: mriconvert: lcni-users: FSL/Nifti output and Minnesota
> multiband -- IMPORTANT!!
>
> Largest image pixel value does not include intercept and slope. The issue
> does not necessarily involve rescaling, but that does add another wrinkle.
> Thanks for bringing it up. I'll need to refresh my memory regarding whether
> mriconvert changes the output data type when "apply rescale slope and
> intercept" is selected. It clearly should to avoid loss of data, but I don't
> remember if it does.
>
> Sent from my HTC
>
> ----- Reply message -----
> From: "Roman Fleysher" <roman.fleysher at einstein.yu.edu>
> To: "MRIConvert user's list" <mriconvert at lists.uoregon.edu>,
> "lcni-users at lists.uoregon.edu" <lcni-users at lists.uoregon.edu>
> Subject: mriconvert: lcni-users: FSL/Nifti output and Minnesota multiband --
> IMPORTANT!!
> Date: Mon, Feb 23, 2015 6:34 PM
>
> Dear Jolinda,
>
> Does LargestImagePixelValue include intercept and scale? Is the issue
> related to the original pixel values (before scaling) or after?
>
> Thank you,
>
> Roman
>
> ________________________________________
> From: mriconvert-bounces at lists.uoregon.edu
> [mriconvert-bounces at lists.uoregon.edu] on behalf of Jolinda Smith
> [jolinda at uoregon.edu]
> Sent: Monday, February 23, 2015 12:12 PM
> To: lcni-users at lists.uoregon.edu; mriconvert at lists.uoregon.edu
> Subject: Re: mriconvert: lcni-users: FSL/Nifti output and Minnesota
> multiband -- IMPORTANT!!
>
> Local users: there is now a tool on bordeaux called max_pixel_check that
> recursively checks all dicom files in a directory and returns the names of
> any with maximum pixel values > 32767. To use, just type "max_pixel_check
> [directory name]". If the maximum pixel value for all files is < 32767, you
> can use MRIConvert with these files with no changes to your processing
> stream. If you have any with pixel values in the 60,000 range let me know,
> we need to adjust the sequence (I've seen this in a phantom but not in
> vivo).
>
> Non-local users: you can check your own dicoms by looking at the tag
> "Largest image pixel value" (0028,0107). If you have dcmtk installed, you
> can use this command to output this value for all files in a directory:
>
> dcmdump +sd +r +P LargestImagePixelValue +F [directory_name]
>
> Jolinda
>
> On Fri, 20 Feb 2015 11:36:36 -0800, Jolinda Smith <jolinda at uoregon.edu>
> wrote:
>
>> Hi everyone,
>>
>> A quick but important note regarding the FSL/Nifti output of MRIConvert and
> the multiband epi from Minnesota. First a review: MRIConvert has two options for
> nifti output: regular and FSL/nifti. This was necessary in the early days of
> nifti, until FSL fully supported the format. One important difference between
> the two is that "regular" nifti keeps the data in the same representation as the
> original dicom (typically unsigned 16 bits for MR). FSL did not support unsigned
> 16 bit data, but did support signed 16 bit data. Since MR images typically only
> use the first 12 bits, MRIConvert calls it signed 16 bits for the FSL/nifti
> version.
>>
>> HOWEVER, the multiband sequence from Minnesota uses the full 16 bit dynamic
> range, so this conversion is no longer safe. I'm waiting to hear back from the
> FSL mailing list regarding whether FSL now supports unsigned 16 bit data. If it
> does, we will eliminate the FSL nifti variant, as it's no longer necessary. If
> it doesn't, we'll convert data that uses all 16 bits to float.
>>
>> Until that happens, you have two choices if you are using FSL & the Minnesota
> multiband sequence:
>>
>> 1. Use fsl/nifti output, and check the range of your data. You can do this
> with fslstats filename -R. If your minimum value is 0 or higher, and your
> maximum is less than 32768 (and it will be if you are using fsl/nifti output),
> you are safe to continue as before. You'll need to do this for every file.
>>
>> 2. Use nifti output, and change the datatype to float: fslmaths input_file
> output_file -odt float.
>>
>> I will keep everyone posted on further developments.
>>
>> Jolinda
>>
>>
>
>
> --
> Jolinda Smith, Ph.D.
> MR Physicist
> Lewis Center for Neuroimaging
> University of Oregon
> Eugene, OR USA
> _______________________________________________
> mriconvert mailing list
> mriconvert at lists.uoregon.edu
> https://lists-prod.uoregon.edu/mailman/listinfo/mriconvert
>
> _______________________________________________
> mriconvert mailing list
> mriconvert at lists.uoregon.edu
> https://lists-prod.uoregon.edu/mailman/listinfo/mriconvert
> _______________________________________________ mriconvert mailing list
> mriconvert at lists.uoregon.edu
> https://lists-prod.uoregon.edu/mailman/listinfo/mriconvert
>
>


-- 
Jolinda Smith, Ph.D.
MR Physicist
Lewis Center for Neuroimaging
University of Oregon
Eugene, OR USA