FS5: FS5 4K color and bit depth

[Tom Roper]

David's explanation seems sound, but your interpretation of it is off.
10-bit colour depth offers 1024 independent of red, green and blue. Being able to yield 1024 shades of green, but only 256 shades of blue and red does beat having 256 shades for all three, but it still does not equal proper 10-bit colour depth; and therefore leaves you open the same limitations that lack of tonality in red and blue presents in regular 8-bit footage.
There's no free lunch with these things, and it really does no one any good to let hyperbole cloud the issue.

If you think I am claiming free lunches, or even that my interpretation is wrong, I would ask you to quote me. In the absence of that, I'll quote myself about 16 posts before yours (below), where the explanation I gave fit 100% with David Newman's. I'm not even sure why you would think what I said was different from what you just posted above.

But what David is saying is by working in uncompressed 10 bit RGB space, instead of discarding the luma samples you can add 4 together to make one 10 bit luma sample, effectively giving you 10 bit 4:4:4 1080p. There is one small catch, you don't have 4 chroma samples to sum together like luma, so your 10 bit 4:4:4 RGB values will only have 8 bit precision for the chroma samples that went into the conversion to RGB. The luma samples that went into the conversion to RBG would be genuine 10 bit however.

You won't be getting 10-bit tonality from downsampling 8-bit 4k into 1080p. Only improved chroma subsampling. Which is silly. If you're going to end up with 1080p footage anyway, shoot it at 10-bit to begin with (either internally or recorded externally), then you'll have enough bit depth to use SLOG properly and get a nice result.

He won't be getting 10 bit tonality but he could lose luma and chroma samples by not transcoding to 1080p 10 bit RGB. Compared to the 4k 8 bit 4:2:0 source, we are not improving chroma subsampling in the downconversion, just preserving it. As for the luma, we are improving the 1080p shading precision to 10 bit by summing 4 samples from adjacent pixels (super sampling) that otherwise were going to be tossed.

 

[Ebrahim Saadawi]

The codec in the FS5 is limited not by marketing but by actual hardware ability, which is limited by cost, which is limited by marketing slots.

It's a 10bit 4:2:2 HD camera and an 8bit 4:2:0 UHD LongGOP camera shooting to SD cards.

It is what it is. You either find its ability sufficient or not, only based on your needs.

 

[ectobuilder]

Until we found the CRAPPY UHD 420 8-Bit XAVC-L Codec. Common Sony! What the hell is that??? Were you afraid that FS5 would take some share from your FS7? It can only be...

Well, I can only say Sony this much: If you had given FS5 422 10-Bit UHD internal recording capabilities we wouldn't think twice and jumped over it in no time! Now, it's not even an option, unfortunately.

For me it all comes down to Story. Therefore I don't consider resolution to be a a storytelling tool that is necessary to captivate audiences. Color on the other hand is an important tool. And for that reason the 10-bit 422 HD is something I would consider.

And because I tend to be more creative with cameras that are lighter and smaller, the FS5 is a winner over the FS7 for me.

 

[paulcurtis]

As for 8 bit -> 10 bit Tom is correct. I wrote about this back in feb with some examples. (posted a day earlier than EOSHD!)

http://blog.inventome.com/Blog/2015...d-Noise-Workflow-with-UHD-and-Odyssey-7Q-Plus

So long as the scaling is done in higher depth then there is an 'effective' increase in tonality due to averaging the values.

Over those years as everyone points out storage may become your biggest issue and you're doing a doc, so vfx and post probably isn't an issue. Therefore compressed codecs would be ideal. The FS700+RAW is a fantastic combo but not for you.

Whether you need I frame or not i guess depends on your threshold quality. If you're in situations you cannot control then the higher quality would give a bit more latitude in post in terms of exposure and balance.

But if reframing is more important meaning 4K overrides that then a 4K based compressed codec has priority?

Have you considered point and shoot cameras, like the sony RX series or Panasonic GH? Would multiple cameras and size be an advantage rather than a single bigger cam.

cheers
Paul

 

[stokstad]

I would go with the FS5 and shoot in HD for most shots but having the benefit of 4K in some situations, like wide landscape shots of citys for example. For a documentary project the cost savings of shooting HD (and long gop) is also great, and the post production will be easier. For the 4K shots you can spend a little more time in post doing noise reduction, cropping, etc. But you would not want to do that to all your material in a longterm docu-project?

 

[Nirv]

