scaler.local_mean changes the data type to float64

[constantinpape]

And creates an invalid ome.zarr file! See the minimal example below:

import numpy as np
import ome_zarr
import ome_zarr.scale
import ome_zarr.writer
import zarr

vol = np.random.randint(0, 1000, size=(32, 256, 256)).astype("uint16")

scaler = ome_zarr.scale.Scaler()
mip = scaler.local_mean(vol)

loc = ome_zarr.io.parse_url("./data", mode="w")
group = zarr.group(loc.store)

axes = [ 
    {"name": "z", "type": "space", "unit": "micrometer"},
    {"name": "y", "type": "space", "unit": "micrometer"},
    {"name": "x", "type": "space", "unit": "micrometer"},
]
ome_zarr.writer.write_multiscale(mip, group, axes=axes)

And after running this with ome-zarr 0.5.2 (from conda-forge):

$ cat data/0/.zarray
...
"dtype": "<u2"

$ cat data/1/.zarray
...
"dtype": "<f8"
...

[sbesson]

Thanks @constantinpape and definitely agreed it should be fixed to generate resolutions with the same dtype. In addition to the implementation fix, there might be an RFE at the specification level as I cannot find an unambiguous statement that enforces that all datasets in a multiscales group MUST have the same dtype

[constantinpape]

In addition to the implementation fix, there might be an RFE at the specification level as I cannot find an unambiguous statement that enforces that all datasets in a multiscales group MUST have the same dtype

Yes, this should absolutely be fixed in the spec. Note that we already have this in an issue: https://github.com/ome/ngff/issues/100 / https://github.com/ome/ngff/issues/2 (first one is a collection of minor points that should be tackled that includes this one).