Rolling shutter correction - rules of thumb

In my WebODM tests so far, there haven’t been an obvious difference in output when I’ve used the rolling shutter correction - or not.

My cameras all have rolling shutters - so it’s easy enough to just always take this option.

But I’m wondering if there are any rules of thumb about when this correction makes a noticeable difference in the output products.

1 Like

Have you verified using the log that your camera models have calibrated Rolling Shutter Correction values or are they just using the default 30ms estimate?

In general, you’ll see bigger impacts when flight speed is higher, your survey areas are larger, and/or shutter speed is a bit slower.

Wow - that’s really helpful.

Indeed - my camera didn’t seem to appear in the WebODM camera database. Hence in my log:

[WARNING] Rolling shutter readout time for “SONY ILCE-5100” is not in our database, using default of 30ms which might be incorrect. Use --rolling-shutter-readout to set an actual value (see GitHub - OpenDroneMap/RSCalibration: Docs and scripts to estimate a camera's rolling shutter readout time for instructions on how to calculate this value)

Is there a database of cameras that WebODM knows about for these values? Maybe I can find the data for a similar Sony camera.

I did an extensive web search to try to find the sensor readout time for the Sony a5100, and couldn’t find anything.

I then tried ChatCBT, and it reported that the sensor readout time for the Sony a5100 is 2.5ms.

That’s way off from the default 30ms estimate.

Unfortunately, ChatCBT wouldn’t give me a reference for that 2.5ms value.

The Sony a5100 is such a common camera - I would think that many folks here in this community know the readout time value for this camera.

Of course I can build the devices in the book and on github that describe how to measure this. But I’m not sure I’ve got the patience to do so. So I’ll ask around to see if anyone knows about this.

Many Thanks!

1 Like

We are building out our own database of sensor readout times, using contributions from this methodology:

I created and used the No-Tinker method for my data, and it really is super simple to get working.

As for Chat* and other LLMs, they know and understand nothing, and all it is doing is making a stringing together of statistically likely words based upon the text it was trained on, so you are right not to trust the value given.

1 Like

I’m going to build one this week,

I’m not up on Arduino projects - but but I have a friend who I’m going to ask to help me out and shorten my learning curve.

I have 3 cameras I want to calibrate.

2 Likes

This would be so, so, so helpful!

You can open a new thread if you run into issues and I’ll try my best to keep present.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.