The 8 bit - 10 bit benefit is complete bunkum and is regularly trotted out and has entered the dvx zeitgeist just like converting to ProRes before grading was all the rage in the HDV era.

While the maths are correct they do not survive contact with the reality of compressed footage.

The codecs are engineered in such away to compress the less obvious areas of the image such as the blacks and large swathes of similar tones such as sky and these are precisely the areas that one wants the fine 10 bit graduations. Unfortunately the compression has posterised these values in these areas and while to the human eye the image looks fine the damage has already been done to the 8 bit - 10 bit theory. The compression artefacts are by far the most limiting factor to grading not whether the file is 8 bit or 10 bit.

You're simply wasting your time and throwing out 3/4 of you luma info for a 10 bit HD file that grades no better than its 8 bit UHD counter part, instead of destroying data you should edit and grade the 8 bit as normal then resize for delivery that way any vignettes or filters that have been applied.

The only real way of overcoming the compression damage is to strip the file into its components YUV and blur the UV channels and then recombine and downsize. I've written an FCPX plugin to do this to help with keying and comes from the days of keying DV footage. This doesn't help any damage to the luma data of course and is no free lunch. To do the UV Blur effectively it needs to be done on a per shot basis in a compositor and no one has time for that.

Don't waste your time with the 8 bit - 10 bit conversion as it only works with uncompressed data despite what the great minds of dvxuser say.

 

[ectobuilder]

The 8 bit - 10 bit benefit is complete bunkum and is regularly trotted out and has entered the dvx zeitgeist just like converting to ProRes before grading was all the rage in the HDV era.

While the maths are correct they do not survive contact with the reality of compressed footage.

The codecs are engineered in such away to compress the less obvious areas of the image such as the blacks and large swathes of similar tones such as sky and these are precisely the areas that one wants the fine 10 bit graduations. Unfortunately the compression has posterised these values in these areas and while to the human eye the image looks fine the damage has already been done to the 8 bit - 10 bit theory. The compression artefacts are by far the most limiting factor to grading not whether the file is 8 bit or 10 bit.

You're simply wasting your time and throwing out 3/4 of you luma info for a 10 bit HD file that grades no better than its 8 bit UHD counter part, instead of destroying data you should edit and grade the 8 bit as normal then resize for delivery that way any vignettes or filters that have been applied.

The only real way of overcoming the compression damage is to strip the file into its components YUV and blur the UV channels and then recombine and downsize. I've written an FCPX plugin to do this to help with keying and comes from the days of keying DV footage. This doesn't help any damage to the luma data of course and is no free lunch. To do the UV Blur effectively it needs to be done on a per shot basis in a compositor and no one has time for that.

Don't waste your time with the 8 bit - 10 bit conversion as it only works with uncompressed data despite what the great minds of dvxuser say.

Ah good point. So the 10-bit 422 HD internal on the FS5 is COMPRESSED. I totally overlooked that. So the HDMI/SDI out signal is still better because it is uncompressed?

So to an external recorder like a Ninja/Odessy that that records in Prores it is still better than the internal recording on the FS5?

 

[paulcurtis]

Don't waste your time with the 8 bit - 10 bit conversion as it only works with uncompressed data despite what the great minds of dvxuser say.

8 to 10 works only if you're downsampling from a decent source, true, but doesn't have to be uncompressed. The enclosed image from that blog articles has a comparison but then the source was ProRes HQ out of the camera, the best 4K image i could get via a recorder.

You are right in that there is a tradeoff there between compression and bit depth. There is an argument that asks

is a 100mbit UHD image better than a 50mbit HD image (thinking specifically on the A cameras). And the answer is simply depends what you're shooting.

In the OP case it sounds like 4K offers reframing choices and then a downsample on top of that will only help. You'd never make anything worse. You could even run some reconstruction of channels at 4K before downsample to improve the results, but in this case it may not be worth the effort.

Just taking UHD putting it on a scaled timeline in most NLEs will gain some benefits.

http://inventome.blob.core.windows.net/media/banding.jpg

cheers
Paul

 

[naavt]

If you're in situations you cannot control then the higher quality would give a bit more latitude in post in terms of exposure and balance.

Completely agree. The main reason to work in a better bit-rate and color space has to do imminently with that.

But if reframing is more important meaning 4K overrides that then a 4K based compressed codec has priority?

That's the catch right there. Even if we can somewhat anticipate the importance of one versus another (it will be very hard at some point I presume), it would be so much better that we had those two fronts covered at the same time, not needing to put one in front of the other and vice-versa.

Have you considered point and shoot cameras, like the sony RX series or Panasonic GH? Would multiple cameras and size be an advantage rather than a single bigger cam.

cheers
Paul

We will use multiple cameras for sure. We will need crash and action cameras for sure and we already decided on the Hero Session for that. We are assuming for a start that those shots will be brief in the final edit. Those cameras will be mounted on fast moving objects with jerky, non controlled motion, so we are not worried about intercutting the Hero shots with the other footage, no matter what camera it will end to be.

We have 2 GH4 in our production house and the first consideration was to use them, but then the lack of a decent slow motion trowed it away from our list, That's why we have put BMD URSA mini into consideration since it goes to 160fps. The Sony is a clear winner in that respect and it's slow motion capabilities would be a very good asset in this project.

I would go with the FS5 and shoot in HD for most shots but having the benefit of 4K in some situations, like wide landscape shots of citys for example. For a documentary project the cost savings of shooting HD (and long gop) is also great, and the post production will be easier. For the 4K shots you can spend a little more time in post doing noise reduction, cropping, etc. But you would not want to do that to all your material in a longterm docu-project?

We plan to edit as we go. Things can be altered radically once everything is shot and the project can make a 180º turn depending on where protagonists will lead us. This is not a talking heads documentary so we are planning to start putting things together every time we are not shooting.

Don't waste your time with the 8 bit - 10 bit conversion as it only works with uncompressed data despite what the great minds of dvxuser say.

Today I've phoned to Sony Professional here explaining the whole situation and they were kind enough to schedule a meeting next Wednesday (16th). I've found strange that they haven't an FS5 with them but they assured me they will. They want to talk to me first! I presume they want to give me their sales rhetoric and gain a new buyer.

Anyway, I've talked with them about the codec and that my main goal contacting them is to test the camera. So the 8 to 10-bit conversion will be a factor that I will test for sure, just to rest assured that it works or it don't.

Just taking UHD putting it on a scaled timeline in most NLEs will gain some benefits.

http://inventome.blob.core.windows.net/media/banding.jpg

cheers
[FONT=Verdana, Arial, Tahoma, Calibri, Geneva, sans-serif]Paul

[/FONT]

[FONT=Verdana, Arial, Tahoma, Calibri, Geneva, sans-serif]That's promising [/FONT]

 

[morgan_moore]

Probably not relevant to this thread but maybe.

Here is GH4 4k vs GH4 HD 8bit put on a Resolve timeline.

I dont know if it is resolution or colour depth downscaling but the 4k grades better on a 1080 timeline.

https://www.dropbox.com/s/ayywi8rtv4judhx/grade1.jpg?dl=0

 

[naavt]

Probably not relevant to this thread but maybe.

Here is GH4 4k vs GH4 HD 8bit put on a Resolve timeline.

I dont know if it is resolution or colour depth downscaling but the 4k grades better on a 1080 timeline.

https://www.dropbox.com/s/ayywi8rtv4judhx/grade1.jpg?dl=0

I have just ended a call with a friend who regularly shoots 4k and delivers 1080p and he too confirms that the theory holds up. Curiously I didn't know that he's also on board for a new camera and just like me he pondered on the FS5 until he realized that it shoots Long GOP and 8-bit 4:2:0 UHD.

In the end, an FS5 + recorder will end up in the price range and size of an FS7.

 

[naavt]

I've just realized that putting an external recorder to work on a FS5 will dismiss the best thing that XAVC has to offer: Storage rates.

If we do the math, Codec, viewfinder, wider sound input options, longer HFR bursts and a probable fee for future FW RAW update ample justifies the FS7 price tag comparing it to it's baby brother.

 

[Tim Naylor]

Shoot fs5 1080p 10 bit. It's not 4k but how many clients these days insist on 4k deliverable?

 

[naavt]

Shoot fs5 1080p 10 bit. It's not 4k but how many clients these days insist on 4k deliverable?

It hasn't to do with delivery. It has to do with wider options in post, especially with reframing.

 

[LeoGrey]

It hasn't to do with delivery. It has to do with wider options in post, especially with reframing.

Not sure about others but I view Re framing as more of a luxury option than an actual necessity/requirement. Perhaps your needs differ but I would certainly prioritize image quality over resolution with the only exception being if I wanted to stabilize the footage in post.

