Jump to content

horshack

Members
  • Posts

    167
  • Joined

  • Last visited

1 Follower

About horshack

Recent Profile Visitors

2,711 profile views

horshack's Achievements

Active member

Active member (3/5)

53

Reputation

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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/
  8. 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:
  9. Yep, I've started using the Arduino just for that purpose, to have a precise video/audio sync lead-in.
  10. 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.
  11. Good call. Bought an 18Gbps cable and the noise is gone. Here's a side by side:
  12. 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.
  13. 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
  14. 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
  15. 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.
×
×
  • Create New...