In this update we simultaneously roll out two sets of features: the first half of our new individual identification tools, and a new simplified way of identifying your sites/stations and cameras in your folder structure.
Folder-Level Selection
Of most general interest will be our new more-intuitive way of identifying your sites/stations and cameras. As a recap, we have always tried to simplify this process by leveraging the information inherently in one’s folder structure – where inevitably SD-card data is stored in separate folders for each camera, and those are in turn sorted into site/station-level folders (in the case where one has multiple cameras per site/station). Previously, you needed to identify this folder information by name – by specifying your site/station/camera naming schema either through a simple prefix-number combination, or a regular expression. This approach was extremely powerful as it could work independently of your folder structure – regardless of different folder depths etc. However, it did present a little bit of a learning curve, and a challenge for those with a non-standardised naming schema.
Don’t worry – due to their robustness and flexibility these site and camera identifiers aren’t going anywhere. However, to make the import process more intuitive we have added a new way to specify your sites and cameras – the ability to simply select the level within your folder structure in which this information is situated. To keep things simple, this is achieved by displaying an example folder path from the data you have selected, and all you need to do is to click on the folder that represents your site or camera.
This is depicted in Figure 1 below for a dataset collected at a protected area called Kwaluzi in 2017. This survey was carried out using a dual-camera setup with a camera on either side of a game trail for the purposes of capturing both flanks of a passing individual for identification. Each of the sites/stations where these camera pairs are situated are named K1, K2, K3 etc. (K for Kwaluzi in this case), whilst each individual cameras are designated either A or B. Therefore, each SD card folder (“K23_C45_1A(2)”) was added to either an A or a B camera folder which then in turn was added to a site/station folder. These were then all collected under a single Kwaluzi2017 folder that was selected for upload. Therefore, in the displayed example one only needs to click the “K23” folder for the site/station and then the “A” folder for the camera. These folder-level selections will then be applied across the entire dataset. As such, with this approach one does not need to be consistent in one’s naming schema, but you will have to be consistent with your folder structure – where sub-folder inconsistency below the lowest site/camera folder will not have an impact.
Figure 1: The new folder-level selection approach to identifying sites/stations and cameras.
To compliment this new feature, we took the opportunity to better clarify the form and simplify the options available to you. Firstly, you will note the usage of “site/station” instead of simply “site” as previously. This was to try and reduce confusion around the ambiguity of the word “site” that could either mean a singular point in space (as we mean it), or an area or region. Originally, this confusion was not prevalent, but it became so with the addition of camera definitions. Additionally, we added a dedicated single or multiple cameras per site option, where the default is a single camera as that is the most common. We also added a warning for when a site/station has more than two cameras as this is extremely rare, and should help prevent users from importing all their data as a single site/station with 90 cameras.
Improved Individual ID Tools – Part 1
When we first built the individual ID workflow, we built it around the most-common use case we had encountered – where an organisation will go into a new protected area and perform a discrete survey of the population of a particular species using spatially-explicit capture recapture. In particular, for more prevalent species like spotted hyena, there would be thousands of images of hundreds of different individuals. Moreover, these images would be processed by students that would not know any of the individuals. As such, the process of individual ID was simply a giant pattern-matching exercise subject to combinatorial growth where the name of the game was to simply reduce the number of image pairs that would need to be reviewed. Significantly, in the case where a mistake was found, it would be almost impossible for a user to figure out which individual out of hundreds an image belonged to. Therefore, error correction was simply handled by dissolving the individuals or dissociating incorrectly-associated images/sightings, and reverting back to the pattern-matching workflow.
For this fore-mentioned use case, this workflow works extremely well. However, for the use case where a single protected area is undergoing long-term monitoring by a dedicated set of annotators, it can be frustrating when one comes across an individual one knows by sight and not be able to do anything about it – instead being forced to follow the strict pattern-matching exercise. Therefore, in both this update and the second half that is coming, we hope to address this use second case with a number of useful tools whilst avoiding negatively impacting on the original.
The primary feature added in this half of the update is the ability to better edit the individuals in your library, in the form of the ability to merge individuals, or push an incorrect image/sighting from one individual to another known individual – bypassing the pattern-matching workflow. Both are achieved by displaying the possible matches in an ordered, filterable list as in Figure 2 below – with a number of different ordering available such as similarity, distance, or name. Once a potential match has been selected, one is shown – as in Figure 3 – all the relevant information about that individual its tags, first and last seen timestamps, and the map of where it has been seen – and how that overlays against the current individual or incorrect image/sighting, thus allowing you to make certain of the selection you have made.
Figure 2: The new ability to merge individuals in the individuals library – showing how one can search through an ordered, filterable list of possible matches. This same filterable list also appears when one wants to push an image/sighting from one individual to another, as well as within the individual ID workflow.
Additionally, the exact same menus and tools have been added to the first stage of the individual ID workflow. So instead of being forced to create a new individual for each animal sighted in a cluster and waiting until it is suggested as a potential match during the second stage, you can optionally push that animal and all its images/sightings immediately to a known individual. However, should you not recognise the animal, you still have the option to leave it for the pattern-matching exercise.
Figure 3: The new ability to merge individuals in the individuals library – showing the information provided about a selected potential match, and how that relates to the individual you are wanting to merge. This same information page also appears when one wants to move an image/sighting from one individual to another, as well as within the first stage of the individual ID workflow.