threshold_local does not preserve data type

[hirschmichael]

Describe the issue:
dask_image.ndfilters.threshold does not preserve the data type. If the input image is dtype np.single then the output is np.double

Minimal Complete Verifiable Example:

import numpy as np
import dask.array as da
from dask_image.ndfilters import threshold_local

data = da.random.normal(size=(100, 200, 200)).astype(np.single)
print(f'{data.dtype=}')
print(f'{threshold_local(data, [5, 10, 10]).dtype=}')

Anything else we need to know?:

Environment:

• Dask version: '2025.10.0'
• Python version: Python 3.12.3 (main, Mar 3 2026, 12:15:18) [GCC 13.3.0]
• Operating System: Ubuntu 24.04.4 LTS
• Install method (conda, pip, source): pip

[m-albert]

Hi @hirschmichael , thanks a lot for the report and the MCVE.

Would you be interested in creating a PR which addresses this?

[GenevieveBuckley]

That'll be due to this line, which converts arrays to 64 point float precision right at the start of any threshold_local function:

dask-image/dask_image/ndfilters/_threshold.py

Line 72 in a513d9c

image = image.astype(np.float64)

I think I put that in there to avoid possible artifacts (but that was six years ago, so I don't remember specific details).

[GenevieveBuckley]

Update: I have experimented, and removing that line of code does lead to the behaviour @hirschmichael was expecting.

• Pros: this matches the behaviour of the global threshold functions (gaussian, etc.), which do not automatically upgrade arrays to np.float64 the way threshold_local has been doing.
• Cons: I have some vague sense that maybe there was an important reason that we had that line there in the first place. Can somebody help argue the case for or against it?

[hirschmichael]

@GenevieveBuckley : The scipy.ndimage filters will operate on the data type of the input data. This can lead to an unintended loss of precision. Casting to np.float64 ensures the best precision of the results. The sequence:

1. cast to double precision
2. apply filter
3. cast to original data type
   will have a different result than applying the filter directly.

I'm not quite sure how memory efficient the back and for casting is in the context of dask memory management.

[hirschmichael]

For example,

1. If the data is np.single the user might want to operate with that, without any casting
2. If the data is np.uint16 casting might be desired to avoid loss of precision