Is BRAW 444, 422...?

The place for questions about shooting with Blackmagic Cameras.
  • Author
  • Message
Offline

Adriano Oliveira

  • Posts: 73
  • Joined: Fri Nov 01, 2013 12:03 am

Is BRAW 444, 422...?

PostThu Jun 04, 2020 8:21 pm

I seams that BRAW is debayred to a YCbCr signal.

Is there any difference (444, 422...) in any of BRAWs compressions?
-----
Adriano Oliveira
Windows 10
GTX 1060 6GB
Offline

MishaEngel

  • Posts: 1367
  • Joined: Wed Aug 29, 2018 12:18 am
  • Real Name: Misha Engel

Re: Is BRAW 444, 422...?

Online

Uli Plank

  • Posts: 7433
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: Is BRAW 444, 422...?

PostFri Jun 05, 2020 3:33 pm

The short answer: Any Bayer pattern sensor doesn't resolve full color for every pixel anyway.
So, don't care.
Resolve Studio 16.2.2 and Fusion Studio under MacOS Mojave 10.14.6
iMac 2017 Radeon Pro 580 8 GB VRAM and 32 GB RAM
Mac mini 16 GB RAM plus eGFX Breakway Radeon RX 580
Offline

Howard Roll

  • Posts: 863
  • Joined: Fri Jun 03, 2016 7:50 am

Re: Is BRAW 444, 422...?

PostSat Jun 06, 2020 1:59 pm



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
Offline
User avatar

Akpe Ododoru

  • Posts: 223
  • Joined: Sun Nov 03, 2013 3:44 am
  • Location: London

Re: Is BRAW 444, 422...?

PostSat Jun 06, 2020 4:17 pm

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?
Offline
User avatar

rick.lang

  • Posts: 13790
  • Joined: Wed Aug 22, 2012 5:41 pm
  • Location: Victoria BC Canada

Re: Is BRAW 444, 422...?

PostSat Jun 06, 2020 6:01 pm

Detail?
Rick Lang
Offline

Hendrik Proosa

  • Posts: 1134
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Is BRAW 444, 422...?

PostSat Jun 06, 2020 6:25 pm

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...
I do stuff.
Offline

Wayne Steven

  • Posts: 3233
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: Is BRAW 444, 422...?

PostSat Jun 06, 2020 7:32 pm

rick.lang wrote:Detail?

Shh Rick, don't start that up again! :)
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Wayne Steven

  • Posts: 3233
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: Is BRAW 444, 422...?

PostSat Jun 06, 2020 7:38 pm

Would that be 2:1:0? Which ever way it is, it's such an elegant way to put it. Looks better than Bayer.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Hendrik Proosa

  • Posts: 1134
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Is BRAW 444, 422...?

PostSat Jun 06, 2020 8:37 pm

Wayne Steven wrote: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.
I do stuff.
Offline

Wayne Steven

  • Posts: 3233
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 5:25 am

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?
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Hendrik Proosa

  • Posts: 1134
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 7:41 am

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 do stuff.
Offline

Wayne Steven

  • Posts: 3233
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 10:26 am

I quickly found this one:

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

Image
Image

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.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline
User avatar

rick.lang

  • Posts: 13790
  • Joined: Wed Aug 22, 2012 5:41 pm
  • Location: Victoria BC Canada

Is BRAW 444, 422...?

PostSun Jun 07, 2020 12:23 pm

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?
Rick Lang
Offline

Måns Winberg

  • Posts: 70
  • Joined: Tue Aug 13, 2013 1:32 pm
  • Location: Lund, Sweden

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 1:13 pm

rick.lang wrote: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
Offline
User avatar

rick.lang

  • Posts: 13790
  • Joined: Wed Aug 22, 2012 5:41 pm
  • Location: Victoria BC Canada

Is BRAW 444, 422...?

PostSun Jun 07, 2020 3:41 pm

Thanks for the link, Måns!
Rick Lang
Offline

Hendrik Proosa

  • Posts: 1134
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 4:40 pm

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.
I do stuff.
Offline

John Griffin

  • Posts: 693
  • Joined: Sun Aug 23, 2015 4:18 pm

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 5:48 pm

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!
Which is what I said, and even though this is what I was talking about, there is not too much comparison between your actions at the moment compared to some not around here.
Offline

John Brawley

  • Posts: 2591
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Ontario Canada

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 6:57 pm

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
John Brawley
Cinematographer
Currently - Ontario Canada
Offline

Hendrik Proosa

  • Posts: 1134
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 7:48 pm

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 8-)

John Brawley wrote: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 do stuff.
Offline

John Brawley

  • Posts: 2591
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Ontario Canada

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 7:53 pm

Hendrik Proosa wrote: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 8-)


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

People equate 4:2:2 with GGRB pixels.


Hendrik Proosa wrote:
John Brawley wrote: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
John Brawley
Cinematographer
Currently - Ontario Canada
Offline

MishaEngel

  • Posts: 1367
  • Joined: Wed Aug 29, 2018 12:18 am
  • Real Name: Misha Engel

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 8:55 pm

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.
Offline

John Brawley

  • Posts: 2591
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Ontario Canada

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 9:12 pm

MishaEngel wrote:What's important is the end result.


Indeed. Specs be damned.

JB
John Brawley
Cinematographer
Currently - Ontario Canada
Offline

Andrew Kolakowski

  • Posts: 6691
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 9:24 pm

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 :D 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).
Offline

Wayne Steven

  • Posts: 3233
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 9:44 pm

Hendrik Proosa wrote: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 8-)


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.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Andrew Kolakowski

  • Posts: 6691
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 9:55 pm

John Brawley wrote:
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).
Last edited by Andrew Kolakowski on Mon Jun 08, 2020 8:44 am, edited 1 time in total.
Offline

John Brawley

  • Posts: 2591
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Ontario Canada

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 10:10 pm

Andrew Kolakowski wrote:
John Brawley wrote:
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
John Brawley
Cinematographer
Currently - Ontario Canada
Offline
User avatar

rick.lang

  • Posts: 13790
  • Joined: Wed Aug 22, 2012 5:41 pm
  • Location: Victoria BC Canada

Is BRAW 444, 422...?

PostSun Jun 07, 2020 10:10 pm

Andrew Kolakowski wrote:... 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 Lang
Offline

Wayne Steven

  • Posts: 3233
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 10:44 pm

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
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Wayne Steven

  • Posts: 3233
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: Is BRAW 444, 422...?

PostSun Jun 07, 2020 10:49 pm

Andrew Kolakowski wrote:
John Brawley wrote:
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. :)
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Hendrik Proosa

  • Posts: 1134
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 6:51 am

Andrew Kolakowski wrote:BRAW is RAW, so YUV subsampling naming should not be really applied to it.
RAW footage is B&W :D 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.

Andrew Kolakowski wrote: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.
I do stuff.
Offline

Andrew Kolakowski

  • Posts: 6691
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 8:19 am

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.
Offline

Andrew Kolakowski

  • Posts: 6691
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 8:22 am

John Brawley wrote:
Andrew Kolakowski wrote:
John Brawley wrote:
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.
Offline

Andrew Kolakowski

  • Posts: 6691
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 8:25 am

rick.lang wrote:
Andrew Kolakowski wrote:... 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.
Offline

Andrew Kolakowski

  • Posts: 6691
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 8:32 am

Wayne Steven wrote: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).
Offline

Hendrik Proosa

  • Posts: 1134
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 9:32 am

Andrew Kolakowski wrote: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 :D 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.
I do stuff.
Offline

John Brawley

  • Posts: 2591
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Ontario Canada

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 12:46 pm

Andrew Kolakowski wrote:
Wayne Steven wrote: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
John Brawley
Cinematographer
Currently - Ontario Canada
Offline

Andrew Kolakowski

  • Posts: 6691
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 1:39 pm

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.
Offline

Andrew Kolakowski

  • Posts: 6691
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 1:42 pm

Hendrik Proosa wrote:
Andrew Kolakowski wrote: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 :D 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.
Offline

Måns Winberg

  • Posts: 70
  • Joined: Tue Aug 13, 2013 1:32 pm
  • Location: Lund, Sweden

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 2:08 pm

John Brawley wrote:
Andrew Kolakowski wrote:
Wayne Steven wrote: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".
Offline

Andrew Kolakowski

  • Posts: 6691
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 2:19 pm

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

Hendrik Proosa

  • Posts: 1134
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 2:25 pm

Andrew Kolakowski wrote: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.

Måns Winberg wrote:"Noise reduction" is applied using a "filter kernel".

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

Måns Winberg

  • Posts: 70
  • Joined: Tue Aug 13, 2013 1:32 pm
  • Location: Lund, Sweden

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 2:46 pm

Måns Winberg wrote:"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.
Offline

John Brawley

  • Posts: 2591
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Ontario Canada

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 2:55 pm

Andrew Kolakowski wrote: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
John Brawley
Cinematographer
Currently - Ontario Canada
Offline

Hendrik Proosa

  • Posts: 1134
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 3:02 pm

This sounds like simply throwing high frequency / low value coefficients to trash after DCT transform.
Last edited by Hendrik Proosa on Mon Jun 08, 2020 3:03 pm, edited 1 time in total.
I do stuff.
Offline

Wayne Steven

  • Posts: 3233
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 3:03 pm

Andrew Kolakowski wrote:
Wayne Steven wrote: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.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Andrew Kolakowski

  • Posts: 6691
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 3:03 pm

John Brawley wrote:
Andrew Kolakowski wrote: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.
Offline

Ellory Yu

  • Posts: 1634
  • Joined: Wed Jul 30, 2014 5:25 pm

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 3:04 pm

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?
Last edited by Ellory Yu on Mon Jun 08, 2020 3:09 pm, edited 2 times in total.
MSI Raider X99 MB / Intel i7 5280 6 core CPU / 2 x AMD R9 390X 8Gb GPU / 64Gb 3200 RAM / Decklink 4K Mini Monitor / 240Gb SSD OS Drive / 2Tb RAID 0 SSD Cache/Scratch Drive / 14Tb 7200rpm HDD Data Drive / Win 10 Pro 64bit / Resolve 16.2.1
Online

Uli Plank

  • Posts: 7433
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 3:06 pm

I'd not go down to 4:2:0, but in many cases 4:2:2 can be good enough.
Resolve Studio 16.2.2 and Fusion Studio under MacOS Mojave 10.14.6
iMac 2017 Radeon Pro 580 8 GB VRAM and 32 GB RAM
Mac mini 16 GB RAM plus eGFX Breakway Radeon RX 580
Offline

Andrew Kolakowski

  • Posts: 6691
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Is BRAW 444, 422...?

PostMon Jun 08, 2020 3:12 pm

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.
Next

Return to Cinematography

Who is online

Users browsing this forum: Google Feedfetcher, Rakesh Malik and 25 guests