time lapse as observationType

[peterdesmet]

Originally reported by @PatrickAJansen at inbo/camtraptor#96 (comment) and split into 3 issues.

It would be logical and practical for users to adopt three additional values of observationType in observations.csv (1 of 3):

(1) "timelapse", for sequences that can be classified as time-lapse photos.
Currently, timelapse sequences are recorded as observationType="unclassified". They can only be recognized as time lapse only by checking media.csv for captureMethod="time lapse", which is highly unpractical and not logical.

[peterdesmet]

It is theoretically possible to classify animals in time lapse obtained media. Can someone comment if this is done in practice? If so, then "time lapse" (captureMethod) is not mutually exclusive with "animal" (observationType). Moreover, "time lapse" and "motion detection" are truly properties of the media file, not an assessment by the classifier (which is what the values in observationType are).

Note that the new model of Camtrap DP (#203) will force you to join observations over media to deployments, so you'll always be able to filter on media.captureMethod="motion detection"

[jimcasaer]

the answer is yes - for some research project the observation protocol is the use of time lapses only or combined with morion triggers. This is done to reduce the effect of detection probability depending on species. e g. every 15 or 30 minutes a picture is taken - these images will subsequently be annotated I'm not sure the time lapse images are currently already presented for annotation in agouti but surely is one of the objectives

[peterdesmet]

@jimcasaer thanks, then that is definitely an argument to not lump this property with observationType values. Closing this issue.

[PatrickAJansen]

This solution is not practical for users.
Example: I have a fully processed dataset. Yet, the output file suggests that the dataset has not been completely processed: 80% of the sequences have observationType = "unclassified". These are all time-lapse photos. It is cumbersome and unnecessary that users must first link observations to sequences and then filter captureMethod = motion triggered.

observationType n
1 animal 3096
2 human 194
3 blank 1740
4 unknown 126
5 unclassified 21479

captureMethod observationType n
1 motion detection animal 3095
2 motion detection human 194
3 motion detection blank 1740
4 motion detection unknown 126
5 motion detection unclassified 57
6 time lapse unclassified 21422
7 NA animal 1

[jimcasaer]

@PatrickAJansen : I do not see the problem given that at the moment camtraptor deals with this kind of selections and filters when analysing exports from agouti -- the problem of filtering and selecting will however occur when time-lapse images will also be annotated

[PatrickAJansen]

This is still an issue.
People trying to interpret the observations.csv directly reach the conclusion that a dataset is not completely annotated, even when it is. Camptrapdp should be logical / interpretable / useable without camptraptor. Timelapse observations should be recognizable as such.

[peterdesmet]

The problem is that timelapse is not a property of an observation, it is a property of the media. I see two solutions (both can be implemented):

1. The Agouti export doesn’t include (unclassified) observations linked to timelapse media.
2. The R package allows to filter on timelapse: Provide option to filter out observations related to timelapse inbo/camtraptor#306

[PatrickAJansen]

It is good to have timelapse images in the export because they contain information on cameratrap functioning (which is typically the sole reason for collecting timelapse photos in the first place).
The problem is that the camtrapdp tags records associated with timelapse photos as unclassified while they are classified -: as timelapse. For users, there is no way to tell this from the observations.csv alone, and that is plain a simply user unfriendly.

See also #375 and #12

[kbubnicki]

@PatrickAJansen What if your time-lapse image captured an animal (or human)? Time-lapse images are often used exactly the same way as motion-triggered images (e.g. in TTE, STE density models) and people need to annotate them. For this reason time-lapse is not a valid category for observationType (all categories describe a content of an image and not how it was captured).

I think what we could consider is to add a helper column in observations.csv table e.g. captureMethod but this information is already available in media.csv so I am not super convinced that this is needed.

[PatrickAJansen]

I understand that some studies use time-lapse photography for capturing and counting animals. Geese on meadows, for example.
Yes, a helper column in observation.csv would solve the problem users face. I understand that it is redundant from a database point of view, but it is absolutely needed from the point of view of user friendliness.
Getting the camptrapdp widely adopted requires user friendliness.