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.