constantinpape / pybdv

python tools for BigDataViewer

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

On the fly editing much slower for n5 than hdf5

K-Meech opened this issue · comments

I'm initialising a dataset like so:

pybdv.initialize_bdv(path, (50, 1536, 2048) , np.uint8, downscale_factors=[[2,2,2], [2,2,2], [2,2,2]],
                             resolution=resolution, unit="micron", chunks=(1, 64, 64))
current_dataset = BdvDataset(path, setup_id=0, timepoint=0)

Then writing slice by slice (for 10 slices) like so:

# add dummy first dimension to slice, so it's 3d
slice = np.expand_dims(slice, axis=0)
current_dataset[slice_no:slice_no+1, 0:current_dataset_shape[1], 0:current_dataset_shape[2]] = slice

For hdf5 this takes about 29 seconds, compared to around 147 seconds for n5. It also seems like the time to convert each slice increases for n5, while it doesn't really for h5.
Example times for 10 slices on n5:

Converted image in 3.3464 seconds
Converted image in 6.2296 seconds
Converted image in 8.5396 seconds
Converted image in 12.5240 seconds
Converted image in 16.3049 seconds
Converted image in 19.7258 seconds
Converted image in 23.3828 seconds
Converted image in 27.1164 seconds
Converted image in 2.7939 seconds
Converted image in 6.3479 seconds

@constantinpape Any ideas if this can be improved for speed? Or is it always slower to write many small files vs one big hdf5?

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

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.