After a short break due to my summer term exams I am glad to be back, and even gladder to say that the project is coming to an end. I spent today integrating the lazy connected components operator from my own repo to my fork of lazyflow, and added some features on the way (e.g. slots for exporting/importing HDF5 data). The operator conforms to what is expected by the currently used operator OpLabelVolume, and transition between classic mode and lazy mode should be as easy as switching the input slot “Method” of OpLabelVolume to “lazy”. Even saving a project in classic mode and loading the data to lazy mode should be no big deal (although I would not recommend that).

Two things remain to be decided:

  • OpLabelVolume does not use chunk shapes, so we have to (a) guess the optimal shape or (b) rely on what may or may not be given by meta.optimal_shape.
  • Who decides when to use which mode? I would favour using lazy mode with appropriate chunk shape, but that introduces overhead that could be avoided.

Speaking of overhead, I got some data on this. Measurements were made on a 256^3 volume, on my trusty AMD Phenom II X6. A slightly different version of the benchmark script can be found in the repo.

LazyCC (1 chunk) LazyCC (64 chunks) OpLabelVolume.CachedOutput
Empty Volume 3602.864ms 1369.749ms 2935.961ms
Dense Labels 4742.257ms 1106.593ms 4053.926ms
Sparse Labels 4057.741ms 1683.202ms 2926.479ms

For an (unfair) comparison:

OpLabelVolume.Output
Empty Volume 2385.448ms
Dense Labels 3639.021ms
Sparse Labels 2383.570ms