Rolling Shutter readout time reported on Quality Report

I’ve been testing a DJI Mavic 2 Pro - old, but in good shape.

For some reason, Pix4D reports really high rolling shutter readout times for this drone - around 220ms.

The correct value should be in the neighborhood of 55ms to 75ms.

It is possible that there’s a problem with this camera.

But perhaps it’s also possible that is something wrong with Pix4D’s assessment. (I’ve attached an example quality report)

Have there been issues regarding this sort of thing?

Thank you for any comments or suggestions!

Alexander Park_report.pdf (261.4 KB)

Hi Joe,
The readout time that is given in the quality report is computed during the rolling shutter correction process. For each image, the distance traveled by the drone during the readout is computed, and the readout time is deduced by using the drone speed. As such, it is a bit of a roundabout way to compute the readout time, and is prone to computation errors.

Thank you Mike -

Your explanation matches what I recall learning before.

The problem is that the Pix4D jobs I’ve run with my Mavic 2 Pro come up with some very peculiar rolling shutter times - 219ms.

I decided to check it experimentally using the rolling shutter detection apparatus outlined here:

GitHub - OpenDroneMap/RSCalibration: Docs and scripts to estimate a camera’s rolling shutter readout time

The result was this image:

The 56 bands show that the sensor read-out time is 56ms.

Coincidently, this is the readout time in the WebODM database for this drone’s camera.

As additional info - I have an associate who also has a Mavic 2 Pro - and Pix4D Mapper generates rolling shutter read-out times for his drone’s camera from 77ms to 140ms.

Pix4D appears to process the jobs well - so maybe there’s just a bug in the Quality Report data.