horshack

I have posted X100VI rolling shutter measurements for both photo and video to my GitHub project:

https://horshack-dpreview.github.io/RollingShutter/

You can see more detail about the measurements by clicking on the X100VI link in the Detailed Results section below the consolidated table.

3 hours ago, KnightsFan said:

I fully support your endeavor! I'm not negative on what you're doing. Ideally it is best to standardize, I just worry that the list won't grow very large, because of the purchase requirement. Unless you can get buy in from a big reviewer who gets their hands on a lot of models (or maybe you are a reviewer who gets your hands on lots of models personally)

Thanks, I appreciate that. I have a running thread on Fred Miranda soliciting submissions and so far the response has been good. To encourage participation I've been buying the Arduino boards on Amazon and having them shipped directly to members who have cameras I would like tested. Going forward my hope with the crowdsourcing is that the group interested in these kinds of measurements would be enthusiastic about having their own reliable method for measuring readout speeds whenever they need, so that the small investment in the Arduino board wouldn't be an impediment. Time will tell if that turns out to be true.

2 hours ago, KnightsFan said:

Sounds like either you or the other person measured it wrong (or possibly both of you did).

Agreed. The difference is the methodology I'm using has been fully disclosed, along with all materials needed to generate it, the most important of which is the light source, the frequency of which has been independently verified with an oscilloscope. That means anyone can verify the math behind the measurement and reproduce it themselves using a $17 Arduino board.

Again, that was the impetus behind the project. To finally standardize a measurement around a transparent, opensource-veified methodology.

8 hours ago, KnightsFan said:

Here's my list

https://outerspaceoatmeal.com/tools/RollingShutterComparison.html

You can add or not , up to you. Most of my numbers come from DVXuser, CineD, and a couple from other primary sources where the test method has been shared. Global shutter cameras are self explanatory so I link to the product page.

Yeah I mean it's ideal to always do it the same way, I'm just not sure many people will buy a specific arduino to fill out this table.

Difference with DR is that it's extremely subjective. Rolling shutter is not. People can measure it incorrectly-- which they can do whatever their intended test method is -- but they can't measure it correctly and then arrive at a different conclusion than someone else.

Edit: And to be clear, measuring signal to noise ratio is also objective.

Thanks. The results represented in that table is part of the reason I started my project - some of the measurements are off by significant amounts. For example, the A7 III 1080 is listed at 8.7ms - my measurement is 7.10ms - that's a 22% error in the 8.7ms measurement. There is simply too much slack in the varied methodologies being used to be considered objective measures.

53 minutes ago, KnightsFan said:

In that case none of my values will go into your table. Seems like a waste, though--it's a raw speed so there's no subjectivity.

I agree, the sensor speed is what it is. However there is a moderate amount of variability in the readout speeds posted online, owing to differences in methodology. I'm looking to avoid that variability in this repository of measurements.

4 hours ago, KnightsFan said:

Nice! I have my own database of rolling shutter values that I can get to you. The one column I would add to the table is the ratio of the rolling shutter to the frame rate. That value normalizes the skew per frame.

Thanks! To keep the results in the table fully comparable I would like for all of the cameras to be measured using an identical methodology.

FYI, I've started a GitHub project to create a repository for sensor readout speeds of all cameras, for both stills and video, using a standardized measurement method that involves a $17 USD Arduino board.

The project's homepage is:

https://github.com/horshack-dpreview/RollingShutter

The project has a link to the current database, a primer about rolling shutter artifacts, source code, and collection details for those who would like to contribute their camera's images to be measured and added to the database.

Direct link to current results:

https://horshack-dpreview.github.io/RollingShutter/

Follow-up. After my earlier post I've determined the issue appears specific to the AAC audio codec, which is the codec utilized for all the lower bit-rate MP4 mode files. If I switch to LPCM the issue doesn't occur - LPCM is utilized for all of the higher bit-rate MOV mode files. Here's a new video comparing the two audio codecs:

