Hi,
Maybe I'm missing some subtlety of the -div flag, but to properly scale
the image shouldn't one first -div by the original image's max intensity
and then -mul by the max of the desired range (255 in this case)? Also,
maybe someone with more experience than I can speak to whether these
intermediate -div and -mul steps that should be done with avwmaths_64R
to maintain the maximum information about each voxel before the final
avwmaths_8UI conversion.
best,
Stephen
[log in to unmask]
Mark Jenkinson wrote:
> Hi,
>
> To convert the datatype with avwmaths you need to first normalise the
> range (so that it fits into 0-255) and then change the datatype as two
> separate steps. This is because avwmaths_8UI will convert the image
> at the point that it is read in from file, and so if the range is wrong it
> will give you poor output.
>
> To get what you want just do:
> avwmaths image_as_int16 -div 256 normalised_image_int16
> avwmaths_8UI normalised_image_int16 image_as_uint8
>
> Or alternatively, force it using "-datatype char" on your original
> flirt command line.
>
> I'm not sure why your initial flirt produced an output datatype different
> to your input datatype. I cannot replicate that behaviour here.
> However, the above solutions should definitely allow you to achieve
> your desired output.
>
> All the best,
> Mark
>
>
> Ged Ridgway wrote:
>
>> Mark Jenkinson wrote:
>>
>>> Hi,
>>>
>>> Generally Flirt uses same the output datatype (i.e. bit-depth) as the
>>> input image.
>>> You can also force the output datatype using the -datatype option in
>>> flirt.
>>
>>
>> That's odd, here the input image was datatype 2, uint8, and the output
>> was datatype 16, float32. I didn't use the datatype option, and I
>> can't see anything in the fslconf script setting this either. Any idea
>> why FLIRT may have decided on float32 here? (all images are
>> single-file NIFTI, and so is FSLOUTPUTTYPE)
>>
>>> In addition, you can use a range of specific avwmaths calls to change
>>> the
>>> datatype of any image (e.g. avwmaths_32R produced real, 32-bit output;
>>> avwmaths_16SI produces signed integer, 16-bit output; etc.)
>>
>>
>> I've tried
>> avwmaths_8UI image_as_int16 image_as_uint8
>> and
>> avwmaths_8UI image_as_int16 -div 256 image_as_uint8
>> but neither works, the former gives an image that looks like noise,
>> the latter gives an image with min/max of 0/0. I realise I am going in
>> a direction where information will be lost, but it should still be
>> possible, right?
>>
>> I'd be very grateful for more specific info on how to convert between
>> datatypes.
>>
>> Many thanks,
>>
>> Ged.
>>
>>
>>
>>>
>>> Hope this helps.
>>> All the best,
>>> Mark
>>>
>>>
>>>
>>> Ged Ridgway wrote:
>>>
>>>> Hi,
>>>>
>>>> Please can someone describe FSL/FLIRT's procedure for determining
>>>> the bit-depth of output images?
>>>>
>>>> I can't see anything in the FAQ about this, nor any options in
>>>> FLIRT. I have an example where registering a uint8 image to an int16
>>>> reference has resulted in float32 output -- is this to be expected?
>>>> Is it perhaps a consequence of my choosing sinc interp? (I have
>>>> other images registered to the same template which have resulted in
>>>> 16 bit output)
>>>>
>>>> Are there any tools in FSL which can change image bit-depth? It
>>>> appears avwchfiletype can't, though it seems like a useful option to
>>>> me, particularly going from e.g. uint8 to int16 or float32 to
>>>> double, when no information need be lost.
>>>>
>>>> Kind regards,
>>>>
>>>> Ged.
>>>
>>>
|