Articles | Volume 23, issue 1
https://doi.org/10.5194/nhess-23-329-2023
© Author(s) 2023. This work is distributed under the Creative Commons Attribution 4.0 License.
Evaluation of low-cost Raspberry Pi sensors for structure-from-motion reconstructions of glacier calving fronts
Download
- Final revised paper (published on 27 Jan 2023)
- Supplement to the final revised paper
- Preprint (discussion started on 09 Aug 2022)
Interactive discussion
Status: closed
Comment types: AC – author | RC – referee | CC – community | EC – editor | CEC – chief editor
| : Report abuse
-
RC1: 'Comment on nhess-2022-201', Karen Anderson, 08 Sep 2022
- AC1: 'Reply on RC1', Liam Taylor, 03 Jan 2023
-
RC2: 'Review of Taylor et al. Evaluation of low-cost Raspberry Pi sensors for photogrammetry of glacier calving fronts', Penelope How, 23 Nov 2022
- AC2: 'Reply on RC2', Liam Taylor, 03 Jan 2023
Peer review completion
AR – Author's response | RR – Referee report | ED – Editor decision | EF – Editorial file upload
ED: Publish subject to minor revisions (review by editor) (08 Jan 2023) by Pascal Haegeli
AR by Liam Taylor on behalf of the Authors (09 Jan 2023)
Author's response
Author's tracked changes
Manuscript
ED: Publish as is (17 Jan 2023) by Pascal Haegeli
AR by Liam Taylor on behalf of the Authors (17 Jan 2023)
NHESS2022-201 Taylor et al
This is a nice piece of methodological work, which delivers insights on a new approach for low-cost unattended monitoring of calving glaciers via low-cost raspberry pi operated cameras. It's a neat idea and the proof-of-concept is done well. The piece was relatively uncomplicated to review, because it is quite clear in its layout. The major findings are that the raspberry pi-operated cameras can deliver quite good quality photogrammetric reconstructions of glacier fronts, and compared to equivalent data captured from a drone flying along the glacier front – the results are not hugely different, which evidences the capability of the cameras for this task. What is quite impressive is that the very low cost raspberry pi system delivers precision thresholds set for DSLR workflows. Monte carlo point-cloud to point-cloud methods are employed to perform a robust comparison between the raspberry pi and drone datasets. Overall the paper is uncontroversial but provides a useful reference point for those wanting to develop raspberry pi imaging for photogrammetry, or timelapse monitoring for glacial applications as well as in other fields.
The main thing which I think needs a little finessing is that the piece has a title which is about photogrammetry but the paper is also focused on timelapse. And you can have timelapse functionality without photogrammetry on the pi – e.g. one camera instead of an array of cameras. So I felt that a bit more careful structuring of the argument could benefit the clarity of the paper and make that distinction a bit more visible. There are some minor points to address, largely relating to some areas needing a little more detail.
Minor points
Line 65 – ‘we have designed…’ – this sounds like a methodology point not something that belongs in introduction. I think the introduction should focus on reviewing the camera technology / hardware here rather than linking to your specific experiment or motivations. Maybe just lose the first sentence of this paragraph and start with ‘raspberry pi computers are small…’
A general point is that timelapse capability can also be achieved very cheaply (less than £120) from wildlife cameras (e.g. the type that are typically used for motion-sense camera trapping). You do pick up on this a little in the discussion but not at the beginning of the piece (e.g. table 1). Not all trailcams have a timelapse capability, but some do, and many also have in-built solar trickle charge capacity. I’ve also seen papers using them as phenocams. It would have been interesting to see how data from these compared to the pis, but I appreciate that it’s too late to ask for that. On that note I also wondered why you didn't do a like-for-like comparison to SLR method from the same vantage points with the pi? The drone may be the most widely used method for glacial front reconstruction but it is not for timelapse, I think… Perhaps there needs to be an explanation added about this distinction. I think the experiment described around line 140 is addressing this but the explanation is a bit opaque (e.g. “the monitoring network would be cheaper as fewer cameras are required”…)
If this is about time-series monitoring of glacier frontal dynamics – is the spatial reconstruction from the boat-mounted surveys a useful demonstration of the temporal case study? I am referring to the statement at the beginning of the paper where you state that “Arrays of fixed cameras can be positioned around a glacier front to capture images repeatedly over long time periods. The resulting imagery can then be used to photogrammetrically generate 3D models at a high temporal resolution and analyse change over days, months, or years.” So I guess that one way would be to position multiple pis facing the calving front and trigger them simultaneously, to generate SfM products. I felt that the paper warranted a discussion about this high cadence mode of operation which seems to be largely what you’re advocating – vs the boat mounted transect operation that you actually carried out.
Figure 4 – it shows the two comparative point clouds from the pi and the drone and I note that the colouration of the renderings is different. Is this due to some different camera settings used (e.g. exposure etc?) or something else? It made me think that the methods section needs some added information about these aspexts given that other papers have commented on the impact of camera settings on the quality of SfM outputs. I guess it may not be possible to change the settings on the pi camera but this is not the case on the drone camera, so does warrant some discussion.
Line 125 – I read your argument for flying the drone closer to the glacier than the boat but I think if you want to compare pi to drone it would have made more sense to use a distance for each which did a better job of balancing the camera resolution capabilities with the distance. It seems like being further from the glacier with a poorer quality camera will give you a negatively biased estimate of the quality of the pi camera. Perhaps warrants some discussion.
Table 1 – I think the cost given here is inaccurate – you did not use a Pi ZeroW so this price is not describing the system used. You could perhaps put a range of price here to indicate the low-entry point zero-W and the version you used.
The thing that is lacking from the paper is an open source sharing of the build recipe (e.g. list of components) and code for setting up the pi to run as timelapse camera. I think this should be added as supplementary information if the paper is accepted.
Line 120 – what is the minimum capability for timelapse in the pi camera? And why approx. 10 second intervals – is it uncertain how often it triggers (e.g. why ‘approx’).
Line 150 – this pre-alignment with the UAV data sounds great in this context, but what would happen if someone used the pi without the drone survey…? Presumably the registration would then be arbitrary. I realise that you did this for the purposes of cloud-to-cloud comparison in M3C2 but thinking more broadly does the lack of georeference information matter in the timelapse? Perhaps add some clarification to the manuscript in this regard.
Figure 6 needs a colour bar scale legend
Can you comment a little more on the patterns of errors in Figures 4 and 6. You wrote that the jagged edges of ice result in higher errors but the nature of the patterns in the M3C2 results shows that there are patches of high positive errors neighbouring patches of large negative errors (e.g. blocks of blue and red next to one another). What is the cause of this systematic patterning of error – why are the differences in the point clouds organised like this?
Thanks for the opportunity to review the paper.