A good eye and understanding of composition trump reframing any day

 

[Grug]

I've just realized that putting an external recorder to work on a FS5 will dismiss the best thing that XAVC has to offer: Storage rates.

If we do the math, Codec, viewfinder, wider sound input options, longer HFR bursts and a probable fee for future FW RAW update ample justifies the FS7 price tag comparing it to it's baby brother.

I think that's the right call.

 

[naavt]

Not sure about others but I view Re framing as more of a luxury option than an actual necessity/requirement. Perhaps your needs differ but I would certainly prioritize image quality over resolution with the only exception being if I wanted to stabilize the footage in post.

A good eye and understanding of composition trump reframing any day

Completely agree with you but on the other hand there are things in life which we can't control no matter what. We know for sure that we're going to face serious difficulties to properly frame what we have to shoot - everyday. So having "that" margin to reframe a head and put it inside the frame and - as you pointed out - stabilize the footage, will be a very important asset to this project.

I think that's the right call.

Yes, I think there's no turn around that. It remains to be seen if we can stretch the budget to reach it or not. And I certainly will miss FS5's weight and form factor. It's a real pity that UHD 8-bit 420 L Codec

 

[paulcurtis]

David's explanation seems sound, but your interpretation of it is off.

10-bit colour depth offers 1024 independent of red, green and blue. Being able to yield 1024 shades of green, but only 256 shades of blue and red does beat having 256 shades for all three, but it still does not equal proper 10-bit colour depth; and therefore leaves you open the same limitations that lack of tonality in red and blue presents in regular 8-bit footage.

There's no free lunch with these things, and it really does no one any good to let hyperbole cloud the issue.

Don't forget that these codecs don't store RGB data, they hold YUV which is very different so this idea of shades or red etc,. don't apply. When you ask for RGB from one of these movie formats *something* in that pipeline converts to RGB. That conversion can be quite different, quicktime has a number of pixel formats and they each produce slightly different results including the dithering of the RGB colours. Yes, so if you specify something like 16 bit RGB from QT then QT will dither the result - and you'll not see banding, but it's just false dithering obsfucating the actual source.

Don't think 8 bit -> 256 shades of RGB, it's not.

8 bit YUV holds the luma signal in 8 bit but the colour differences are subsampled massively and also the difference channels don't occupy anything like 256 shades.

Having said that it's quite remarkable how little colour information is needed to get a decent image back but when pushing that image that colour subsampling does matter.

I think everyone should look at a YUV file and actually *see* what you're getting, then you'll understand the limitations and sacrifices made and why these formats aren't ideal for some post tasks..

cheers
Paul

 

[naavt]

Don't forget that these codecs don't store RGB data, they hold YUV which is very different so this idea of shades or red etc,. don't apply. When you ask for RGB from one of these movie formats *something* in that pipeline converts to RGB. That conversion can be quite different, quicktime has a number of pixel formats and they each produce slightly different results including the dithering of the RGB colours. Yes, so if you specify something like 16 bit RGB from QT then QT will dither the result - and you'll not see banding, but it's just false dithering obsfucating the actual source.

Don't think 8 bit -> 256 shades of RGB, it's not.

8 bit YUV holds the luma signal in 8 bit but the colour differences are subsampled massively and also the difference channels don't occupy anything like 256 shades.

Having said that it's quite remarkable how little colour information is needed to get a decent image back but when pushing that image that colour subsampling does matter.

I think everyone should look at a YUV file and actually *see* what you're getting, then you'll understand the limitations and sacrifices made and why these formats aren't ideal for some post tasks..

cheers
Paul

For what I could understand from this post you're saying that converting from 4K to 2K won't give a 10-bit final result since luma signal is YUV, not RGB. Is this correct?

Trying to understand it further with this new information you're sharing, how is this related to your previous post?

(...)Just taking UHD putting it on a scaled timeline in most NLEs will gain some benefits.

http://inventome.blob.core.windows.net/media/banding.jpg

cheers
Paul

 

[Tom Roper]

Don't forget that these codecs don't store RGB data, they hold YUV which is very different so this idea of shades or red etc,. don't apply. When you ask for RGB from one of these movie formats *something* in that pipeline converts to RGB.

Hi Paul, David Newman specifically described a down conversion from 4k UHD 8 bit 4:2:0 to 1080p 10 bit 4:4:4 RGB. Video can be stored or streamed as YCrCb or RGB. Most often the color space is stored as YUV but it can be either type.