Is BRAW 444, 422...?

I seams that BRAW is debayred to a YCbCr signal.

Is there any difference (444, 422...) in any of BRAWs compressions?

The long answer: https://patents.google.com/patent/US20180367775A1/en?assignee=blackmagic+design&oq=blackmagic+design&sort=new

The short answer: Any Bayer pattern sensor doesn't resolve full color for every pixel anyway.
So, don't care.

The long answer: https://patents.google.com/patent/US20180367775A1/en?assignee=blackmagic+design&oq=blackmagic+design&sort=new

Good read, thanks. I’m probably misunderstanding but it looks like the green channel is debayered to 4:2:0 to create the luminance channel/green, while the R and B are left debayered. In a 4:2:0 component sampling scheme the luma/green is sampled every pixel. Essentially the Y/G channel is 4:0:0 YUV and the color is compressed raw in a YCbCR wrapper......or not.

Good Luck

If h.264 allows me adjust my ISO, WB and go crazy in post, then thats RAW enough for me. What more do i want?

Detail?

Braw compression setting affects the encoder quantization level, not chroma subsampling as far as I know. What the subsampling schema is is difficult to say, raw and pseudoraw sources don't really fit the subsampling numbering logic, but if I had to put a number on raw bayer pattern, it would be 2:1:1. Braw doesn't store raw bayer pattern though...

Detail?

Shh Rick, don't start that up again!

Would that be 2:1:0? Which ever way it is, it's such an elegant way to put it. Looks better than Bayer.

Would that be 2:1:0? Which ever way it is, it's such an elegant way to put it. Looks better than Bayer.

For a row of four pixels bayer pattern has two green (substitutes for luma) samples and one of each chroma samples (actually not really, but for arguments sake lets suppose red and blue sites are shuffled for every second 2x2 block). Next row has also one new chroma sample per component. Thus my 2:1:1 notation. 2:1:0 would mean there is just one sample per chroma component for 4x2 photosites.

Sorry, I was thinking how 4:2:0 was in the old mpeg1 days. The numbering scheme is not great, and you can see different interpretations around of it like, 4 pixel wide presumed 2 rows, 2 samples in first row and and no samples in second row, 4:2:0, where as I talking about one sample of each getting shared between each group of 4 pixels squared on the two rows. So, 2:2:0, as the closest thing, but interpretation of 4:2:0 out there is also two of one of the subsample primaries for each 4 pixel line to more easily convert 4:2:2 I think. But what's the reality of the interpretation of the two systems mpeg1 and mpeg2? Virtually need an expert to be sure.

It's a shame the engineers monitoring here, don't get together and offer an data book answer on stuff like this?

4:2:2 means that chroma samples have half resolution in horizontal direction: for four luma, there is two chroma and on next row also two chroma each. 4:2:0 means that chroma components have half resolution both in horizontal and vertical direction: per row of four luma samples there are two chroma samples per component and no additional samples in next row. This is how subsampling schemas are explained in Poynton's "Digital Video and HD: Algortihms and Interfaces" book.

I quickly found this one:

https://www.projectorcentral.com/chroma ... lained.htm




And yet I read even more interpretations with one colour per line.

Horrifyingly I read talk of the viewer deciding how to blend the single value. I much rather prefer the original scheme used in jpeg, with authentically decided average, which would still be possible to use with Braw, which ever internal interpretation it orientates from.

Hendrik, according to your referenced definition of 4:2:0, should Wayne’s second example be called 4:2:0, not 4:2:2 if I understand this correctly?

Hendrik, according to your referenced definition of 4:2:0, should Wayne’s second example be called 4:2:0, not 4:2:2 if I understand this correctly?

No, those are different kinds of 4:2:0 chroma subsampling. Wikipedia explains it in more detail: https://en.wikipedia.org/wiki/Chroma_subsampling

Thanks for the link, Måns!

Those are both 4:2:0, yes. It is not possible to deduce from chroma subsampled footage, where the area that value describes is, so they are equivalent after conversion. Site location has any relevant meaning only on raw data, before any additional blending, subsampling and whatnot. But I get the idea of that illustration, it tries to tell that you can either drop three samples alltogether and use the value of one or average four samples together, and you get slightly different result. It would be interesting to know which way specific codec encoders do it, averaging makes way more sense though so most probably it is the way most encoders work.

Is it anything to do with the 'massive green shift' or how it is 'ridden with denoising artefacts'? (or maybe even the poor battery life) - who cares if BRAW is 4.4.4, 4.2.2 or 4.2.0 - CDNG went to 11!

I think it's a confluence of a few concepts here.

You can't really think about a sensor as being 4:2:2 simply because the typical arrangement of the filter array on the sensor is greens at twice the ratio of reds and blues.

Many assume INCORRECTLY that because the ratio is the same, that it what's being described the 4:2:2 numbers.

It's not.

One is a way of describing ENCODED video.

Encoded video is what you typically "work" with. It's what ProRes is, it's what most working video formats and codecs are.

Encoded video is in the YCbCr format.

Sensor data IS NOT.

But you don't really get to access the "raw" sensor data. Typically you’re always manipulating it through an SDK and it's being de-mosaiced via an algorithm that interpolated the pixel data from the sensor into a useable form, the encoded video from above.

People always think it's RAW on the media, but you can't really access the true raw data. To view it it HAS to be processed to be viewable.

And it's not ever RAW in the way people think either. Stuff like calibration tables, dead pixels and even some codecs have noise reduction and other hidden image processing in the SDK.

So, just because the BAYER sensor filter array is typically two greens for every blue and red pixel, that's a co-incidence that encoded video is described as 4:2:2

The colour fidelity in the BAYER array is typically much higher than what the ratio 4:2:2 implies.

The extra confusion here is caused by BRAW doing some of the demosaic stage in-camera.

With most other RAW workflows the de-bayer or de-mosaic of the image happens at a later point. BRAW does this step in camera and so yes, in effect the video becomes "encoded" and is in a YCbCr form.

But the colour sampling of that image is depending on other factors.

Typically the efficiently of the demosaic algorithm is usually describes as being 80-90%

So to get a meaningful 444 worth of encoded video at 4K you typically want to have a slightly larger pixel count. The UMP G2 camera is a 4.6K sensor so in theory, that makes a really nice 4K encoded video that has 4:4:4 colour discretion.

So in any Bayer based sensor to get "444" you typically shoot at a higher pixel level on the sensor to super sample down to the target delivery format.

JB

I think no-one argues any of that, raw bayer data does not fit chroma subsampling schema logic, and is not supposed to. But some people just like to argue about apples and oranges

The colour fidelity in the BAYER array is typically much higher than what the ratio 4:2:2 implies.

This caught my eye though, what does "color fidelity" mean in this context exactly? Source that originated at 4:4:4 sampling level and is downsampled to 4:2:2 has more information (2x more) than bayer array data, so I don't get the comparison idea here.

I think no-one argues any of that, raw bayer data does not fit chroma subsampling schema logic, and is not supposed to. But some people just like to argue about apples and oranges

That's exactly what's often mistaken. I see this happen all the time.

People equate 4:2:2 with GGRB pixels.

The colour fidelity in the BAYER array is typically much higher than what the ratio 4:2:2 implies.

This caught my eye though, what does "color fidelity" mean in this context exactly? Source that originated at 4:4:4 sampling level and is downsampled to 4:2:2 has more information (2x more) than bayer array data, so I don't get the comparison idea here.

Simply that once you account for the algorithm processing the GGRB data into encoded video, it's possible to get 4:4:4 from a 4.6K sensor -->4K encoded video.

JB

What's important is the end result.
Put on your german language spectacles and checkout https://www.slashcam.de/4K-Kamera-Vergleich-b34c2c3a8d800ae23ec23827a9c3db0b.html

Makelos ~ Perfect
nahezu perfektes ~ Almost perfect

The de-bayer algorithm used is also important to get the best possible output.

What's important is the end result.

Indeed. Specs be damned.

JB

Question should be- what can we get out of BRAW as final image?
This depends on sensor resolution vs. final image resolution. You can get 4:4:4 or anything below and debayering algorithm plays quite important role here as well.
BRAW is RAW, so YUV subsampling naming should not be really applied to it.
RAW footage is B&W It's debayering processes which "recovers" color information. The more you compress (simplify) original B&W data by compression the more "distortion" you will get in final debayered footage. I assume BRAW equally compressed "pixels" responsible for final RGB colors (even if it doesn't you can't really apply 4:2:2 etc. naming to it). I'm almost sure BRAW compression doesn't skip any lines (pixels).

I think no-one argues any of that, raw bayer data does not fit chroma subsampling schema logic, and is not supposed to. But some people just like to argue about apples and oranges

They ussually like trying to argue with me, after I've told the truth about what an Apple is, which they then change to orange or lemon etc just to keep it up.

However, I'll clear up the confusion here, it's all about PACKING Bayer data into a component envelope, not any misfit. The thread is about what they maybe using in Braw. The suggestion I made was not a spec suggestion, but an exception to the rule suggestion, of a way to say it differently. But I was wrong, I didn't divide, it is more like 2:1:0.

In the old days, three chip more closely matched 4:4:4 and 4:2:2, even 4:2:0 averaging could be possible with matching resolution in each chip as a starting point. It's like arguing that foveon X3 isn't rgb, it's used to directly derive rgb for recording. Both are much more directly accurate than Bayer to 4:4:4.

People always think it's RAW on the media, but you can't really access the true raw data.

Not really true. In some formats (Arri, ProResRAW or any other "open" RAW) SDKs allow you to access RAW pixels (before any meaningful processing which could affect them). This allows you to process it with eg. own amazing debayering instead of one provided by SDKs (Resolve does it for Arri RAW for example allowing you to choose which you prefer- Arri or Resolve own algorithm).
In BRAW you can also recover RAW (after BM "covers" them to avoid RED patent), but you need to do some small processing (Fast CinemaDNG does it). Problem is that actual noise reduction seems to be done in camera before encoding, so this cannot be skipped (which is a shame).

People always think it's RAW on the media, but you can't really access the true raw data.

Not really true. In some formats (Arri, ProResRAW) SDKs allow you to access RAW pixels (before any meaningful processing which could affects them). This allows you to process it with eg. own amazing debayering instead of one provided by SDKs (Resolve does it for Arri RAW for example allowing you to choose which you prefer- Arri or Resolve own algorithm).

But there's another layer that you don't get access to is my point.

The bit that turns off the dead pixels that are in your image for example. There's other under the hood things happening that go on BEFORE it gets to the SDK.

JB

... In some formats (Arri, ProResRAW or any other "open" RAW) SDKs allow you to access RAW pixels (before any meaningful processing which could affects them). This allows you to process it with eg. own amazing debayering instead of one provided by SDKs (Resolve does it for Arri RAW for example allowing you to choose which you prefer- Arri or Resolve own algorithm)...

With the recent ARRIraw frame I was grading a few days ago, I saw that choice of using ARRI or Resolve’s algorithm. Since I didn’t know much about what I was doing, I chose the ARRI routine. Have you tried both and had a better result with Resolve’s routine?

The goal of my exercise (in the Resolve forum) was to maximize the dynamic range in the image which had original highlight data up to 4000 nits on the scope (the log HDR scope from 0 to 10000).

Rick, look for my posts in Dimitry's threads on getting more useful dynamic range, I'd be happy to know how you went please? An BM engineer was quoted in that other Braw cdng thread as saying close to the same thing, but nobody would say whether he said it before or after

People always think it's RAW on the media, but you can't really access the true raw data.

Not really true. In some formats (Arri, ProResRAW or any other "open" RAW) SDKs allow you to access RAW pixels (before any meaningful processing which could affects them). This allows you to process it with eg. own amazing debayering instead of one provided by SDKs (Resolve does it for Arri RAW for example allowing you to choose which you prefer- Arri or Resolve own algorithm).
In BRAW you can also recover RAW (after BM "covers" them to avoid RED patent), but you need to do some small processing (Fast CinemaDNG does it). Problem is that actual noise reduction seems to be done in camera before encoding, so this cannot be skipped (which is a shame).

Andrew, is there any tests to compare hie much better the Arri debayer is at anything?

I don't know about resolution/sharpness, but they should be pretty good.

An BM engineer said that they don't apply a noise filter in cameea, quoted in that Braw cdng thread.

BTW, fast CDNG, tell is more, how fast?

------


Far out, how come nobody has made a credit card sized raw camera. Was waiting for the Sinclair credit card camera over 10 years back, I wonder if he might like to do a "raw" one?

Anyway, back to the internals of raw. I starting to think about doing a post in if you can setup a custom interpretation of format in resolve. Response curve and interpreting a video feed as an embedded Bayer pattern preserved in the matching pixel locations, like braw does presumably. So I could ask somebody if they would like to have a crack at it.

BRAW is RAW, so YUV subsampling naming should not be really applied to it.
RAW footage is B&W It's debayering processes which "recovers" color information. The more you compress (simplify) original B&W data by compression the more "distortion" you will get in final debayered footage. I assume BRAW equally compressed "pixels" responsible for final RGB colors (even if it doesn't you can't really apply 4:2:2 etc. naming to it). I'm almost sure BRAW compression doesn't skip any lines (pixels).

This is a matter of definition of "RAW". It definitely does not fit the narrower definition, because with braw you can't change debayering algorithm after recording, image is not compressed with original sensor color components but derivates (this is where the YUV/luma-chroma topic comes from) and so on. So to pinpoint it again, braw does not compress original RGGB image planes from sensor but luma-chroma derivates calculated from them, and applies DCT compression with variable strength per component (chroma components are way more compressed). Any image is B&W by the way, RGB components are monochromatic.

In BRAW you can also recover RAW (after BM "covers" them to avoid RED patent), but you need to do some small processing (Fast CinemaDNG does it).

How? SDK has no methods for any recovery of original bayer data.

Ask Fast CinemaDNG.
They ‘recover’ original RAW data and said it’s not difficult (of course after denosing and compression).
I assume BRAW gets converted to something aka YUV in a way which is 100% reversible.
Even after debayering you can recover RAW as long as math is reversible and you know it.

I wasn’t talking about BRAW specifically but about ARRI and ProResRAW which are very open formats and give you easy and direct access to RAW data in SDKs.

People always think it's RAW on the media, but you can't really access the true raw data.

Not really true. In some formats (Arri, ProResRAW) SDKs allow you to access RAW pixels (before any meaningful processing which could affects them). This allows you to process it with eg. own amazing debayering instead of one provided by SDKs (Resolve does it for Arri RAW for example allowing you to choose which you prefer- Arri or Resolve own algorithm).

But there's another layer that you don't get access to is my point.

The bit that turns off the dead pixels that are in your image for example. There's other under the hood things happening that go on BEFORE it gets to the SDK.

JB

Yes, but this doesn’t really affect image in a way we would like to eg. turn it off.

... In some formats (Arri, ProResRAW or any other "open" RAW) SDKs allow you to access RAW pixels (before any meaningful processing which could affects them). This allows you to process it with eg. own amazing debayering instead of one provided by SDKs (Resolve does it for Arri RAW for example allowing you to choose which you prefer- Arri or Resolve own algorithm)...

With the recent ARRIraw frame I was grading a few days ago, I saw that choice of using ARRI or Resolve’s algorithm. Since I didn’t know much about what I was doing, I chose the ARRI routine. Have you tried both and had a better result with Resolve’s routine?

The goal of my exercise (in the Resolve forum) was to maximize the dynamic range in the image which had original highlight data up to 4000 nits on the scope (the log HDR scope from 0 to 10000).

They look about identical. Resolve is bit sharper by default but you can match them very easily.
Test it as it’s very easy to do.

An BM engineer said that they don't apply a noise filter in cameea, quoted in that Braw cdng thread.

Where do they do it then, because BRAW is always de-noised?
If recorded files are not pre-denoised then this is good news as with new SDK it could be turned off.
I think their PR says very opposite. Denosing helps a lot with compression so doing it before compression makes sense. Forcing it in SDK instead of letting to do it by user in Resolve makes about no sense (specially if you have 0 control over it).

Ask Fast CinemaDNG.
They ‘recover’ original RAW data and said it’s not difficult (of course after denosing and compression).
I assume BRAW gets converted to something aka YUV in a way which is 100% reversible.
Even after debayering you can recover RAW as long as math is reversible and you know it.

I wasn’t talking about BRAW specifically but about ARRI and ProResRAW which are very open formats and give you easy and direct access to RAW data in SDKs.

I should add this "recovery" to my Nuke braw reader plugin, would be a nice tool to play with But I don't see how this "recovery" could improve anything image data wise, in practical world I would rather add some random noise to braw to get the apparent detail. Or to put it another way, one could deal with sharpening, refocusing, deconvolving etc on RGB data, turning back to bayer pattern has zero benefit at that stage.

An BM engineer said that they don't apply a noise filter in cameea, quoted in that Braw cdng thread.

Where do they do it then, because BRAW is always de-noised?
If recorded files are not pre-denoised then this is good news as with new SDK it could be turned off.
I think their PR says very opposite. Denosing helps a lot with compression so doing it before compression makes sense. Forcing it in SDK instead of letting to do it by user in Resolve makes about no sense (specially if you have 0 control over it).

It’s not denoised.

It is pre filtered. Which has a similar visual effect.

JB

It's de-nosied. No other type of filtering creates those crappy smearing artefacts.
I know what I see and not going to argue about it again. It's nothing nice at all however you call it.

Ask Fast CinemaDNG.
They ‘recover’ original RAW data and said it’s not difficult (of course after denosing and compression).
I assume BRAW gets converted to something aka YUV in a way which is 100% reversible.
Even after debayering you can recover RAW as long as math is reversible and you know it.

I wasn’t talking about BRAW specifically but about ARRI and ProResRAW which are very open formats and give you easy and direct access to RAW data in SDKs.

I should add this "recovery" to my Nuke braw reader plugin, would be a nice tool to play with But I don't see how this "recovery" could improve anything image data wise, in practical world I would rather add some random noise to braw to get the apparent detail. Or to put it another way, one could deal with sharpening, refocusing, deconvolving etc on RGB data, turning back to bayer pattern has zero benefit at that stage.

It just allows to use other RAW processing than one in SDK. Some people convert BRAW to CDNG with Fast CinemaDNG and use Adobe RAW handling as they claim it's better than Resolve. Not sure if it's any useful.

An BM engineer said that they don't apply a noise filter in cameea, quoted in that Braw cdng thread.

Where do they do it then, because BRAW is always de-noised?
If recorded files are not pre-denoised then this is good news as with new SDK it could be turned off.
I think their PR says very opposite. Denosing helps a lot with compression so doing it before compression makes sense. Forcing it in SDK instead of letting to do it by user in Resolve makes about no sense (specially if you have 0 control over it).

It’s not denoised.

It is pre filtered. Which has a similar visual effect.

JB

"Noise reduction" is applied using a "filter kernel".

Not an expert in filtering but sounds like very basic one, so as its results.

It just allows to use other RAW processing than one in SDK. Some people convert BRAW to CDNG with Fast CinemaDNG and use Adobe RAW handling as they claim it's better than Resolve. Not sure if it's any useful.

Sounds pretty futile from data point of view, image manipulation aside. Getting braw to some other software is something that is useful, true that, but if the case is using adobe raw, one could "raw-ify" any video to work on it. Not sure the gains are actually real, not imaginary.

"Noise reduction" is applied using a "filter kernel".

Do you know anything more specific? Most basic box blur is also applied with filter kernel.

"Noise reduction" is applied using a "filter kernel".

Do you know anything more specific? Most basic box blur is also applied with filter kernel.

It's all in the patent application, link above.

Not an expert in filtering but sounds like very basic one, so as its results.

It's basically ditching very high frequency detail, ditching or filtering it to reduce the amount of "true" picture detail to be compressed.

Like a digital OLPF.....

Many found ProRes would often have less of the aliasing and false colour information compared to DNG, simply because encoding to ProRes does something similar.

JB

This sounds like simply throwing high frequency / low value coefficients to trash after DCT transform.

An BM engineer said that they don't apply a noise filter in cameea, quoted in that Braw cdng thread.

Where do they do it then, because BRAW is always de-noised?
If recorded files are not pre-denoised then this is good news as with new SDK it could be turned off.
I think their PR says very opposite. Denosing helps a lot with compression so doing it before compression makes sense. Forcing it in SDK instead of letting to do it by user in Resolve makes about no sense (specially if you have 0 control over it).

I came to conclusion from what was said, before this filtering discussion, that it was likely a bi-product from an aggressive compression process, but how 2D would that be?

Why couldn't they just do a ProRes mode you could bayerfy, even an non bayer cdng in its container file, then you have something that is remotely standard as far as viewers and support goes, with an extra step to get to Bayer if you choose. I mean, Braw gets some people excited from a marketing point of view, but I like something that ticks all the boxes and gets smaller files before I get really excited. Faster processing is then great.

Not an expert in filtering but sounds like very basic one, so as its results.

It's basically ditching very high frequency detail, ditching or filtering it to reduce the amount of "true" picture detail to be compressed.

Like a digital OLPF.....

Many found ProRes would often have less of the aliasing and false colour information compared to DNG, simply because encoding to ProRes does something similar.

JB

Yes, this is a "positive" effect of mild compression.
I don't like how it's implemented in BRAW at all. Way too strong and no way of controlling it.

This thread is an awesome read for techno enthusiast but...

on the practical side for the laymen/women out there, will the end result comparing BRAW, 444, 422, and 420 be noticeable on the screen or monitor? I'm not sure anyone beside "pixel peepers" can differentiate. Right/Wrong? Isn't that all that matter at the end of the day?

I'd not go down to 4:2:0, but in many cases 4:2:2 can be good enough.

You can't compare it as RAW is not for viewing. RAW needs to be debayered to be a meaningful image (otherwise it's just grey pixels). Answered been already given that good debayering will have eg. 80% efficiency, so you will get (badly saying) 80% of 4:4:4 (if sensor resolution=output resolution). Add a bit of oversampling and you will get full 4:4:4 worth of data image. This applies to any RAW, as BRAW is nothing specific compared to other RAW formats at the end.
People are too much exited about BRAW- its nothing that special at all compared to the RAW formats. Its based on same base principle. Rest are just details.