Blackmagic RAW

As I understood it, you can't encode into BRAW, only trim files that are already BRAW.

You are 100% correct

Ok. He mentions Larger sensors with more complex Raw in the future. That sounds like new higher resolution cameras.

This sounds like what I was advocating around 13 years ago, except the part de-mosaic. I can't quite work out what they mean, but as they mention dealing with noise on the camera end, that is completely what I wanted to drastically increase compression for the same sort of quality (less camera noise).

Does anybody know how they split the de-mosaicing in camera, and dud the compression?

I'm guessing the minimum they would do was to better form the raw data and remove noise, in such a way to make for quick conversion to 4:4:4, with maybe a bit more data This sounds a bit like the TV channel Raw format I was advocating around 13 years ago. So, it might be a good candidate for a raw TV codec.

One interview I saw has a guy talking about 32 Mbit/s 12:1 Raw similar to a ProRes 4:2:2. I imagine he meant 32 Megabyte/s. At 32 mb/s, cannI please have it in my phone. I still wouldn't mind it on my phone at 32MByte/s, please?

Now, the guy in the interview just mentioned, said they had worked on it for 2.5 years, and when asked about comparison to ProRes raw, he stated he had know idea. If you were working on ProRes raw, you would know. So, I suspect ProRes Raw has not been much in their development before the announcement. Not saying it won't come, but may not be planned.

They asked for some suggestions, well here they are:

Can you set final colour in camera with this? Applying the settings, luts and/or transforms to the meta data? So, you get handoff footage that maybe directly played to broadcast or transcoded to a final file or streamed?

Can you set final color balance in camera with this.

Can you have auto colour with this in camera, press to set, or turn on?

Otherwise, can you use this to set all levels in camera to hand off final footage to directly broadcast, transcoded to final encode or stream.

Can it be used, one day, as a delivery format?

I mention streaming, not just for internet streaming, but for wireless streaming to a recorder or in a studio/venue (the big picture). This makes wifi/local 5G use a lot better.

Otherwise, a good quality effort that makes the cameras more desirable.

..

..

OMG, my iMac is running at about 25% load both for CPU and GPU playing that stuff.
Sorry, BM, not buying the eGPU yet, the noise is also so low, who needs NR?

..

Is BMD RAW an open standard that, say, other camera manufactures can deploy for their own cameras?

I can't see BMD giving away so much research away for nothing to it's competitors, but hopefully will prompt them to consider the advantages.

That compared to free Resolve is nothing It's not that crazy amount of research.

Just wondering if any of the BM reps can verify if there's a flavor of braw that supports an alpha channel. I've always rendered out drag and drop graphics like logo reveals as Prores 444 since it supports alpha. I've been hoping to ditch prores altogether and this could be my solution. My instinct would be that braw has no alpha yet, but would be great if it eventually did.

Forget about BMRAW as final delivery/export codec. It's not going to work. Codec needs RAW sensor data, not final debayered RGB/YUV data. It's recording format, not "export". Could BM introduce intermediate codec based on it? Yes, just not sure if we need another intermediate codec. You don't need ProRes (if people not asking for it), DNxHR is as good.

So are the regular Cinema DNG files that The UMP normally shoots technically better quality then let's say QO, or is their something in the new Blackmagic Raw that increases the quality and lowers Fixed Pattern Noise?

From compression point yes, but 3:1 or Q0 loss is meaningless in practice. They could also introduce even higher quality mode, but this is not really needed. BM is also doing something with noise when working with BM RAW, so it looks like new files are actually better quality.

OMG, my iMac is running at about 25% load both for CPU and GPU playing that stuff.
Sorry, BM, not buying the eGPU yet, the noise is also so low, who needs NR?

This is how it should be, but so many people argued that DNG RAW is "good and not a problem".
They did not like when I was complaining about DNG RAW- now they seems to changed their mind

Cineform RAW still seems to have advantage, mainly due to wavelet nature.

Just wondering if any of the BM reps can verify if there's a flavor of braw that supports an alpha channel. I've always rendered out drag and drop graphics like logo reveals as Prores 444 since it supports alpha. I've been hoping to ditch prores altogether and this could be my solution. My instinct would be that braw has no alpha yet, but would be great if it eventually did.

Forget about BMRAW as final delivery/export codec. It's not going to work. Codec needs RAW sensor data, not final debayered RGB/YUV data. It's recording format, not "export". Could BM introduce intermediate codec based on it? Yes, just not sure if we need another intermediate codec. You don't need ProRes (if people not asking for it), DNxHR is as good.

