# Structure, concepts, and terminology ## 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 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 within the image. Each *Object* will have a “bounding box”, or rectangle defining its extent and location within the *Image*. *Labels* describe an *Object* (e.g., “animal”, “rodent”, "sasquatch"). *Objects* can have multiple *Labels*, and *Labels* can be created from either machine learning model predictions or users. The reason *Objects* can have multiple *Labels* is because multiple machine learning models might have different predictions for the same *Object,* and human reviewers might want to override/add their own *Labels* to *Objects* as well. Users can “validate” or “invalidate” *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.

"Unlocked" Objects are represented by dotted lines encircling the available Labels/ML predictions (list on the left) and dotted lines for bounding boxes (image on the right)

"Locked" Objects have solid lines

## Tags *Tags* offer another way to annotate images. *Tags* differ from *Objects* and *Labels* in two ways: (1) they can only be applied by humans, not by ML models, and (2) they are used to describe something about the entire image, rather than something within the image. For example, if you wanted to annotate your images as having been "viewed" or "double-checked", you could create *Tags* to represent those states, and apply them to your images to indicate to other users that they have been seen. Some other examples of use-cases for "image-level" *Tags* include: * describing images' reviewed state, e.g.: "**viewed**", "**retired**", "**double-checked**" * marking certain images as "**interesting**" or "**favorite**" * describing the presence or absence of a certain animal, e.g. "**rat**" and "**no-rat**" * describing an animal behavior or animal interaction, e.g. "**predation event"** or "**first Hawaiian petrel sighting of season**"

Tags appear below the Image and describe something about the entire Image, rather than something within it

Project Managers are responsible for creating and maintaining the list of allowable *Labels* and *Tags* that can be applied to images in their Project. For instructions on how to manage Labels and Tags, see the [Image Review](https://docs.animl.camera/fundamentals/image-review#managing-labels-and-tags) section of the documentation.