You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Short version is I have not so far been able to reproduce this exact problem. blosc with cname=zstd produces the effectively the same size total output, with some small discrepancies in individual chunks. cc @joshmoore
As discussed in the most recent NGFF challenge call, I tried to reproduce the behavior noted in zarr-developers/zarr-python#2171 here.
Short version is I have not so far been able to reproduce this exact problem. blosc with
cname=zstd
produces the effectively the same size total output, with some small discrepancies in individual chunks. cc @joshmooreI tested with these 3 public datasets:
stack&sizeX=8192&sizeY=8192&sizeZ=4000&pixelType=uint16.fake
(simulating dimensions of an EM volume)With bioformats2raw 0.9.4:
Note that omitting
--compression-properties "cname=zstd"
will use thelz4
cname instead, see https://github.com/zarr-developers/jzarr/blob/533c8bb4197f57bd664edc6c62b3f5cd0de262ba/src/main/java/com/bc/zarr/CompressorFactory.java#L220. For the slide test, the defaultlz4
cname results in an output dataset that is approximately twice the size as with the alternatezstd
cname.Converting the generated v2 datasets to v3, using the current state of #8:
Double-checking that the compression options match:
and then comparing total sizes in bytes:
and a few selected chunk files:
Some things we may want to improve, either here or as part of future work in bioformats2raw (in which case this issue can be moved):
zstd
?The text was updated successfully, but these errors were encountered: