BRAW is actually Macro-Blocking RAW

Dmitry Shijan wrote:
The main lesson - you should never expose and shoot things in the way like this with digital sensors.

100% agree.

I disagree.
It’s RAW after all. The only thing you should take care of is to make sure nothing gets clipped. Beyond that you can do whatever you want in post. See attached pic.

BRAW_settings.jpg

First one is the setting from Jamie. The other three are complete different settings. Same result, no person will be able to tell the difference without scopes.
If there is a reason for the “macro-blocking” I expect it to be the BRAW compression and nothing else. The OP mentioned Q5, so apperently 5:1 isn’t good enough to go extreme on sky footage.

Yes you can go less extreme than the OP and you will see no artifacts what so ever …however I can go way more extreme with my BMCC 2.5K cDNG footage and no "artifacts" will show.

But it's not 'RAW' - it's been processed in camera in various ways which mean you can't treat it like RAW from a stills camera.

Sony is compressing RAW in some stills cameras too.

You can do whatever you want in post if you have 32 bit source, or at least true 16 bit data from sensor. 10 and 12 bits sources have it's own limits. And it is not depends if you operate with ProRes or with RAW.
ISO and Expose in the RAW tab is the same thing. Both ISO and Expose are just artificial human friendly names to represent gain adjustment in linear gamma (and it is not depends if you operate with ProRes or with RAW). For example changing ISO from 400 to 800 is the same as add one stop of Expose, and it is also the same as add Gain value 2 in linear gamma.
Also color information is always related somehow to tonal information and saturation response is not equal due all tonal range. Colors may be muted around near bright or overexposed areas, so you can not recover reach colors from last brightest bits. Digital sensors don't like clipping.
Artifacts mostly starts to appear when you adjust image outside RAW tab, like adjust Contrast, use extreme curves add LUTs...
You may see some further info and over/under expose tests here: viewtopic.php?f=21&t=65149#p537852

But it's not 'RAW' - it's been processed in camera in various ways which mean you can't treat it like RAW from a stills camera.

It's not a stills camera, but OK, BlackMagic RAW then which I just treated like RAW and which reacted like RAW, compressed RAW that is, hence you can break it. If you want unlimited control, get into graphics.

Sony is compressing RAW in some stills cameras too.

That's just data compression and not image processing.

ISO and Expose in the RAW tab is the same thing. Both ISO and Expose are just artificial human friendly names to represent gain adjustment in linear gamma (and it is not depends if you operate with ProRes or with RAW). For example changing ISO from 400 to 800 is the same as add one stop of Expose, and it is also the same as add Gain value 2 in linear gamma.
Also color information is always related somehow to tonal information and saturation response is not equal due all tonal range. Colors may be muted around near bright or overexposed areas, so you can not recover reach colors from last brightest bits. Digital sensors don't like clipping.
Artifacts mostly starts to appear when you adjust image outside RAW tab, like adjust Contrast, use extreme curves add LUTs...
You may see some further info and over/under expose tests here: viewtopic.php?f=21&t=65149#p537852

ISO on a BM camera is just an adjustment to the mid part of th response curve - it does not change exposure as has been demonstrated many times. With BRAW it's just a tag in the file but it's baked in in ProRes. With true RAW ( linear) you can move colour values up and down the response curve and as long as you don't clip or hit noise the absolute values should remain the same. Obviously with ProRes this can't happen but I'm not sure if BRAW is linear or some form of LOG?

But it's not 'RAW' - it's been processed in camera in various ways which mean you can't treat it like RAW from a stills camera.

It's not a stills camera, but OK, BlackMagic RAW then which I just treated like RAW and which reacted like RAW, compressed RAW that is, hence you can break it. If you want unlimited control, get into graphics.

I can push my Sony compressed RAW files much further than BRAW. They are RGB without any demosacising for a start and AFAIK BRAW is YCBCR with partial demosacising.

I can push my Sony compressed RAW files much further than BRAW.

That's not some unique deficiency of BRAW. The exact same thing is true for ARRIRAW and .r3d
The processing on a digital motion camera has to work consistently with a huge amount of bandwidth going through. Stills cameras can get away with higher quality signal processing of the sensor data because they only have to shoot multiple frames in short bursts. A digital motion picture camera has to maintain the data rate indefinitely.

I can push my Sony compressed RAW files much further than BRAW.

That's not some unique deficiency of BRAW. The exact same thing is true for ARRIRAW and .r3d
The processing on a digital motion camera has to work consistently with a huge amount of bandwidth going through. Stills cameras can get away with higher quality signal processing of the sensor data because they only have to shoot multiple frames in short bursts. A digital motion picture camera has to maintain the data rate indefinitely.

True RAW would be impossible on a cine camera due to the data storage overhead. It has to be reduced in-camera not just by compressing the data but also partially processing the image. Stop calling it RAW - it's not!

[CaptainHook]

ISO on a BM camera is just an adjustment to the mid part of th response curve - it does not change exposure as has been demonstrated many times. With BRAW it's just a tag in the file but it's baked in in ProRes. With true RAW ( linear) you can move colour values up and down the response curve and as long as you don't clip or hit noise the absolute values should remain the same. Obviously with ProRes this can't happen but I'm not sure if BRAW is linear or some form of LOG?

ISO for most of our cameras are different log curves with middle grey and the white point shifted, yes. Exposure is done in linear though as a multiplier (as it must be) and is represented to the user as "stops".

Our DNG's are not encoded as linear either, they are stored with a log type curve for efficiency (like ARRIRAW etc) but contain linearisation tables so that processing and RAW adjustments can be done in linear sensor space. Blackmagic RAW does the same thing with storing in non-linear but much of the processing in linear (changing white balance and exposure needs to be done in linear so this is self evident). Blackmagic RAW also doesn't clip away any of the sensor range/data (that incidentally DOES happen with some other 'RAW' codecs in some other cameras out there).

Yes you can get some compression artefacts when pushed, but they are less than what we were getting with 3:1 and 4:1 with cDNG shooting the same scenes at even higher ratios (the above example of the sky with DNG one such example). We tested 5:1 with cDNG in our cameras, it was IMHO (and others) not useable but I would happily use 20:1 -> 30:1 on some scenes with Blackmagic RAW (it can get that high and higher with Q5).

For reference, the blue sky Blackmagic RAW clip posted in this thread ranges from 19:1 (first frame) and the last frame of the clip is 36.5:1. I'll write that again:

This clip ranges from 19:1 -> 36:1.

Yes, we are aware of requests for a Q3 'middle' option that limits the upper range of compression etc. But in terms of the quality of this clip at those ratios... well... I think others have shown just how well it is actually holding up (imagine it at even 12:1). Again, look at the cDNG example in this thread at 4:1 and what happened in the sky.

We are otherwise always looking at ways to improve everything we are doing and planning to do and we do read and take on all feedback like in this thread and elsewhere.

Thanks.

Hi Capt. I'm surprised, as the upper bit depths you use, match the sensor bit depths. How do you use log in this situation, I'm braw?

On the thing of taking feedback. 16 bit sensor and sensor data please? A Q-Ultra mode practically lossless, temporal noise reduction only, tight pixels please, using better compression like the latest jpeg of the now free cineform? . Cdng is not needed, only what a lossless cdng mode could do. People complain about colour artifacts, but that is how bayer sees, and what people can try to process out.

Any option to tone down the spatial stuff? The spatial (noise reduction) where is that happening? Is it the demosaicing, the dct, quantization, or explicit noise reduction? These things would be useful to know to orientate discussions here?

Oh, and $1000 8k p50 12 bit+ micro please with full wifi recording and mobile control (4k-8k with high fill ratio vertical colour filtering sensor).

Thanks for the work Capt.

ISO and Expose in the RAW tab is the same thing. Both ISO and Expose are just artificial human friendly names to represent gain adjustment in linear gamma (and it is not depends if you operate with ProRes or with RAW). For example changing ISO from 400 to 800 is the same as add one stop of Expose, and it is also the same as add Gain value 2 in linear gamma.
Also color information is always related somehow to tonal information and saturation response is not equal due all tonal range. Colors may be muted around near bright or overexposed areas, so you can not recover reach colors from last brightest bits. Digital sensors don't like clipping.
Artifacts mostly starts to appear when you adjust image outside RAW tab, like adjust Contrast, use extreme curves add LUTs...
You may see some further info and over/under expose tests here: viewtopic.php?f=21&t=65149#p537852

ISO on a BM camera is just an adjustment to the mid part of th response curve - it does not change exposure as has been demonstrated many times. With BRAW it's just a tag in the file but it's baked in in ProRes. With true RAW ( linear) you can move colour values up and down the response curve and as long as you don't clip or hit noise the absolute values should remain the same. Obviously with ProRes this can't happen but I'm not sure if BRAW is linear or some form of LOG?

You can adjust Expose for ProRes footage if it was shoot with native ISO. Use Gain in Linear Gamma Node (Right click on the Node and set Gamma to Linear. Adjust Gain wheel). Also you need to set timeline in project settings to Log.
In same way you can adjust Expose for RAW files in the Node outside RAW tab.
Gain in linear gamma corresponds to Expose F-Stops in RAW tab like this:
linear gain 2 = expose 1
linear gain 4 = expose 2
linear gain 8 = expose 3
linear gain 16 = expose 4
and so on...

See more useful step by step workflow tips here viewtopic.php?f=21&t=65149#p537852

ISO and Expose in the RAW tab is the same thing. Both ISO and Expose are just artificial human friendly names to represent gain adjustment in linear gamma (and it is not depends if you operate with ProRes or with RAW). For example changing ISO from 400 to 800 is the same as add one stop of Expose, and it is also the same as add Gain value 2 in linear gamma.
Also color information is always related somehow to tonal information and saturation response is not equal due all tonal range. Colors may be muted around near bright or overexposed areas, so you can not recover reach colors from last brightest bits. Digital sensors don't like clipping.
Artifacts mostly starts to appear when you adjust image outside RAW tab, like adjust Contrast, use extreme curves add LUTs...
You may see some further info and over/under expose tests here: viewtopic.php?f=21&t=65149#p537852

ISO on a BM camera is just an adjustment to the mid part of th response curve - it does not change exposure as has been demonstrated many times. With BRAW it's just a tag in the file but it's baked in in ProRes. With true RAW ( linear) you can move colour values up and down the response curve and as long as you don't clip or hit noise the absolute values should remain the same. Obviously with ProRes this can't happen but I'm not sure if BRAW is linear or some form of LOG?

You can adjust Expose for ProRes footage if it was shoot with native ISO. Use Gain in Linear Gamma Node (Right click on the Node and set Gamma to Linear. Adjust Gain wheel). Also you need to set timeline in project settings to Log.
In same way you can adjust Expose for RAW files in the Node outside RAW tab.
Gain in linear gamma corresponds to Expose F-Stops in RAW tab like this:
linear gain 2 = expose 1
linear gain 4 = expose 2
linear gain 8 = expose 3
linear gain 16 = expose 4
and so on...

See more useful step by step workflow tips here viewtopic.php?f=21&t=65149#p537852

Obviously you can adjust the 'exposure' but as you have a baked in response curve and only 10 bits you will run the risk of artefacts if you don't try to get the exposure as near as possible in camera.

Obviously you can adjust the 'exposure' but as you have a baked in response curve and only 10 bits

There are 12 bit flavours of ProRes too. I find 444 ProRes is also very robust in the grade.

JB

Obviously you can adjust the 'exposure' but as you have a baked in response curve and only 10 bits

There are 12 bit flavours of ProRes too. I find 444 ProRes is also very robust in the grade.

JB

Yes it is but it's not an option on the P4k/P6k.

This clip ranges from 19:1 -> 36:1.

I had no idea that the compression could go up that high. What are we even talking anout here. Still, I'm very happy with my old bmcc, eventhough I understand the reasining some might prefer BRAW. I personally like my RAW raw

Yes it is but it's not an option on the P4k/P6k.

But the point stands as per Dimitry with regards to bit depth and ProRes.

I'm still trying to work out the basic issue here...

A compressed RAW codec has artefacts...artefacts of compression. Compression in this case at a freaking high number.

So does the DNG codec everyone lovingly remembers as being faultless. Nevermind that it never looked right almost no matter what app you opened it with, was unwieldy when shot uncompressed by even the most maxed out systems and made media options almost impossible for future cameras requiring more K's.

As Hook explained the compression ratio in the BRAW example is really high. Even REDCODE doesn't typically do those kinds of numbers.

I'm sure they've well and truly seen and heard the complaints and I guarantee they knew about the possible shortcomings and they've made a CHOICE to balance those demands. I mean look at the compression ratio mentioned.

With feedback like what's in this thread I'm sure they'll be looking at it in the next development cycle.

But think about it. A brand new codec. A young codec. And already it's gaining wide acceptance and bedding in with the major post players. ProRes RAW launched around the same time and it seems to be going nowhere in the same time frame.

By all means go try and break the codec but I don't know many scenarios where I'm trying to push a grade around so much as exemplified in these scenarios that these kinds of issues show up.

I don't think the macro blocking / DCT style compression artefacts will be going away in any codec until a certain other camera company chooses not to come after those that try to innovate in this field, or you pay for their IP.

JB

Enough datarate and care, but you don't need to use dct etc. Most TV here is SD too, but that doesn't mean one can't do more either. There is some good suggestion, Q3, limiting maximum compression, making more use of lower compression, or pretty much anything I suggest. The situation is just a little refinement, some options, and a higher end mode that maybe constant quality, but allows you to grade however, and you're done. With adaptive data rate, I imagine you have to be more careful then in consumer adaptive, as that does not have to be completely robust.

I think with prores, Apple moves for it's own reasons. Wanting a non-core product Bayer form of codec with licensing issues might be a reason to move slower then a camera company with big interest in pushing an relatively unencumbered codec out that will sell core product. Personally, seeing braw, prores raw probably doesn't seem such a leap without Bayer, which they are now going after. The cineform Bayer license was $20 for individuals, so for 100k of pricey cameras, a bulk discount would make it look desirable. Even without Bayer, free cineform makes braw look not really that much. Lots of benefits with cineform, if you can customise it to GPU processing. Cineform is probably the lighter faster option, of only it had the processing hardware support that JPEG standards get. It is such a shame. If only BM had bought out cineform when gopro was up for sale.

When I came across blue sky breaking up and started a thread about it I saw a similar artefact in cDNG so I'm not sure it's entirely a compression problem. For me it's no longer a practical problem as I don't now treat BRAW as RAW and now we have BM confirming it's a 'LOG type curve' and not linear I suggest everyone else does. Again it's a great codec - but it's not 'RAW'.....(and that's not a criticism)

[CaptainHook]

I don't now treat BRAW as RAW and now we have BM confirming it's a 'LOG type curve' and not linear I suggest everyone else does. Again it's a great codec - but it's not 'RAW'.....(and that's not a criticism)

Then our cDNG should be treated the same then and not considered 'RAW" by that standard. And the same for ARRIRAW, etc

but it's not 'RAW'

This is a semantic issue. In video land, people understand RAW to mean some undebayered format that lets you adjust exposure/WB/tint and such after the fact, without doing it by manually correcting the image. It hasn't been practical for a while to record totally uncompressed, and that ship sailed (at least for now) when we entered the 4K era. Maybe in a few years we'll be using NVMe SSD mags and have the option for uncompressed again, but I'm not holding my breath.

[CaptainHook]

I saw a similar artefact in cDNG so I'm not sure it's entirely a compression problem.

I missed this first time, but it is compression. Compare lossless to 4:1 on the same scenes with cDNG.

now we have BM confirming it's a 'LOG type curve' and not linear

By the way this is not a 'revelation' - it's been in our marketing on the website for a year now and it was widely known before that for cDNG we used a 12bit log encoding in DNGs (DNG supports linearisation tables for log/non-linear encoded RAW for a reason - it's common). I knew it well before I started working for BMD 5 years ago.

Well, I still asked in what way. If you have a 12 bit sensor output going to a 12 bit file, how is the log getting used Captain Hook?

but it's not 'RAW'

This is a semantic issue. In video land, people understand RAW to mean some undebayered format that lets you adjust exposure/WB/tint and such after the fact, without doing it by manually correcting the image. It hasn't been practical for a while to record totally uncompressed, and that ship sailed (at least for now) when we entered the 4K era. Maybe in a few years we'll be using NVMe SSD mags and have the option for uncompressed again, but I'm not holding my breath.

Raw is strictly the original values to play with, wherever the original 4:4:4, Bayer etc. I would even regard demosaiced 4:2:2 as a sort of Light Raw, as well as temporal denoise, as they are a reconstruction of the original pixel data, which is more an extended or restored Raw (these are just arbitrary descriptive names for performance or function). So, the question is, what is Braw. I mean, if the semi debayered video maintains the original sensor primary values at their pixel array positions that is raw like, maybe hidden or obscured. Baked in adjustments would be less Raw. But, spatial smoothing over of noise/detail, is not Raw.

but it's not 'RAW'

This is a semantic issue.

Exactly. This and other threads would not exist if it was called 'BRES'
I think we are done here? - I'm off to shoot some non linear 12 bit partialy debayered YCBCR video on my P4k and some RAW stills on my new Sony A7r IV.

