EMAnnotationSchemas
Repository to hold schemas for annotations of volumetric imaging data focused on EM
How to add a new annotation type
In order to add a new annotation type to this repository you must do the following steps.
- Create a new schema for your annotation. This schema needs to follow a few guidelines.
- This schema should extend the class emannotationschemas.schemas.base.AnnotationSchema.
- The central tenant of annotations, is that you should mark spatial locations that should be linked to agglomerated objects in the segmented EM volume with a emannotationschemas.schemas.base.BoundSpatialPoint nested schema. This will announce to the AnnotationEngine and the MaterializationEngine that the associated root_ids (neurons/glia/axon fragment/etc) should be "bound" to these locations and easily referenced (along with the nearest skeleton node and mesh node). You may also include points which do not need to be linked to root_ids, as emannotationschemas.schemas.base.SpatialPoint (of which BoundSpatialPoint is a subclass). All Nested SpatialPoint fields can include an 'order' keyword, which will be used by UI elements to determine whether, and in what order to draw lines between these points to represent an annotation.
- If your annotation needs to reference another annotation. For example, if you want to be able to annotate that a certain synapse is of a certain type, or that a spine head is dually innervated, then you should subclass a emannotationschemas.schemas.base.ReferenceAnnotation, so the system knows to link that annotation to its reference annotation.
- You should add a mm.post_load validation methods to the schema that ensure everything is what you would expect. For example that the type field is what you want it to be, and that any reference_annotation_type are what they should be. It should set the 'valid' flag of the annotation when the necessary information to validation the annotation is present, and remove that key from the dictionary when the information is not yet present. For example, upon posting new annotations to the annotationengine, root_id's are not available, and so synapses cannot be 'valid' based upon their having different pre/post IDs, but later, when materialized, they should have those IDs.
-
Import this schema into init.py, and add the schema to the type_mapping dictionary, giving it a string based key. This will be the annotation_type of your new class of annotation.
-
You should add a test to the testing suite that uses this schema, and checks that you can correctly detect potential problems with annotation data that is sent into the system.
An example of a proper schema is emannotationschemas.schemas.synapse.SynapseSchema.
4 maintainers
Metadata
4 maintainers
Release files for emannotationschemas 5.26.3
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| emannotationschemas-5.26.3.tar.gz | 40.2 kB | Details |
Release files / emannotationschemas-5.26.3.tar.gz
| Download URL | emannotationschemas-5.26.3.tar.gz |
|---|---|
| Size | 40.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
d6ecf81a904f07634794ba21c333e6f2ebef751217a05b521d5502b8f7b87e18
|
|
BLAKE2b-256 checksum How to use checksums |
c52101bcdbdc894ea74121394186f89d81a6663e93ec66943532df897d7ad68e
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Apr 28, 2026.
Transparency log
