On the fly editing much slower for n5 than hdf5 about pybdv HOT 2 CLOSED

Ok - so more testing! The biggest contributor seems to be the chunk size.
Each time it writes a slice, an area is read from the image with a z depth == the highest amount of downsampling (i.e. 8 for the example above). This is made much more efficient by using a chunk size in z == the highest amount of downsampling. (before I was using a chunk size of 1 in z)
Using bigger chunks in xy is also more efficient for read/write times.

With a chunk size of (8, 128, 128), the times can be improved to around:

Converted image in 1.1741 seconds
Converted image in 2.0598 seconds
Converted image in 2.0561 seconds
Converted image in 2.2036 seconds
Converted image in 2.2064 seconds
Converted image in 2.2776 seconds
Converted image in 2.4407 seconds
Converted image in 2.4372 seconds
Converted image in 1.2728 seconds
Converted image in 2.0469 seconds

So still slower than hdf5, but fast enough for now! I'll close this.

from pybdv.

I looked into this a bit more, and the slowdown seems to come from downsampling in z. If I change the downscale_factors to [[1,2,2], [1,2,2], [1,2,2]] then all images are converted in ~1 second.

I profiled it, and it seems like most time is spent in _check_shape_and_position_scaling() reading data from the n5 file here: https://github.com/constantinpape/pybdv/blob/master/pybdv/bdv_datasets.py#L62 So it seems reading from n5 is slower than reading from hdf5

from pybdv.