It's totally possible, but they would have to purposely do it. I'm not going to get into the details, as it requires some mind shifts. But you can simply reply on debayering in the player with meta data to define any look set on set. But you get what you pay for. As long as you can share it with somebody to use it straight away, it's fine.

This is already supported through sidecar file, but it only operates on RAW data.
Doing same on final video is another story. Cineform had such a ability for years. BMRAW even if released 15 years after Cineform it doesn't really have any new cool features. Cineform seems to have more possibilities, which shows how advanced and unique it was many years ago.
Whole idea of embedded looks etc. combined with new eg. IMF container could totally change way of deliveries. We could have 1 package for different versions including language, cuts and even looks. This is far away as industry still struggles with simple color space flagging

I'm also trying to understand if with BMRAW debayering is provided by SDK? In other words- if I add for given player/app BMRAW support, does it automatically give me full support with debayering, so don't have to write my own code for this part?
BMRAW Player for Mac suggests this is possible, which is good news. It means we can easily add BMRAW support to any app over SDK without worrying of fact that this is RAW file and needs debayering.

Did some tests on the sample clips and they do run pretty damn fast on my old PC. So yeah... Awesome work BMD Team!

After watching Grant's presentation I still have some questions on the topic. I am not as well versed on the subject as I'd like to, but to my understanding one of the major benefits of RAW file formats is the ability to apply different debayering algorithms. Am I correct to assume that Braw won't have this functionality since the debayering is already "baked in" to some extent while the images are captured?

Also, can somebody explain the nature of this ghosting/fringing effect from one of the sample clips? I doubt that it has anything to do with the codec, but it's sill interesting what might be the cause of it

So downloaded player and clip 1 - mac played the clip once at a slow but consistent stuttery speed - audio was fine - played it again and it shut down my mac to black - had to actually restart.

Mac is late 2013 i7 4Core 16GB Ram 2GB Video Memory

Once computer restarted, tried again and played blck with audio - quit app - restarted and played fine albeit still really choppy but consistently so if that makes sense. Thought I'd share.

Anyway, pretty stoked raw even played at all and even more stoked that in 30 days I get to purchase my first blackmagic camera; a mini pro - also getting a new mac.

Anyway, my question is, now that we have very slick codec, what do you think I could get away with minimum mac-wise so that I can spend more money on lenses?

Cheers

Yes, David was one of my favourite engineers. But cineform was not alone, and I am talking about more than meta data in the first part.

But still, like in the second part, ProRess results, they can do it as a pass off with reasonable accuracy and results set during shooting. But, as you said, people get so bound up just on a color flag, how are they going do more? It's just amazing how little is like cineform, and how much is like other things, and those flags. You could ask where do they get programmers from, programming video games in their mother's basement, but that would be an insult to good machine code game programmers, who without much training would be concerned about missing that flag.

About cineform. It was a shame that lack of hardware support slowed it's performance. It actually performed a lot better in software than h264 software of the day.

So, is BM willing to go the whole way as an intermediate and pro delivery format?

[CaptainHook]

if I add for given player/app BMRAW support, does it automatically give me full support with debayering, so don't have to write my own code for this part?

Yes, the SDK handles it.

I sure do hope braw ends up in the pcc4k, but I would caution everyone that Grant likes to say things that will please his audience even when it may never happen.

... I don't see a reason not to shoot 4.6k as the 12:1 ratio will give you file sizes akin to prores HQ but in 1080p!!!! The savings are massive.

Right on, Ryan. The results look good enough to just forget about in camera downscaling when the resulting file size is about what you were used to in HD. Even raw UHD capture to deliver HD could be the norm, but there are benefits to going 4.6K to HD in post as you have about 20% more room to stabilize or reframe in post.

if I add for given player/app BMRAW support, does it automatically give me full support with debayering, so don't have to write my own code for this part?

Yes, the SDK handles it.

And I assume also guarantee all apps end up with same quality- this is good.
In the same time can you access RAW data (before debayering) through SDK (eg. if I have better debayer )?

Does anyone know what type of compression BMD Raw uses? Is it wavelet-based? Is it lossless?

It's not lossless for sure as lossless has no fixed ratios.
I would also like to know if it's DCT based of wavelet?
Some answer may be in playback testing. Unfortunately I have not seen a proper CPU load drop when using proxy mode at 1/2 or 1/4 resolution, so it suggests it's not wavelet. Btw. Performance Mode is gone from Resolve 15.1 top menu, so I assume it's now fully automated and always engaged (if not turned off in preferences).