Nope! Raw has actual structural meaning, unless you want h264 9mb/s 4kp60 4:2:2 8 bit to be considered "Raw" one day. It is enough we refer to semi Raw derived formats as still Raw.

I think the issue goes further. There are things going on inside that BM avoids answering. You just mentioned one of them.

If anybody can confirm to me the pocket is actually filming 16 bit linear and producing 12 bit log from that. I would be most happy.

I'm off to shoot some non linear 12 bit partialy debayered YCBCR video on my P4k and some RAW stills on my new Sony A7r IV.

John, which raw video camera does meet your definition of RAW ?

Cause if you want greater than 12 bit linear uncompressed RAW I don’t think you have any options.

Arri is the same as BMD (12 bit log / 16 bit lin)

Sony is 16bit LIN raw but compressed on their higher end cameras and more so in their lessor models.

R3D is secret, but is probably 16 bit lin and is certainly compressed.

JB

Interesting question John.

LOL. Sensors that can capture and process image in 16 bit are very rare. Those mostly single pixel line array CCDs from some high end film photo scanners. They are extremely slow and produce a lot of heat and consumes huge amount of power. 12-bit represent 4096 different numbers,
16-bit represent 65536 different numbers. Huge amount of data to process. Not sure if CMOS 16 bit sensors ever exists.
12 bit in single gain mode is more than enough as well as 2x11 bit combined in dual gain mode. Sensor bit depth capture and internal processing is hardware limit, it is not the thing that BM developers can adjust. In real life going from 12 to 14 bit sensor internal processing will not brings a lot of additional quality. Sensor dynamic range is way more important than 16 bit internal processing.

There is a dude on Youtube who makes a lot of side by side tests and shares links to original files in comments. So he compare P6K vs some modern RED camera. When i open both BRAW and R3D files in original 1:1 size in Resolve i was shocked that BRAW footage has almost no aliasing artifacts and same time RED footage produced a lot of aliasing artifacts. So BRAW pre-processing is not a bad idea. It just needs some improvement for compression. And also it need to allow user to adjust noise reduction strength. Also it need to allow to switch pre-processing off for situations when you use OLPF filter and no need software anti-aliasing processing. Same option may be usable for ProRes.

Even BRAW is profiting from an OLPF.

Also noise reduction is sort of thing that should be done at most early stages before Expose (ISO) adjustment. If you apply NR to highly compressed file it may produce artifacts.

Good workflow examples:
Debayer->NR->High Compression->Grade in Resolve
Debayer->Uncompressed->NR in Resolve->Grade in Resolve

Bad workflow example:
Debayer->High Compression->NR in Resolve->Grade in Resolve

Also noise reduction is sort of thing that should be done at most early stages before Expose (ISO) adjustment. If you apply NR to highly compressed file it may produce artifacts.

Good workflow examples:
Debayer->NR->High Compression->Grade in Resolve
Debayer->Uncompressed->NR in Resolve->Grade in Resolve

Bad workflow example:
Debayer->High Compression->NR in Resolve->Grade in Resolve

That’s a great tip Dmitry! So you’d put NR on the first node?

I'm off to shoot some non linear 12 bit partialy debayered YCBCR video on my P4k and some RAW stills on my new Sony A7r IV.

John, which raw video camera does meet your definition of RAW ?

Cause if you want greater than 12 bit linear uncompressed RAW I don’t think you have any options.

Arri is the same as BMD (12 bit log / 16 bit lin)

Sony is 16bit LIN raw but compressed on their higher end cameras and more so in their lessor models.

R3D is secret, but is probably 16 bit lin and is certainly compressed.

JB

No video camera (maybe Magic Lantern?) does RAW AFAIK. I'm not looking for a RAW shooting video camera and am very happy with BRAW. I'm just questioning why it's called RAW.

Also noise reduction is sort of thing that should be done at most early stages before Expose (ISO) adjustment. If you apply NR to highly compressed file it may produce artifacts.

Good workflow examples:
Debayer->NR->High Compression->Grade in Resolve
Debayer->Uncompressed->NR in Resolve->Grade in Resolve

Bad workflow example:
Debayer->High Compression->NR in Resolve->Grade in Resolve

That’s a great tip Dmitry! So you’d put NR on the first node?

