[joss] Handling non-8bit images?

[sneakers-the-rat]

Part of: openjournals/joss-reviews#6336

I can't tell if this is a bug or not.

It looks like the expectation for 8-bit images is encoded in a few places (ctrl+f for 255), and I'm wondering if that's a problem for images that aren't 8-bit.

I created a version of the demo data cast to uint16:

from nibabel import load
from nibabel.nifti1 import save, Nifti1Image
import numpy as np

img = load('test-image.nii.gz')
data = img.get_fdata()
data16 = data.astype(np.uint16) * 256

img16 = Nifti1Image(data16, np.eye(4))
save(img16, 'test-image-16.nii.gz')

and it looks like the image is correctly loaded, and I'm able to do all the thresholding correctly as expected.

The threshold mask shouldn't be a problem since that's just a boolean array, but I do notice that control-points.json takes values from 0-255. So it seems like the image is downscaled to 8-bit for use internally within thresholdmann, but that might pose a problem for someone who uses a different bit depth, since they'll have to convert the ranges to the source range.

How hard would it be to keep the values in the original range of the image, either internally in the program, or recast at export time? or is this not a problem?

[katjaq]

That's a very good question. We don't actually do anything with the user's raw MRI data – they just provide it to the app so they can create a mask for their dataset. The MRI data is handled by mriviewerjs which handles the different formats – so your modified demo data was loaded without problem. For the mask, it should be all fine. For the control-points, their values are displayed as integers in the interface, but upon saving are saved as floats. So we think it's not a problem.

[sneakers-the-rat]

ok! works for me