Structure, concepts, and terminology
Understanding how projects, users, and data are organized
Projects
At the highest level, Projects are a way to organize cameras/deployments used for different purposes and that have different user bases. Each Project owns its own set of Users, Cameras, Deployments, and Images, which are all only accessible to users who have been granted the appropriate permissions for a given Project. NOTE: Users can belong to more than one Project and have varying levels of project roles across different projects.
Please reach out to Nathanial Rindlaub at nathaniel.rindlaub@tnc.org if you need to create a new Project.
User management & project role levels
Only Project Managers (level 3, see below) can add/remove users and manage project roles. See the "User management" section for more details.
There are three project role tiers available:
Level 1 - Project Observer - Project Observers have read-only roles. This may be useful in certain situations, e.g., to allow ecologists or researchers outside of your organization who want to view reviewed, validated data for research purposes but don’t necessarily need to edit the data.
Level 2 - Project Member - Project Members can help review and edit image Labels and can create Views to help with their review workflow. They cannot edit inference pipelines, edit deployments, or register/release Cameras.
Level 3 - Project Manager - Project managers can register and release Cameras to their Projects, configure inference (machine learning) pipelines and Alerts, see all Images that belong to their Projects, and edit Labels. They can also create and edit Views, add and manage project member permissions, and upload images directly from their computers.
Filters
Image query filters allow the user to view a subset of images. Users can filter by deployment/camera, date created, date ended, labels, reviewed/not-reviewed, etc.)
Views
Views are saved combinations of filters that users can freeze and return to for fast access or sharing with other users in their Project. For example, you might have a View called “Images that need reviewing” which could show images that have yet to be reviewed. NOTE: The default View is “All Images” (no filters applied), and cannot be edited or deleted.
Automation rules
Users can configure Automation Rules, which are simply actions to take (e.g., send email, request machine learning prediction) after certain events occur (e.g., an image is added, label is added). Automation Rules are set at the Project level, so an automation rule set for a specific Project will apply to all images that are added to that Project going forward. Automation Rules do not retroactively get applied to images that are already in your Project.
Cameras
Cameras are representations of individual, physical cameras in the real world and are uniquely ID'ed by the cameras' serial number.
Wireless Cameras are a special variant of Cameras and represent cellular and other wireless camera traps who's data streams can be integrated into Animl and processed in real time. Unlike regular Cameras, before you'll be able to ingest any images from your Wireless Camera traps, you must first register them with your Project. If the camera’s serial number is already registered/paired with another Project, you will be unable to register it to your own, so it’s important when transferring a camera between Projects to release it first.
Deployments
Over the course of a camera’s life, it may be deployed multiple times for multiple purposes and across multiple Projects. So in essence a Deployment is just a set of Images taken by a Camera between two dates at a single location.
In Animl, it’s maybe most helpful to think of Deployments simply as a data management tool, and they’re quite flexible: you can create Deployments retroactively and adjust their start dates and other metadata whenever you want. Every camera that is registered or was registered at some time to a Project has an un-editable Default deployment, with no start date, which serves as a fallback for images that may enter Animl but were taken earlier than the start date of the earliest user-defined Deployment.
Images
Images are both the image files themselves as well as their associated metadata.
Objects and Labels
An Object represents any object/thing (animal, person, vehicle, etc.) that was identified in the image. Each Object will have a “bounding box”, or rectangle defining its bounds and location within the Image.
Labels describe an Object (e.g., “animal”, “rodent”). Objects can have multiple Labels, and Labels can be created from either machine learning model predictions or users. Users are responsible for “validating” or “invalidating” Labels produced by machine learning models. If a user validates a Label, that object will become locked, and that validated Label will appear as the “winner” (the most specific & accurate Label associated with that Object). However, users can always unlock objects, invalidate previously validated Labels, or add new ones manually to override Labels that had been applied earlier.
Last updated