Yes, do NR on the first node. Do it before expose (ISO) adjust. Works for RAW as well as for ProRes, if it source footage was shoot at native ISO:
WB in RAW tab->NR->Expose adjust (Gain in linear gamma node)->All other grade. See step by step workflow in details here: viewtopic.php?f=21&t=65149&p=537852#p537852

Yes, do NR on the first node. Do it before expose (ISO) adjust. Works for RAW as well as for ProRes, if it source footage was shoot at native ISO:

There are mixed opinions on this. For example, colorist Jason Bowdach has an in-depth tutorial on noise reduction as part of his "Problem Solving in DaVinci Resolve" tutorial from Ripple Training, and he recommends adding noise reduction as a node after color correction because color correction itself can exacerbate noise. This is somewhat contradicted in another Ripple Training tutorial (Advanced Color Grading in DaVinci Resolve), where the instructor Mark Spencer recommends using the noise reduction as the first node so that NR is applied to the original RGB signal. He says that can result in better noise reduction but he notes that it can also affect the quality of later qualifications so sometimes it's good to try it both ways: as the first node or as a later node after color grading.

I use it as the first node myself but I suppose it's worth experimenting to see what looks best.

No video camera (maybe Magic Lantern?) does RAW AFAIK. I'm not looking for a RAW shooting video camera and am very happy with BRAW. I'm just questioning why it's called RAW.

12bit log raw can be much better than the 14bit linear raw you find it stills cameras. This is an extremely ignorant comment and shows you really don't understand what you're talking about.

No video camera (maybe Magic Lantern?) does RAW AFAIK. I'm not looking for a RAW shooting video camera and am very happy with BRAW. I'm just questioning why it's called RAW.

12bit log raw can be much better than the 14bit linear raw you find it stills cameras. This is an extremely ignorant comment and shows you really don't understand what you're talking about.

Please explain and free me from my ignorance

LOL. Sensors that can capture and process image in 16 bit are very rare. Those mostly single pixel line array CCDs from some high end film photo scanners. They are extremely slow and produce a lot of heat and consumes huge amount of power. 12-bit represent 4096 different numbers,
16-bit represent 65536 different numbers. Huge amount of data to process. Not sure if CMOS 16 bit sensors ever exists.
12 bit in single gain mode is more than enough as well as 2x11 bit combined in dual gain mode. Sensor bit depth capture and internal processing is hardware limit, it is not the thing that BM developers can adjust. In real life going from 12 to 14 bit sensor internal processing will not brings a lot of additional quality. Sensor dynamic range is way more important than 16 bit internal processing.

There is a dude on Youtube who makes a lot of side by side tests and shares links to original files in comments. So he compare P6K vs some modern RED camera. When i open both BRAW and R3D files in original 1:1 size in Resolve i was shocked that BRAW footage has almost no aliasing artifacts and same time RED footage produced a lot of aliasing artifacts. So BRAW pre-processing is not a bad idea. It just needs some improvement for compression. And also it need to allow user to adjust noise reduction strength. Also it need to allow to switch pre-processing off for situations when you use OLPF filter and no need software anti-aliasing processing. Same option may be usable for ProRes.

Thanks Dimitry for the Braw recommendations. That is what I have been saying.

There are various 14 bit mode Sony sensors in the consumer range. Just BM leaves things clouded. Having 12 bit log to move the exposure as a reason, seems not as good as having 14 or 16 bits sensor values packed into 12 bits log. But, they have left it hanging. Why does 16 bit generate more heat then 12 bits Dmitry? I would expect more, but not that much.

I think Red is a bad example to compare to. Your artifacts will depend on your olpf your choose, and they go to some ridiculous amount like 15:1 constant without the level of noise reduction Braw does (as I told the industry years ago, noise reduction is the key to higher intra compression ratio, and you would get camera engineers debate the use of it). So, above 6:1 I wouldn't trust it, maybe less on the original red code. 3:1-4:1, Braw 2:1-3:1. Which compression ratio, codec versions and test samples was he using there? But, I specified various noise reduction techniques (though I don't remember how many new ones I kept in notes. If Red or Sony started doing it on sensor after my suggestions back then, I probably suggested it). Anyway, the point was, that I would have put spatial noise reduction do far down the list, it would have been off of it. I would have put good temporal at the top, though I had some interesting techniques in between). Elsewhere on the forums here, I've laid out my second generation image preservation preference list. First one did major improvements, but this one was more nuanced for high quality imaging. But, in that you can compress the parts which are sky or plain more, hair less, face in between, etc, dynamically for more compression while maintaining up to lossless quality. This is IS (intelligent Structure) programming rather than AI, to optimally process the image compression by rule set, or dynamic rule set, and dynamic analysis if needed.

