Answer this: If new broadcast deliverable standards demand Super35, what about MFT?

[Cliff Totten]

Originally Posted by Cary Knoop

You made your point, I made mine.

I think you should not use 8 bit devices for Log or HDR.

I seems to me we have to agree to disagree! :)

Dont get me wrong,..I think we all know that 10bit is the optimal color depth sampling we's like to use with any log gamma. Yup,..if given the chance, I'll take 40 times more color space in a log recording ANY day! AGREED!

However, this does not mean that you "can't" get very good results with 8bit. You still can. And, if you use recorded 8bit color output to ProRes HQ, your results improve even more. May people blame banding on 8bit stair steps when the REAL problem is h.264 Log GOP compression instead.

When H.264 Long GOP is stressed, it clusters pixel values into single value "blocks". It can represent,...let's say 8 pixels and assign them all ONE single color value. This "looks" like 8bit banding but it's really not! H.264 will also sacrifice gradients and shadows first. Yes,..shadows WILL look "muddy" at times during highly complex scenes that stress the bandwidth cap.

Again, this is not 8bit's fault. 8bit's in ProRes HQ is actually pretty darn durable. No, it's not 10bit and yes, it's a "thinner" space,...but you can EASILY still get great really good results with logarithmic gamma color grading.

CT

[Gary Huff]

Originally Posted by Cliff Totten

May people blame banding on 8bit stair steps when the REAL problem is h.264 Log GOP compression instead.

Except it's not Long GOP compression, it's bitrate. AVCHD gets stressed easier than XAVC S. Both are H.264 LongGOP, but one tops out at 24Mbps while the other tops out at 50Mbps. At some point, you can throw enough bitrate at LongGOP, where it won't get stressed.

When H.264 Long GOP is stressed, it clusters pixel values into single value "blocks". It can represent,...let's say 8 pixels and assign them all ONE single color value. This "looks" like 8bit banding but it's really not! H.264 will also sacrifice gradients and shadows first.

This true of H.264 Intra as well, if you don't have enough bitrate for it.

[Cary Knoop]

Originally Posted by Cliff Totten

May people blame banding on 8bit stair steps when the REAL problem is h.264 Log GOP compression instead.

When H.264 Long GOP is stressed, it clusters pixel values into single value "blocks".

All DCT based compression uses blocks whether it is H.264 or ProRes.

H.264 can compress in addition to intra-frame compression the motion compensated difference between frames.

Given the same bitrate inter-frame and intra-frame compression combined will provide a superior image compared to only intra-frame compression.

The only disadvantage to files that have inter-frame compression is that it is hard to edit because the decompression depends on multiple frames.

H.264 is neither better nor worse than ProRes, it all depends on the bitrate and you can encode H.264 all-intra and also use lossless compression.

[Steve Burkett]

Originally Posted by Gary Huff

So you can point out the A7S/A7R Slog2 footage out of this trailer? Can you point to specific segments where the 8-bit shows where it's lacking?

A STREET CAT NAMED BOB Official Trailer (2016) - YouTube

Gary, with respect, it would take a damn good pixel peeper to point out 8 bit slog footage from a Trailer such as this. Fast clips that barely register on screen hardly allow time for the human brain to process what they are seeing without judging the quality of the footage. By all means, show a long clip of the movie and ask the same question, but this Trailer..... I'm not a robot you know. :)

Personally I prefer using 10 bit for Log and HDR; I just find it grades easier. That said, I've used Log for 8Bit and it ain't bad.

That said, with A Street Cat Named Bob, they were using an Atmos Shogun, shooting at 4:2:2 colour, at a high data rate. So perhaps the argument is, that shooting Log on 10 bit isn't the issue, but shooting with 4:2:2 colour is important. With my GH5, that means shooting 10 bit.

[Cliff Totten]

Originally Posted by Cary Knoop

All DCT based compression uses blocks whether it is H.264 or ProRes.

H.264 can compress in addition to intra-frame compression the motion compensated difference between frames.

Given the same bitrate inter-frame and intra-frame compression combined will provide a superior image compared to only intra-frame compression.

The only disadvantage to files that have inter-frame compression is that it is hard to edit because the decompression depends on multiple frames.

H.264 is neither better nor worse than ProRes, it all depends on the bitrate and you can encode H.264 all-intra and also use lossless compression.

Understood. I understand DCT compression and cluster averaging. My only point on that os that ProRes HQ is nowhere near as agressive in this process relative to H.264 Long GOP at a low bit rate. The lower the bit rate your cap is and the more complex your scene is the more and more macroblocking you get. And vice versa as you move back "up" the bitrate ladder.

Yes, given enough bit rate, Long GOP can be tough as nails too. No doubt about that.

My point was that this process "can" look like banding and is easy to blame 8bit sampling for. I have done test recordings with 8bit XAVC-S and 8bit ProRes HQ and the stretched the Hell out of both and seen the h.264 "band" way before the same shot did in 8bit ProResHQ. This happened because what I saw was not "true" 8bit banding but compression "banding" (macroblocking because of a sressed CODEC)

Thats my only point.

And yes....we ALL love 10bit here. Im sure nobody is arguing that 8bit is just as good. I think we are mostly just trying to say that 8bit CAN still give very good results too.

[Cary Knoop]

Originally Posted by Cliff Totten

