More Gemini, Samurai, AC-Log and S-Log sample frame grabs. See download box at bottom of post.
I had thought, when I first wrote this post that I had discovered a strange issue where the 444 RGB recordings from the Gemini had more dynamic range than 422 recordings. I didn’t think this was right, but it was what my NLE’s (FCP and CS5.5) were telling me. Anyway to cut a long story short, what was happening was that when I dropped the Gemini RGB files into the timeline the levels got mapped to legal levels, i.e. nothing over 100% while the YCbCr 422 clips go into the timeline at their original levels. The end result was that it appeared that the 422 clips were clipping before the 444 clips. Thanks to Waho for suggesting that it may be a conversion issue with the frame grabs, I was able to see that it was simply the way the NLE’s (both CS5.5 and FCP were behaving in the same way) were clipping off anything in the 422 clips above 100% both in the frame grabs and also on the monitor output. As the RGB files were all below 100% they were not clipped so appeared to have greater dynamic range.
Anyway….. below is a new set of frame grabs layered up in a single photoshop file showing how the various codecs and recorders and codecs perform. The levels in these have been normalised at 100% to avoid any dodgy clipping issues. I’ve included F3 Cinegamma 4, plus my AC-Log picture profile, plus Samurai ProRes, Gemini S-Log and F3 Internally recorded S-Log of a very extreme contrast situation. Use the link below to download the photoshop layers file. You’ll need to me a registered user to access the link.
[downloads_box title=”More codec test grabs.”]
Photoshop Layered Frame Grabs v3
[/downloads_box]
Thanks for the examples
Likely the difference is from the color space conversion method used to take frame grabs. For example, if you took the 4:2:2 Y’CbCr material and applied Rec.709 conversion to generate the RGB still image, you lose both Y’ values 940 in 10-bit values ( 235 in 8-bit values for xdcam). i.e superbrights and superdarks are clipped
This is also why the contrast in the “xdcam” and “prores” images are greater. For the 8bit xdcam case, Y’ 16 or “white” is mapped to RGB 0,0,0 and Y’ 235 or “black” is mapped to RGB 255,255,255 as specified by Rec.709 . So you lose those superbrights and superdarks, and there is a contrast increase. Instead, if you used a full range conversion, Y’ 0 would be “mapped” to RGB 0,0,0 and Y’ 255 would be “mapped” to RGB 255,255,255 , preserving the superdarks/brights, and the resulting RGB image would have less contrast. ( Similar for the prores case, but in 10-bit values)
Not shown in this example, but similar effect can occur with Cb and Cr chroma clipping, but with 16-240 in 8-bit values
For the Gemini, of course there is no alteration in RGB, it’s already in RGB.
If your software used is able to operate in Y’CbCr, then you can recover those “super” values before conversion to RGB frame grab or grading if you are working in RGB
(My first paragraph was cut off for some reason)
Thanks for the examples
Likely the difference is from the color space conversion method used to take frame grabs. For example, if you took the 4:2:2 Y’CbCr material and applied Rec.709 conversion to generate the RGB still image, you lose both Y’ values 940 in 10-bit values ( 235 in 8-bit values for xdcam). i.e superbrights and superdarks are clipped
This is also why the contrast in the “xdcam” and “prores” images are greater. For the 8bit xdcam case, Y’ 16 or “white” is mapped to RGB 0,0,0 and Y’ 235 or “black” is mapped to RGB 255,255,255 as specified by Rec.709 . So you lose those superbrights and superdarks, and there is a contrast increase. Instead, if you used a full range conversion, Y’ 0 would be “mapped” to RGB 0,0,0 and Y’ 255 would be “mapped” to RGB 255,255,255 , preserving the superdarks/brights. ( Similar for the prores case, but in 10-bit values)
Not shown in this example, but similar effect can occur with Cb and Cr chroma clipping, but with 16-240 in 8-bit values
For the Gemini, of course there is no alteration in RGB, it’s already in RGB.
If your software used is able to operate in Y’CbCr, then you can recover those “super” values before conversion to RGB frame grab or grading
Thanks Waho.
You are correct. The issue is with the way the NLE’s translate and display values over 100% (235,940 etc) and convert to RGB frame grabs. It was the fact that I was seeing the problem on both the frame grabs as well as on my monitors that was puzzling me. Applying a simple levels filter to the non-RGB recordings and bringing them down below 100% does bring back the “lost” highlights.
Sorry for the posting problems / It should say:
Likely the difference is from the color space conversion method used to take frame grabs. For example, if you took the 4:2:2 Y’CbCr material and applied Rec.709 conversion to generate the RGB still image, you lose both values Y’940 in 10-bit values ( 235 in 8-bit values for xdcam). i.e superbrights and superdarks are clipped
Y’ 940 in 10 bit values
Y’ 235 in 8 bit values
I don’t know why the message board is cutting it off
Sorry
Hi,
thanx for the stills! AC-Log seems quite soft though… Why is that?
on the other hand internal s-log holds up remarkably well imho!
AC-Log has no artificial image sharpening or detail correction. As it is a low contrast image it will appear to be softer as sharpness is a function of both resolution and contrast. After grading it would look much sharper and you can add further sharpening in post if you desire. As for the internal recording holding up, well it depends on many things but you might want to take a quick look at this : http://www.xdcam-user.com/2011/12/this-is-why-you-want-an-external-recorder/