Bytes compatible saving csm

[ceesem]

This branch adds two features:

• Introduces a new format for saving annotation tables associated with meshwork objects that is based directly on json and h5py without going through pytables. This allows it to be compatible with bytesIO objects and thus cloudfiles.
• Richer skeleton metadata that holds skeletonization parameters in a structured dataclass. This accomplishes the same goal as in #70 with a bit more structure.

@dataclass
class SkeletonMetadata:
    root_id: int = None
    soma_pt_x: float = None
    soma_pt_y: float = None
    soma_pt_z: float = None
    soma_radius: float = None
    collapse_soma: bool = None
    collapse_function: str = None
    invalidation_d: float = None
    smooth_vertices: bool = None
    compute_radius: bool = None
    shape_function: str = None
    smooth_iterations: int = None
    smooth_neighborhood: int = None
    smooth_r: float = None
    cc_vertex_thresh: int = None
    remove_zero_length_edges: bool = None
    collapse_params: dict = None
    timestamp: float = None
    skeleton_type: str = None

    _extra_fields = ["root_id", "timestamp", "skeleton_type"]

    def __init__(self, **kwargs):
        names = [f.name for f in fields(self)]
        for k, v in kwargs.items():
            if k in names:
                if isinstance(v, np.ndarray):
                    v = v.tolist()
                setattr(self, k, v)

    def skeletonize_kwargs(self):
        params = asdict(self)
        for k in self._extra_fields:
            params.pop(k)
        return params

This class will accept a dict and, for any values that match its fields, will fill them in. The skeleton_type string is there to provide some descriptive metadata that could be used as a tag, e.g. "pcg_skel_chunk_skeleton" to indicate source or maybe even "ais_skeleton" to indicate that this is a specific subpart of the larger cell. Users set this by providing a dict when creating a skeleton and it is set automatically when running skeletonize_mesh.

Considerations: This suggests to me that pcg_skel results actually subclass Skeleton/Meshwork rather than make them directly, because there is significant extra metadata there for how to interpret the pcg_skel results via the different mechanisms to get meshes and vertex points, for example the coordinate system there can be in chunk units or nanometers.

[codecov-commenter]

Codecov Report

Merging #71 (a82c852) into master (57eae31) will increase coverage by 0.09%. The diff coverage is 60.15%.

@@            Coverage Diff             @@
##           master      #71      +/-   ##
==========================================
+ Coverage   56.04%   56.13%   +0.09%     
==========================================
  Files          23       24       +1     
  Lines        4102     4202     +100     
==========================================
+ Hits         2299     2359      +60     
- Misses       1803     1843      +40     

Impacted Files	Coverage Δ
meshparty/meshwork/meshwork_io.py	49.38% <45.31%> (-1.00%)	:arrow_down:
meshparty/skeletonize.py	45.10% <48.71%> (-0.26%)	:arrow_down:
meshparty/meshwork/meshwork.py	55.47% <50.00%> (-0.02%)	:arrow_down:
meshparty/skeleton.py	84.89% <66.10%> (-3.07%)	:arrow_down:
meshparty/utils_io.py	72.72% <72.72%> (ø)
meshparty/skeleton_io.py	86.04% <93.02%> (+2.51%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 57eae31...a82c852. Read the comment docs.

[ceesem]

Note that the meta-metadata skeleton commits allow for a place to put information relevant to skeletonization but that does not go into the skeleton parameters, for example if it's a pcg_skel-based skeleton and key parameters for that (chunk or Euclidean space? Refined or not?) This is much better than having some sort of subclassing to add those.