I am starting with this 16-bit image:

If I convert it with Image > Type > 8-bit in Fiji I get:

If I denoise this image I get this result (which I'm happy with):

But if I try to convert it with e.g. result = ops.unary("convert.int8").input(img).apply() I get.. a 32-bit image??

convert.uint8 is 8-bit, at least..

Smoothing the uint-8 version requires bumping up the smoothing strength significantly and it still doesn't look great:

So, how I account for this behavior is:

• In the ImageJ type conversion, values are scaled proportionately to the new range
• In the SJ Ops type conversion, values are directly translated. This can result in type overflow (note the split tails in both the int8 and uint8 conversions) which fundamentally changes the behavior of subsequent image processing.
• These byte casts are perhaps not working as intended?

@gselzer @ctrueden Is there rationale for not scaling the converters to the target data range?