horshack

Wow your site is fantastic. Lots of useful LUT tools there. Going to try out the false-color generator right now.

Nikon recently released a new universal N-Log technical LUT for all their cameras, which replaces Nikon's original camera-specific LUTs. The original LUTs handled highlights particularly poorly. In fact they didn't really handle them at all - they inexplicably clipped all N-Log values above ~68% to white. Here is my analysis of the new LUT. First here are the tone/gamma curves for both the original vs new LUTs, which I calculated by converting both 3D LUTs to 1D and graphing the resulting curves. Notice how the original LUT clips all highlights above 68% to white, whereas the new LUT has a nice, smooth roll-off. Here is a visual comparison showing the original vs new LUT in action. This is a high DR N-RAW capture from a Z6 III, with the original vs new LUT compared, along with a comparison to the same scene using Davinci Resolve's CST with tone mapping. For reference, here is how Nikon describes the new LUT in the comments at the top of the LUT file: # Development Color Space = REC709 # Output Gamma Curve = BT1886 # Output Tonemap = MEDIUM_CONTRAST # Highlight Rolloff = Rolloff 2 - medium

I've just published a YouTube video with my Nikon Z6 III sensor readout speed measurements. It also provides some background information about the my crowd-source rolling shutter project on GitHub.

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.

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.

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.

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.

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.

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:

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.

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.

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

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?

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.

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.

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.

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

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.