Yes, do NR on the first node. Do it before expose (ISO) adjust. Works for RAW as well as for ProRes, if it source footage was shoot at native ISO:

There are mixed opinions on this. For example, colorist Jason Bowdach has an in-depth tutorial on noise reduction as part of his "Problem Solving in DaVinci Resolve" tutorial from Ripple Training, and he recommends adding noise reduction as a node after color correction because color correction itself can exacerbate noise.

If you know that in your physical experiment (measurements) you have a systematic error. Fist before any further calculations you should exclude this error. It's the basic thing. Nothing for discussions. If you know that any further manipulations with your data may cause any additional errors out of your math instruments so you should take this in to account and understand how to compensate this later.

I prefer first node. For 4K+ footage, I will probably have to cache TNR nodes for real-time playback, so may as well do everything after that.

Sony is compressing RAW in some stills cameras too.

That's just data compression and not image processing.

As long as it has visible side effects – and it has on high detail, contrasty edges – I don’t care that much why. Fortunately, Sony later added the choice for uncompressed RAW.
So, to have a choice too, let’s hope for a lift of that Red patent after the case with Apple is settled. Or BM might add an option to reduce NR filtering.
And, BTW, 14 Bit linear is definitely not better for grading than 12 bit log. Yes, technically it is throwing some information away, but humans differentiate much better in the shadows than in the highlights. You’d need 16 Bit linear to surpass 12 bit log (given that any sensor and A/D converter deliver).

I think you have to have NR if you want the compression.

Either that or very aggressive OLPFs like RED do.

Noise and false colour detail are the enemies of compression.

JB

Admitted. I wonder what we’d get with the RAWlite and a tad less NR.
Please note that after years of Red I love BRAW and BM‘s color science.

Sony is compressing RAW in some stills cameras too.

That's just data compression and not image processing.

As long as it has visible side effects – and it has on high detail, contrasty edges – I don’t care that much why. Fortunately, Sony later added the choice for uncompressed RAW.
So, to have a choice too, let’s hope for a lift of that Red patent after the case with Apple is settled. Or BM might add an option to reduce NR filtering.
And, BTW, 14 Bit linear is definitely not better for grading than 12 bit log. Yes, technically it is throwing some information away, but humans differentiate much better in the shadows than in the highlights. You’d need 16 Bit linear to surpass 12 bit log (given that any sensor and A/D converter deliver).

Sony added uncompressed RAW due to customer demand but the 'customer' didn't know what they wanted and they should have asked for lossless compressed RAW and not uncompressed RAW.....
I know LOG is nearer to human perception of tone but is that enough to make up for the 4x less graduations in 12 vs 14bit?

IIRC Kodak did extensive testing before they defined Cineon.

I think you have to have NR if you want the compression.

Either that or very aggressive OLPFs like RED do.

Noise and false colour detail are the enemies of compression.

I'd agree, too. But I would like to see an improved NR. Currently it is - from what I have read in those patent papers someone linked to - pretty basic and explains exactly this issue and some others (like haloing) we are discussing here.

I took a uncompressed DNG shot of the sky and applied a some simple post blurring onto the color channels - and presto - it looks like the BRAW blobs. Still can only be seen when the grade is pushed very far.

After I applied a better de-noising method through NeatVideo based on a noise sample of the camera, the sky looked, well, neat.

Well, Lol! My point exactly.

Admitted. I wonder what we’d get with the RAWlite and a tad less NR.
Please note that after years of Red I love BRAW and BM‘s color science.

Lol, again. I could see Red colour, and people still raved and bought into it. How come it took them so many years to make colour as good as a pocket video camera company can do in a six month or so cycle. It was hard to believe. Why didn't they just hire an experienced engineer to start with.

I would have loved to see Red succeed, but they never did. BM has been closer to succeeding.

Anyway, what real improvements in Braw has there been since the first version. I don't care if it is version 1.5 or whatever, what dues that mean, what improved?? Has so much if the stuff discussed back then been fixed up?

Thanks.

After I applied a better de-noising method through NeatVideo based on a noise sample of the camera, the sky looked, well, neat.

But, Neat is temporal based if I recall. You're needing to apply NR in camera to make an image more easily compress-able, so it has to happen real time. I think that's the trickier part to deal with.

JB