Closed psobolewskiPhD closed 1 month ago
Thanks for the report. I'll have a look into it...
Because I can't just let stuff be, the issue is here: https://github.com/ome/ome-ngff-validator/blob/a3ea7514c1aa99d510d034ccb61282cf758f929e/src/JsonValidator/MultiscaleArrays/ZarrArray/index.svelte#L20-L24
uint16
has 1
and uint8
has 8
so the calculation is wrong.
I don't know enough javascript to fix this -- is a dict-like structure possible to translate np.dtypes to byte values, else use the array-protocol ones you have?
Should be fixed now (in https://github.com/ome/ome-ngff-validator/pull/36/commits/2853654ce9c93803fe9e1ecae3f7620f23dc6f60)
As far as I can tell, when using the validator for a zarr that has numpy.dtype, e.g. uint16, the array size and chunk sizes do not appear to be correctly computed. See, e.g.: https://deploy-preview-36--ome-ngff-validator.netlify.app/?source=https://uk1s3.embassy.ebi.ac.uk/idr/share/ome2024-ngff-challenge/idr0051/180712_H2B_22ss_Courtney1_20180712-163837_p00_c00_preview.zarr/0/
I'm pretty sure this should be:
and
uint16
means 2 bytes per pixel, so:So in this case, the real size is ~2x the reported size.
Here's another case: https://deploy-preview-36--ome-ngff-validator.netlify.app/?source=https://storage.googleapis.com/jax-public-ngff-2024/KOMP/adult_lacZ/ndp/A1cf/24325_K24230_FColon.zarr/0/
This time we have
uint8
so 1 byte per px.So the reported is ~8x larger.
I suspect what is happening is that the
8
inuint8
is being used, rather than treating it as1 byte/px
.Maybe the validator isn't handling cases of numpy & python dtypes vs array-protocol dtypes ?(https://numpy.org/doc/stable/reference/arrays.interface.html#arrays-interface)