I have been working with CTs since a few years now so I have seen lots of them. I’ve had the observation the scalar range difference is always between 8k or 5k (e.g: min=-3024, max=1890), but the datatype used on them allows int16 range, which means from -32768 to +32767.
That means that probably one could get away with using 2 or 3 less bits to represent each voxel value on the CT (i.e. int14 or int13, though not supported by real computer architectures). And I wondered if I could use less even bits without losing interpretability of the CT, so I used SimpleFilters to “scale down” a int16 CT to int8 (see pictures below respectively)
That draws me to the question, seeing that is possible to run SlicerTotalSegmentator on this CT in a couple of minutes, and that int8 is 256 times smaller than int16, would it be possible to re-train TotalSegmentator to work with int8 CTs to return results in around 1 second?
Often 8 bits per pixel could be enough if you need to distinguish bone from soft tissues. However, there are important use cases where 8-bits dynamic range for the entire CT image is insufficient, for example when differentiating between soft tissues (common in brain CT images) or doing digital subtraction (difference between native and opacified images). It would be also somewhat inconvenient to manage the scaling information that converts HU to image-specific 8-bit intensity range.
Int8 is just 2x smaller not a big difference. But more importantly, all computations in the neural network is done in floats anyway.
You have a good point in that it is important to pay attention how you convert segmentation inputs/outputs between the external int8 or int16 and the internal float, as it greatly affects memory usage and therefore computation time. We recently reduced MONAIAuto3DSeg computation time on a 16GB laptop from 800 seconds to 120 seconds by converting output to int16 earlier (by reducing memory need from 17GB to 3 GB).