Performance mode is in the Resolve Preferences. I just saw it this morning.


Sent from my iPhone using Tapatalk

It was always there+in in top menu. It's gone from top menu.

Preferences-User-Playback Settings is where it can be found.

Is BMD RAW an open standard that, say, other camera manufactures can deploy for their own cameras?
I can't see BMD giving away so much research away for nothing to it's competitors, but hopefully will prompt them to consider the advantages.

That compared to free Resolve is nothing It's not that crazy amount of research.

No, incoding by Cameras is only going to be for BM Cameras, which so far Is the UM Pro and later the new Pocket 4K. According to an email I received from BM, Other manufacturers cameras will not have the source code or option to use the new codec, according to BM. Decoding by NLE, is open through the SDK code, which is available to third party NLE programs like Premiere and FCP X.
Cheers

Is this official/confirmed info (or just somewhere from net)?
Many websites says otherwise: that BM wants others to implement their codec as well. Maybe problem is in details- is it for free or not? I have not seen any definitive BM answer.

The SDK is free to download now.


Sent from my iPhone using Tapatalk

Is this official/confirmed info (or just somewhere from net)?
Many websites says otherwise: that BM wants others to implement their codec as well. Maybe problem is in details- is it for free or not? I have not seen any definitive BM answer.

Answer is in there - the SDK is released for allowing BMRaw in other editors. Nothing about allowing other camera manufacturers, and I would be shocked if it went into other cameras. I could be wrong about that, but it would really surprise me.

For free it's questionable.
With licensing fee- great way to earn extra money.

Can you set final colour in camera with this? Applying the settings, luts and/or transforms to the meta data? So, you get handoff footage that maybe directly played to broadcast or transcoded to a final file or streamed?

Can you set final color balance in camera with this.

Can you have auto colour with this in camera, press to set, or turn on?

Otherwise, can you use this to set all levels in camera to hand off final footage to directly broadcast, transcoded to final encode or stream.

All these things are provided with .braw in the Ursa Mini Pro today.

Ursa Mini Pro has an auto white balance button. The temp + tint settings are saved as metadata in braw when the files are recorded. And, if you set it in the camera menu to use Extended Video dynamic range gamma for display that choice will also be recorded in metadata.
Then, any player or transcoder running the SDK will use the temp+tint settings and Extended Video dynamic range gamma for playback or transcode straight from the camera card.

If, for any reason, any of that metadata needs to be changed, it can be done in Resolve, or alternatively because the metadata is JSON, it should be super simple for third party apps to change any of the braw image decode metadata before playback or transcode. By opening up a braw sidecar file in any text editor you can see and change the decode just by typing in new values for each variable:

"tone_curve_contrast": 1.625746,
"tone_curve_saturation": 1.070000,
"tone_curve_midpoint": 0.409008,
"tone_curve_highlights": 0.600000,
"tone_curve_shadows": 1.733267,
"tone_curve_video_black_level": 1,
"viewing_gamma": "Blackmagic Design Extended Video",
"viewing_gamut": "Blackmagic Design",
"viewing_bmdgen": 4,
"exposure": -0.400000,
"white_balance_kelvin": 6000,
"white_balance_tint": 10,
"iso": 400,

Right out of the gate, it's an amazingly useful and flexible design.

Not only this- you can change them through file with frame accuracy.

I like how the sidecar file is human readable and directly editable. The Web conquers all.

All these things are provided with .braw in the Ursa Mini Pro today.

Ursa Mini Pro has an auto white balance button. The temp + tint settings are saved as metadata in braw when the files are recorded. And, if you set it in the camera menu to use Extended Video dynamic range gamma for display that choice will also be recorded in metadata.
Then, any player or transcoder running the SDK will use the temp+tint settings and Extended Video dynamic range gamma for playback or transcode straight from the camera card.

If, for any reason, any of that metadata needs to be changed, it can be done in Resolve, or alternatively because the metadata is JSON, it should be super simple for third party apps to change any of the braw image decode metadata before playback or transcode. By opening up a braw sidecar file in any text editor you can see and change the decode just by typing in new values for each variable:

"tone_curve_contrast": 1.625746,
"tone_curve_saturation": 1.070000,
"tone_curve_midpoint": 0.409008,
"tone_curve_highlights": 0.600000,
"tone_curve_shadows": 1.733267,
"tone_curve_video_black_level": 1,
"viewing_gamma": "Blackmagic Design Extended Video",
"viewing_gamut": "Blackmagic Design",
"viewing_bmdgen": 4,
"exposure": -0.400000,
"white_balance_kelvin": 6000,
"white_balance_tint": 10,
"iso": 400,