21 minutes ago, kye said:

I see a delay in the audio from my GX85, and where it matters I just re-align them manually.

If it matters to you, just include an event at the beginning of each clip that allows you to align it in post.  This is why the clapperboard is used in making movies - it allows the picture and sound to be aligned.

If it matters then you should also ensure that the timing is stable over time, so there are no drifts over long takes.

Yep, I've started using the Arduino just for that purpose, to have a precise video/audio sync lead-in.

I have a project where I need to precisely match the timing of video to audio. In the course of setting that up I noticed what appeared to be a fixed audio lag/skew in my S5 video. It's worst as 60p and occurs in both 1080 and 4K. I created a video to demonstrate what I'm seeing:

Setup
Arduino UNO R3 board running code I wrote that turns on the LED at the same time I turn on a buzzer. The LED+sound stays on for 100ms, then is turned off for 100ms. Repeats continuously. This creates 6 frames of the LED on+buzzer, then 6 frames of the LED off with no sound (for 60p recording, which is 16.66ms/frame, so 6 frames in ~100ms).

S5 is configured for 4K 60p 1/250. That fast shutter speed was selected to always catch the LED turning on within a single frame. There is a lav mic into the S5 that is positioned right next to the buzzer on the Arduino. 

Observed Behavior
I expect the video to show the  LED turning on at the same time the audio waveform shows sound from the buzzer, or within 1 frame of each other, to account for any timing skew between the start of an S5 frame and the start of the LED+buzzer. Instead the S5 shows 2-3 frames of the LED on before the waveform shows sound from the buzzer, indicating that the audio is lagged/skewed by 30ms to 50ms. The lag is slightly less if I record the same setup over HDMI instead of internally. I also compare the S5 to the Sony ZV-1 recording the same setup, which shows the expected behavior of <= 1 frame lag between LED and audio.

On 11/21/2023 at 9:09 PM, Happy Daze said:

That will probably be the HDMI cable. I had the same issue. Buy something that's rated for 8K, I use this one without problem:

https://www.amazon.co.uk/gp/product/B0B76YBHPP/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&th=1

 

Good call. Bought an 18Gbps cable and the noise is gone. Here's a side by side:

First time experimenting with my S5's raw video. Recording to a VideoAssist 12G. When I view the video in Resolve I see random speckles / hot pixels / impulse noise. This is not the typical High ISO noise. Here's a video to demonstrate. This is a crop downsampled to 1080. View full-screen and stare at the lens barrel around the "25". Shot ISO 640.

If I attempt chroma NR in Resolve it takes a threshold that significantly blurs the scene content for the hot pixels to no longer be visible.

