users > average_image : output in 16 bits?
Showing 1-4 of 4 posts
Results per page:
May 7, 2019  07:05 AM | Guillaume Le Goc
average_image : output in 16 bits?
Hi there,
I am using CMTK to register several stacks on one, and then I averaged them to make a mean stack.
To do so, I used the included average_images tool. But I see there's only two options for the output image : single (which result in a 32bits image) and double.
I would like to have a 16 bits output stack. All input stack are in 16 bit.
I tried to convert it to 16bit through ImageJ, but some values are out of range and cap at 65535. How is it possible since all input are 16bit (65535 max) ?

Thanks for your help and work,

May 7, 2019  10:05 AM | Greg Jefferis
RE: average_image : output in 16 bits?
Torsten is the right person to respond here and you may need to give an example e.g. some small input images and an output image if debugging is required.

Assuming that you have used the default behaviour of average_images, I believe it should just calculate the simple mean of the input images. What format are they in? Is it possible that they have some kind of calibration (which could be stored in a nii file).

You could show stack histograms from ImageJ or use the cmtk histogram tool to show full histogram inc min / max information for your inputs and outputs.


May 9, 2019  07:05 AM | Guillaume Le Goc
RE: average_image : output in 16 bits?
I think there was a problem with my preprocessing and rescaling. It is now fixed and I had no trouble converting the output 32bit average image in 16bit with ImageJ. Still, it could be a nice feature to add in the future to the average_images function.
For reference, I used NRRD file generated from TIFF stacks through MATLAB.

Thanks for your help.

May 9, 2019  06:05 PM | Torsten Rohlfing - Google LLC
RE: average_image : output in 16 bits?
Hi Guillaume - sorry for the delay.

CMTK actually has an image conversion tool, convertx, which supports pixel type conversions.

As for the question why your average images exceeded the value range of the input images - when you reslice images using higher-order interpolation (cubic or sinc), then such overruns can occur simply because of the coefficients of the interpolation kernels. Not sure this is what happened here, but if you did use higher-order interpolation, it would be absolutely expected.