Right out of the gate, it's an amazingly useful and flexible design.

Jamie, thanks for helping. I haven't looked into the models of the last x years. So, colour pulling on set in raw.

Now, is this a matter of you set the look on the set, and the BRaw can be auto transcoded to a delivery format (covering all angles)?

So, he did mention the other camera thing. I'm pretty interested for phones.

Is there a way to specify custom LUT in JSON?

Is there something I need to download to play the demo files? Not able to play them on my Mac.

There's a basic Blackmagic Raw Player.
But if you want to do anything to the files you probably need Resolve (free).

Since BM cameras record Raw internally, I do not see BM adding this to a VA for other cameras, at least not until the exclusive deal Atomos has with Sony and Panasonic has expired.
Cheers

As a Cion Owner, I 'really' don't give a damn about Sony, Panny, and Atomos,.....

Especially after buying a Shogun to do Raw recording and getting shafted on the features never being delivered for Cion, and the overall quality of the Shogun's build.


On the cameras supported, after seeing that question repeated, and rightfully so I'd think after reading the files size differences quoted here,..

Just did a quick test with one of the new braw files. Amazing. What has me excited is the file sizes, braw 246MB, ProRess 422- 424MB, 422HQ- 760MB, 4444- 826MB. That means one should be able to record longer in RAW on existing media than in ProRess. Why oh why would you not shoot in RAW all the time in future. This is HUGE, the quality improvements in my footage are going to be staggering.

One would have to think, that any camera that could do the processing and data throughput to record CineDNG, would also have the processing power to shift BRAW, at the same resolutions and frame rates as the CineDNG recorded by each model.

There's a basic Blackmagic Raw Player.
But if you want to do anything to the files you probably need Resolve (free).

Found it. Looks like my old 2013 MacBook Pro can't handle it. Very, very choppy. Wonder which MacBook Pro Grant was playing his on?

Forget about BMRAW as final delivery/export codec. It's not going to work. Codec needs RAW sensor data, not final debayered RGB/YUV data. It's recording format, not "export". Could BM introduce intermediate codec based on it? Yes, just not sure if we need another intermediate codec. You don't need ProRes (if people not asking for it), DNxHR is as good.

That's pretty much the crux of the filetypes issue - convince clients that DNxHR, or CanopusHQX, is the functional equal of ProResHQ for their delivery master copies.

At the quoted files sizes seen so far, I'd bet everyone will be dropping ProRes or CineDNG for capture, and just swap to BRAW with sidecar files for the 'video' output needs.

These points alone will have more of us who shoot on other cameras wanting BMD to sell us a BRAW enabled recorder - add to those finding they can record the format to their current SD cards, and I'm really curious to see what firmware updates or new VA models will contain.

These points alone will have more of us who shoot on other cameras wanting BMD to sell us a BRAW enabled recorder - add to those finding they can record the format to their current SD cards, and I'm really curious to see what firmware updates or new VA models will contain.

I think the next iteration of the Video Assists will likely encode BMDraw if they get a raw data stream. And with the Atomos Ninja V recording Prores raw, I think a lot of consumers will be calling for raw over HDMI.

Is BRAW limited to 12-bit color? How about 16-bit?

If it's log encoded that's not really needed. If it's technically limited, only the developers can tell you.

Is BRAW limited to 12-bit color? How about 16-bit?

I think it's limited to what the sensor outputs. 12-bit color seems like plenty of color information, especially considering that most displays are still only 8-bit.

Will BRAW files be able to work in Premiere? I do have Resolve, but sometimes clients insist on me editing in Premiere so they can screw with things later on and it would be great to have the latitude of BRAW for certain projects.

Is BRAW limited to 12-bit color? How about 16-bit?

Funny thing - the metadata for at least two of the samples released read 16 bit color....

I’m sure BMraw will come to Premiere - there’s no reason NOT to support it with the SDK released, and BMD is not Apple (thank goodness!).

Funny thing - the metadata for at least two of the samples released read 16 bit color....

Really? Now that's interesting...

Since the demosaic process is now partially performed in the camera, is there any chance of downscaled raw? Not that it's as much of an issue now that the new codec is so fast, but it would still be interesting.

Doesn’t all raw bmd log footage show as 16 bit in resolve anyway when it’s a 12 bit log format? Wouldn’t 16 bit only be relevant in linear?