Editing metadata in trail camera images using R, magick and exiftool

I have a new hobby: camera traps, also known as trail cameras. Strapped to trees in my local bushland they sit in wait, firing automatically when triggered by a passing animal. Once in a while, something quite magical happens.

The camera model I chose is the Campark T85 which for me, had the right combination of features and price point. One useful feature is the ability to transfer images and video to a phone wirelessly (albeit through a rather clunky phone app). Unfortunately, images retrieved in this way have one major flaw: an almost-complete absence of metadata. There is no GPS in the camera of course, but the EXIF data does not include the date/time of the image, nor the camera make.

With a little research, I found a way to add this information to the images later using R and some additional software named exiftool. Here’s how I did it.

Experiments and structured data

I’m going to be lazy and point you to some interesting discussion over at Cameron’s blog on the use of structured data to describe experiments: part 1; part 2; part 3.

My experience of discussing electronic lab notebooks, which is mostly from biochemistry/molecular biology labs, is that many biologists are quite resistant to the idea of structured data. I think one reason that the paper notebook persists is that people like free-form notes. You may believe that a lab notebook is a highly-ordered record of experiments but trust me, it’s not uncommon to see notes such as “Bollocks! Failed again! I’m so sick of this purification…” scrawled in the margins.

My take on the problem is that biologists spend a lot of time generating, analysing and presenting data, but they don’t spend much time thinking about the nature of their data. When people bring me data for analysis I ask questions such as: what kind of data is this? ASCII text? Binary images? Is it delimited? Can we use primary keys? Not surprisingly this is usually met with blank stares, followed by “well…I ran a gel…”.

I do believe that any experiment can be described in a structured fashion, if researchers can be convinced to think generically about their work, rather than about the specifics of their own experiments. All experiments share common features such as: (1) a date/time when they were performed; (2) an aim (“generate PCR product”, “run crystal screen for protein X”); (3) the use of protocols and instruments; (4) a result (correct size band on a gel, crystals in well plate A2). The only free-form part is the interpretation. Is the result good, bad, expected? What to do next? My simplistic view is that an XML element named “notes” of data type “string” covers anything free-form that somebody might want to say about their experiment. Now we just have to design the schema, build a nice forms-based web interface and force everyone in the lab to use it :)

One more point: we need to teach students that every activity leading to a result is an experiment. From my time as a Ph.D. student in the wet lab, I remember feeling as though my day-to-day activities: PCR reactions, purifications, cloning weren’t really experiments – they were just means to an end. Experiments were clever, one-shot procedures performed by brilliant postdocs to answer big questions. When I started to view each step: obtaining the right size PCR product, sequencing it, ligation, transformation, plasmid purification etc. as an experiment in its own right, with a defined goal, I felt a lot better about myself. Break your activities into steps and ways to describe them as structured data should suggest themselves.