we are currently pretty strict about the type of fill values -- for an int data type, the json string "0" is not a valid fill value, because it's a string, which is not an int. Mixing up ints for stringified ints is a pretty common mistake, so we should consider allowing anything remotely int-like to be a fill value for an int.
a caveat of doing this is that metadata documents cannot be guaranteed to round-trip through zarr python, because an array with an integer dtype and a fill value of "0" would be resaved with the fill value 0. if that's really important, we could consider a "strict" mode that does guarantee round-tripping.
see this zulip thread#NGFF > N5 library produces zarr that is not readable in python for context
we are currently pretty strict about the type of fill values -- for an int data type, the json string "0" is not a valid fill value, because it's a string, which is not an int. Mixing up ints for stringified ints is a pretty common mistake, so we should consider allowing anything remotely int-like to be a fill value for an int.
a caveat of doing this is that metadata documents cannot be guaranteed to round-trip through zarr python, because an array with an integer dtype and a fill value of
"0"would be resaved with the fill value0. if that's really important, we could consider a "strict" mode that does guarantee round-tripping.see this zulip thread#NGFF > N5 library produces zarr that is not readable in python for context