I tried the hot pixel remapping features of the camera ("pixel refresh" in Panasonic's parlance) with no change.

Don't see the the noise using the camera's internal long GOP codec.

On 11/9/2023 at 8:57 AM, Andrew Reid said:

Sony are saying there's no image quality impact from global shutter, which is of course not true. The base iso 250 and lowest ISO of 2000 in S-LOG says otherwise, and it is a bit disappointing from Sony's marketing people to suggest otherwise.

I'd rather they just be honest!

Still a great camera though.

The Starvis / Pregius S - I am not too familiar with. If it is also a stacked sensor similar to the A9 III then it's a valid comparison though.

Agreed. Sony is being unnecessarily cagey about this. In the following B&H video, Sony's Michael Bubolo claims Sony never discloses the dynamic range of their cameras, in response to a question about the A9 III's exact dynamic range - starts at 39:25:

Which is absolutely false because Sony discloses DR measurements in their actual product press releases, for example the claimed 15EV in their A7r V press release:

https://www.sony.com/content/sony/en/en_us/SCA/company-news/press-releases/sony-electronics/2022/sony-electronics-new-alpha-7r-v-camera-delivers-a-new-highresolution-imaging-experience-with-aibased-autofocus.html

A poster on dpreview compared Sony's Starvis global-shutter sensor to their rolling-shutter equivalent in more typical sensors and found it had 2.4x lower FWC, which matches up with the base ISO change to 250 for the A9 III. The global-shutter sensor Starvis also had 2x the read noise 

The Starvis is their industrial line of sensors, for example security cameras. 

Link:  https://www.dpreview.com/forums/post/67351204

2 minutes ago, Andrew Reid said:

It doesn't need to be from the same time, just the same exposure relative to middle grey and same ISO

Middle grey can only be established relative to the precise raw saturation level and without the necessary staged 9M3 raws available to establish saturation its precise middle grey is unknown. And saturation is more likely to be different for the 9M3 vs previous models since its an entirely different sensor/pixel architecture.

The link to PhotographyBlog only shows A9 III raw samples for that given shoot. Where did you find the equivalent A9 II raw taken at the same location / time?

1 hour ago, Ilkka Nissila said:

It's a little bit more complicated than that. While video users often put cameras on rigs, and fluid heads have stick handles that can be used to pan the camera without touching the camera itself, still photographers who use long lenses on tripod usually have their hands on the camera while shooting on tripod (and they probably shoot in a similar way when recording video, at least when the subjects are moving, since they typically use gimbal heads instead of the more video-oriented fluid heads). So there are circumstances where identifying whether it is safe for the camera surface to heat above 42-43 C might not be so simple.

 

That Andrew was able to make the CFexpress card slow down (and camera display slow card warning) during hack-enabled extended recording suggests that the CFexpress temperature is also close to limits. Allowing long recording times when the card slot is not used and some of the heat generation is moved to the external recorder seems like a sensible practical compromise. Canon may continue to make refinements to the overheating management algorithm. But it doesn't seem like the hopes expressed in this forum and what Canon would consider a good design for the typical user of this camera are going to align.

I can't think of many scenarios where a user shooting video with the camera locked down on a tripod would have to touch the camera for anything other than a momentary dive into the menu, the LCD for focusing, and perhaps the body during panning. Canon talked about low-temperature burns - the camera wont be a thermal risk if the user only touches it intermittently and for a few seconds at a time. It's not hot like a potato.

Regarding CFE, Canon has multiple warnings in the R5 manual about handling hot cards that have been removed from the camera. That can occur for stills shooting as well, esp long duration burst-shooting.

2 hours ago, Ilkka Nissila said:

43 C is regarded as the limit of temperature that is safe for human tissue so that it's not damaged due to the heat. That's what is used in medical devices as the safety limit: during use, the device must not heat the tissue temperature above 43 C. If the temperature of the skin does rise above 43 C then you can expect some damage, though I don't know how quickly it happens or how severe it is. Roger writes "we ran it for 18 minutes before getting a temp warning. The hottest part of the camera was the back behind the LCD door (43°C / 109°F)". So it seems that the 43 C tissue damage threshold is indeed what Canon used to design their overheating algorithm to protect primarily against, and they're running it pretty close.  (Canon also mention controls for internal temperatures as a secondary consideration in the CineD interview).

 

Of course, if you don't hold the camera in your hands during recording and use a tripod or gimbal, then it wouldn't cause burns. But they seem to have designed the protection for those in mind who do their videos hand-held. My guess is that the 43 C could actually be written into some countries legislation or regulations as well, so Canon might not have any choice about it. I'll try to find some information on this.

If limiting skin exposure to heat is the primary goal of Canon's thermal management they should be able to easily distinguish between hand-held and tripod use via either the IBIS gyros or the camera level sensors, and use that information to establish the appropriate temperature thresholds. With some user warnings to handle the scenario of moving between tripod and hand-held use. 

1 hour ago, visionrouge said:

Canon Just released a Firmware V1.1.1 for R5 and R6

Be aware of possible lock down on my hack finding last Sunday.
Even if I think it will be a very fast answer to roll out a firmware in only 3 days, that's still a possibility.

At least, it may be able to do a file comparison between V1.1.0 et V1.1.1 to see what changed is any.

The last bullet point for today's R6 1.1.1 FW release is interesting:

"The phenomenon in which the movie recording time available is not correctly displayed when the Date/Time/Zone is not set has been corrected."

I wonder if the previous R6 firmware not only failed to displayed the available recording time when the clock wasn't set but also allowed it to bypass the thermal limits as a result.

1 hour ago, Andrew Reid said:

It's a weird one.

They all covered the firmware release by Canon and the hack with the screw.

Then I think they had their fill of the subject and saw the clicks decreasing and moved on.

But DPReview, Newsshooter, CineD, you'd think they would run a story. Why not?

It's the biggest development in the whole long overheating saga!

That you can just go into the date menu, and pull the battery, and boom - no more overheating.

They are completely silent and it makes me think Canon has sent some very disapproving nods in their direction that if they cover this they will rock the boat and they won't have friends in high places any more.

I think it's a combination of point #3 (fatigue on the subject) and the slight recording-time improvements achieved with V1.1, which may have pacified some YouTuber's and R5 owners.

I've created a web-based javascript app that lets you quickly set the camera's clock to +1 day and -1 day to help automate visionrouge's workaround. It only works in browsers that allow you to disable CORS Policy Security. Unfortunately none of the mobile web browsers available support that option, so for now this is limited to home/office/studio use.

Here is the link to the app: http://www.testcams.com/ccapi/datehack.html

Full instructions including how to disable CORS Policy security are in the GitHub repository: https://github.com/horshack-dpreview/canondatehack.html

38 minutes ago, Coffe said:

It seems too simple to be true. But it is. There is a camera reset procedure now. Whenever your R5, R6 is overheated, just go quickly through your date change, battery drop procedure. And your camera is back on and fully operational for all video modes. No matter what card you use.

Only if your camera surpasses 65 or maybe 70°C, that's when the real overheating warning kicks in.

The other question of course still remains - how much can or will the camera endure in long term? But as long as you use this neat trick only to get rid of the ridicously long cool down periods I'd say it's fine. 

With FW V1.1 I think the gap between how hot Canon lets the camera run and how hot the camera should run (to avoid IC longevity issues) has narrowed. Canon's original thermal management firmware implementation was quite clumsy and too coarse for lots of scenarios. They addressed some of those scenarios with better ambient temp sensor integration into the algorithm. There's still room for improvement, which hopefully Canon will do eventually. Until then I think the new workaround is a great stopgap, including for situations where you absolutely have to get the shot and don't care about an occasional short-term temperature spike. 

1 hour ago, Coffe said:

This is Pictogram. I took a foto with my R5 close to that moment: 

Not pretty - but it should have the precious temperature reading you're looking for 🙂

Next time I will take that picture once I see the symbol again. It comes in red and also in white. And it disapeared seconds after I took out the CFExpress card.

 

Thanks. It's 75C, a new high record for the R5 🥵

4 minutes ago, Coffe said:

But this is interesting: There is another overheat symbol appearing after 15 minutes into my seconf 120fps run: one without the camera, a thermomter only. After stopping and taking out the card (leaving in the SD card) the symbol turns white. It disapears after taking out the (very hot) CFExpress card. So it seems to be an overheat warning for the CFExpress card.

 

That's the overheat warning for stills operation. Page 284 of Canon R5 manual.

Can you do me a favor and take a photo next time you see that stills warning? I'd like to check the camera's temperature for that threshold. It's embedded in the EXIF of stills images - you can send me a link to the out-of-camera image so I can extract it. Thanks!

Here's a Canomate script for automatically setting the camera's clock +1 day and then back:

https://www.magiclantern.fm/forum/index.php?topic=24827.msg230542#msg230542