Sparse bitmask #44
Sparse bitmask #44
Conversation
The tree is truncated such that it does not contain boolean value-nodes all the way to the leafs. Instead, leafs store bitmasks of a specified size. Also contains algorithms to efficiently compute the number and bounding box of set pixels in such bitmasks.
A RandomAccessible<NativeBoolType> that grows on demand. SparseBitmask.tree() provides the underlying SparseBitmaskNTree. SparseBitmask.region() provides a view as IterableRegion, with efficient computation of bounding box and iteration of set pixels.
| @@ -197,5 +197,10 @@ Jean-Yves Tinevez and Michael Zinsmaier.</license.copyrightOwners> | |||
| <artifactId>junit-benchmarks</artifactId> | |||
| <scope>test</scope> | |||
| </dependency> | |||
| <dependency> | |||
| <groupId>sc.fiji</groupId> | |||
| <artifactId>bigdataviewer-vistools</artifactId> | |||
There was a problem hiding this comment.
The Maven build on Travis now fails because bigdataviewer-vistools contains a transient dependency on imglib2-roi, creating a circular dependency.
As this is a test scope dependency only, the issue can be avoided by adding an exclusion:
<dependency>
<groupId>sc.fiji</groupId>
<artifactId>bigdataviewer-vistools</artifactId>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>net.imglib2</groupId>
<artifactId>imglib2-roi</artifactId>
</exclusion>
</exclusions>
</dependency>
I'm not sure though if it is the best way to address this.
There was a problem hiding this comment.
Interesting hack—I didn't know that worked.Personally, I'd vote for the usage examples requiring vistools to move downstream. Perhaps into vistools itself, since it already depends on imglib2-roi transitively.
|
@tpietzsch I made some quick changes.
|
tpietzsch
force-pushed
the
sparse-bitmask
branch
from
522370b
to
47ca2a9
Compare
The functionality of Bitmask is very much independent of the class Tree. It should be an independent class.
Only on bit of SparseBitmask is true. But SparseBitmask.region().cursor() seems to have two elements?
tpietzsch
force-pushed
the
sparse-bitmask
branch
from
47ca2a9
to
e9e97ca
Compare
|
@maarzt I fixed the bug. Thanks for noticing! |
|
Bitmask is probably not a got term to refer to a black/white image. Mask or Bitmap are preferable. Bitmask is rather one dimensional. |
* numSet -> numberOfOnes (numSet is too ambiguous. Is it a set of numbers?) * leafDims -> dims * bytes -> data (The javadoc comment suggests this renaming.) Add method byteMask similar to byteIndex to reduce code duplication.
The design of this class is specific to it's use in Tree this should be reflected by the name
The sparse bitmaps in Labkit use list's of coordinates to store only the white pixels.
If a set operation sets NodeData.children or NodeData.bitmask to zero, get will return NodeData.value.
That way GrowableTree and Tree can be better distinguished. Also reading Tree becomes thread-safe. The tree can always be red in any thread, only the write operations need to be synchronized.
This has a huge performance improvement for cuncurrent reading.
|
This pull request has been mentioned on Image.sc Forum. There might be relevant details there: |
SparseBitmaskis aRandomAccessible<BoolType>based on nTree (quadtree, octree, ...) with little bitmasks (basicallyArrayImg<BitType>) in the leafs. It's aRandomAccessible(notInterval). The tree grows on demand, just set pixels wherever...There are efficient algorithms for
true) pixels,true) pixels.These are provided through a (read-only) view as an
IterableRegion.Some usage examples are in src/test/.
I'm happy with the underlying tree and bitmask stuff (
SparseBitmaskNTree,Tree,GrowableTree).However, packaging as a
RandomAccessibleinSparseBitmaskrequired some trade-offs that are not so clear and depend on use case. I would be happy about some input...In particular, read/write of pixels is protected by a
ReentrantReadWriteLockthat is acquired per pixel access. It would be nice to have this more coarse-grained, but I don't know how.Also,
SparseBitmask.region()providesIterableRegionview of the current state, and will throwConcurrentModificationExceptionwhen the bitmask is modified. There are some minor trade-offs there as well, but read/write locking is the major problem.