My only point on that os that ProRes HQ is nowhere near as agressive in this process relative to H.264 Long GOP at a low bit rate. The lower the bit rate your cap is and the more complex your scene is the more and more macroblocking you get. And vice versa as you move back "up" the bitrate ladder.

Duh!

You are comparing a high bitrate apple with a low bitrate H.264 pear.

You can encode H.264 with 800Mbps as well, long GOP or all-intra, or could even compress is lossless.

Your point that long GOP is the problem does not make any sense.

[Gary Huff]

Originally Posted by Steve Burkett

I've used Log for 8Bit and it ain't bad.

I agree with you.

So perhaps the argument is, that shooting Log on 10 bit isn't the issue, but shooting with 4:2:2 colour is important. With my GH5, that means shooting 10 bit.

All of that is important, but Vlog L on the GH5 is a gimped Vlog log from the VariCam 35 (they literally just carved 3-stops out of it and saddled it with a Rec.709 gamut), a camera which shoots 10-bit 4:2:2 at a minimum. This is why Vlog L works best in 10-bits. Other logs developed for 8-bit, such as Clog, Slog, Slog2, J-Log, D-Log, etc. will show less banding issues (the typical artifacting that stems from stress 8-bit).

[Gary Huff]

Originally Posted by Cary Knoop

Your point that long GOP is the problem does not make any sense.

It only doesn't make sense in that you described what you see as "mud", not banding. Otherwise, I get what he's saying.

I assume you see "mud" because you have in-camera noise reduction turned up too high. Log profiles are generally less forgiving with noise than a more straightforward Rec.709 profile.

[Cliff Totten]

Originally Posted by Cary Knoop

Duh!

You are comparing a high bitrate apple with a low bitrate H.264 pear.

You can encode H.264 with 800Mbps as well, long GOP or all-intra, or could even compress is lossless.

Your point that long GOP is the problem does not make any sense.

Ok....that was not my point either....

Shortly put,...My point is that banding problems are commonly blamed on 8 bit stair steps. The truth is that MANY times this is the wrong diagnosis! It's often COMPRESSION that is to blame, not bit depth.

Sometimes its very hard to tell the difference between "real" 8bit banding problems and compression-caused banding!

Thats it. 8bit gets a bad rap allot of times. Nobody can just look at a video and go: "Oh yeah,....yup, that's 8bit banding alright, yup...mmm hmmm". It's not super easy to immediately finger a video like that. Everything else I said about Long GOP and ProRes and h.264 is just there to support this really simple point.

CT

[Tom Roper]

My brother owned a picture framing shop, is an award winning photographer, recently won a contest that awarded some prize money, his work display on chamber of commerce type billboards, city buses. When he went to accept the award and be recognized, he wore a Nikon D800 around his neck but the winning picture he shot with an iPhone.

[Cliff Totten]

Nice!

Yknow,...if examples like this "shock" people?

If a snooty engineer-type guy goes...

"What?...that amazing scene was shot on 8bit?.."

"Huh?....Avatar was shot on tiny 2/3 sensor cameras?"

"Award winning photo with a tiny iPhone?..impossible!"

"My God,...how are these things possible using such low standards"

Anybody that thinks stuff like this is a total idiot.

People should NOT have to know "what" a video was shot on "before" they allow themselves to accept it is good. We should be able to analyze the quality of a video with only the merits of its visual qiality FIRST. Then determine if it is good THEN ask what it was shot with.

Zakuto's blind camera challange proved that almost any camera can look great if you shoot ot well. Even big name DP's could barely tell all the cameras they blind tested.

[Christopher Young]

EVA1 just made the infamous NETFLIX list:

https://partnerhelp.netflixstudios.c...-Image-Capture

Chris Young

[Kevin Lau]

Originally Posted by Christopher Young

EVA1 just made the infamous NETFLIX list:

https://partnerhelp.netflixstudios.c...-Image-Capture

First time I'm seeing this list. It is interesting that they class based on resolution and recording codec, not sensor size like so many other organizations do.

[Jack Zhang]

Seems like a GH5s, Ninja Inferno, a XL Speedbooster and a Sigma 24-35 would fit this with V-Log. They don't seem to support HLG, only V-Log.

[Christopher Young]

Originally Posted by Kevin Lau

It is interesting that they class based on resolution and recording codec, not sensor size like so many other organizations do.

EBU and NTSC have never had objection to sensor size. It's always been performance and codec bit rate based.

The new Sony PXW-Z280 with its 3 x 1/2" UHD chips will most likely make the list. In 50/60pp it claims a 63dB signal to noise ratio. This SNR is way above anything most of the S35 and M4/3 single sensors can deliver. It can record UHD 50/60p 422 10-bit up to 500/600 Mbps. Bare in mind also that with 3 x sensors each sensor is a full 3840 x 2160 in all channels, R,G & B. So no Debayer algorithm required. Resolution should be very good. With an f1.6 lens that is parfocal 17 x and constant aperture with end stop focus ring I think they will sell a few.

Details here:

Newsshooter

https://www.newsshooter.com/2018/03/...pxw-z280-z190/

YouTube

Sony| PXW-Z280 | Introduction Video - YouTube

Full Sony details here

https://pro.sony/ue_US/products/hand...rders/pxw-z280

On paper this spec is well within the requirements for Netflix and many other broadcasters. With 12G out you can SDI it into an Atomos for full UHD 50/60p ProRes and that will meet most requirements world wide.

Chris Young