Split can leave size-0 supervoxels in the mapping #289
Assignees
Labels
Comments
|
FWIW, According to the table above, it seems that all of the problematic cases involve the |
|
The latest production node ( Click for table |
|
Note to self: Due to the fact that I've been writing "small" supervoxels as 0-byte files, I should go back and verify that I haven't inadvertently overwritten a few valid mesh files with empty files in cases like this. (If the sv had a non-zero mapping, but a size of 0, I might have written an empty file, whereas I should have left it alone.) |
DocSavage
added
the
unbounded time
|
Assume this isn't urgent since this is for |
|
Apparently this issue can affect One example I ran into on the male CNS is supervoxel According to ...but it has no size: I discovered the problem because I attempted to use it in a cleave, which triggered the following error: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Apparently the
splitoperation can leave behind supervoxels in the/mappingthat should not be there (they don't exist any more, or have size 0, depending on which endpoint you use).Here's a table showing various split events for which at least one supervoxel was left in the mapping, despite it having 0 size. In this table, the
_sizeand_mappingare shown for the UUID in which the split event occurred.The table is attached here as CSV, but also pretty-printed below.
Notes:
oldsupervoxel lingers in the mapping because the mutation log didn't store the necessary info back then. Newer versions of DVID resolved this.9e0d(the bottom of this table). It seems that the RESULT supervoxels can sometimes be left with 0 size, and yet remain in the/mapping.Click for table
The text was updated successfully, but these errors were encountered: