Effects of snapshot moment choice

[Maik Henrich]

Dear everyone,

I am currently working on an R script to obtain confidence intervals for Distance Sampling with camera traps. One of the most tricky parts at the moment is the choice of snapshot moments. It would be advisable to keep the interval between snaphots  short to make use of as much available data as possible. Sadly the  re-triggering speed of the camera traps is not 1s as adverised by the manufacturer. I tested 10 cameras by continously moving in front of them and the median delay between photos was 6 s . 

One option would be, when assessing the confidence interval of the density estimates via bootstrapping, to use fequencies for the  lags between snaphot moments of the iterations that correspond to the distribution of camera trap trigger delays. While it would be easier to just use 6s, I think this might fail to capture quite a bit of uncertainty in the estimate.

The second issue is the start time for the snaphot moments. If I start counting photos every 6th second from 00:00:00 on, I might get a lot more or less photos than if I started  from 00:00:001 or 00:00:02 (etc.) on. If I try to include all these possibilities it gets quickly very confusing.

What do you think about 

a) the choice of lag between snapshot moments

b) the  variation induced by the shifting of the starting point of snapshot moments?

Thanks a lot!

Best,

Maik

[Stephen Buckland]

Maik, if you have the option of taking images at fixed times, then the choice of gap between snapshot moments doesn’t affect bias, but will start to affect precision once the time between snapshot moments becomes long enough for some animals passing in front the camera to be missed altogether.  If you’re not able to do that, but must rely on the camera triggering, then you will start to get bias when the snapshots are far enough apart for some animals to be missed.  In that case, you’re right to raise this variation in re-triggering delay as a problem.  I think you should use the mean time for working out how many snapshot moments there were in total while the camera was operating.  There may be some bias if the delay is sometimes long enough for an animal to pass undetected, but I would not expect the bias to be large, except possibly if average speed of animals is high.  The variation in the delay should not really affect variance of density estimates, so it is really the possibility of bias that you might want to give some thought to.

 

Sorry, I’m not sure what you’re asking in your second point.  When snapshots are determined by the camera triggering, you don’t get to choose a start time – you just get the number of snapshots that the camera actually took.  Then you have to use the mean time between snapshots to estimate the total number of snapshot moments, including all those when no animal was present to trigger the camera.  Ideally, you would have a fixed time between snapshots, but if the cameras don’t give you that option, then you don’t have the option of choosing a fixed time gap, as you won’t have the photos at your chosen snapshot moments.  Of course, if your cameras give the option of video, you can then choose your snapshot moments with a fixed time separation.

 

Not sure how helpful this is – perhaps someone with practical experience of doing camera-trap surveys can comment.

 

Steve Buckland

--
You received this message because you are subscribed to the Google Groups "distance-sampling" group.
To unsubscribe from this group and stop receiving emails from it, send an email to distance-sampl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/distance-sampling/21f20812-6ad1-432c-9b3f-57e1bc2e4f6en%40googlegroups.com.

[Eric Howe]

Good day Maik,

Did you test the cameras while moving continuously in front of them at a very short distance? I.e. within 1 or 1.5 meters? If the camera doesn't trigger because the moving object is farther from the sensor, we capture that in our observed distances. If the camera usually triggers after 1 second when objects are moving very close to the camera, the "unavoidable" delay really is 1 second and you may not have a problem with t = 1 (or 2 or 3) seconds. Otherwise, I agree it makes more sense to set t = 6 seconds based on your histogram.

Regarding the starting point:

If you are defining the starting point as a time of day, regardless of when the camera is triggered (as recommended when recording video), then I think you should be able to shift from e.g. every 0, 6, 12 seconds after the even minute, to e.g. 1, 7, 13 seconds after the even minute without causing bias. With cameras programmed to record single images, and a 6-second delay, this might leave you with little data (most observations won't coincide with predetermined snapshot moments).

If you are redefining the starting point as the triggering time whenever an animal is detected (sometimes necessary when cameras are programmed to record single images) then your histogram suggests that you would maximize your data collected by using 0, 6, 12, seconds after the triggering event (where 0 corresponds with the first image obtained, 6 with the next opportunity in time to detect that animal). You'd still use t = 6 seconds to calculate T_k.

All the best,

Eric

[Eric Howe]

Good day again,

To be clear, you'd also include that first observation at t = 0 seconds after the camera was triggered in your data. That ensures you get to keep at least one observation from each triggering event. Hopefully animals move slowly enough that you'll detect some of the same animals more than once as they pass through the zone of potential detection.

Eric

[Maik Henrich]

Dear Steve Buckland, dear Eric,

Thanks a lot!

When testing the camera, I did indeed move my hand in a very short distance in front of the camera (less than 1 m away).

What I did until now was to use the dataset with photos triggered by the animals and then define a pre-set interval of snapshot moments starting at 00:00:00 at the first day of deployment retrospectively. For the species with which I am trying this (red deer), it worked quite well and I still ended up with a reasonable amount of observations.

However it is good to know that the trigger times could also serve as a starting point for the snapshot moment interval.

It is really great to get such quick answers from experts in the field!

All the best,

Maik

[Maik Henrich]

Dear everyone,

as I found out today the choice of the snapshot interval does make very little difference. It is however very important to divide the total deployment time by the delay of camera trap triggering, because otherwise the potential number of photos is overestimated and the population density is drastically underestimated.

Hopefully this can be helpful for some of you fighting with the same problem.

Best,

Maik

[Maik Henrich]

Dear everyone,

just to add a clarification:

I think the easiest possibility  if you have a camera trap dataset with delayed trigger times is to use the orginal dataset of photos without subsampling and when set t to the observed delay between photos (without changing the deployment time Tk).

What confused me was, that I also subsampled my photos so I had only one photo  left in the dataset every six seconds at each camera trap location. This meant of course that nothing changed compared to the original situation since the number of photos was also six times less. What was before  e.g. 600/60000 became 6*100/60000, so nothing changed. In hindsight, it is clear that I can't do this because, I already have the delay of six seconds in the orginal dataset of photos. That means if I subsample the photos on top, I may get sometimes get a delay of even 12 s instead.

Thanks again  for your support!

All the best,

Maik