resolve 15.1 braw output ... where?

i hear Grant that told in video presentation of Braw that we can output in raw the export of resolve.
i would like to know where, i not found braw voice on delivery.
i think, i hope i can load other raw data and convert in braw. i understand that half of process of braw should be in camera and half in codec, but on computer i have time to attend full raw demosaic conversion, and... later have all benefit of new raw codec, which is what every old CineformRaw user is orphan and hope to have again.
some one tell me more about output braw from resolve, i do a fast search on 15.1 pdf manual but i not found.

You can't render to Blackmagic Raw. Grant meant you can use Media Management to trim clips and only keep what's needed for the project.

So, just like Red R3D in this respect.

Yes, as BMRAW export is about pointless in other cases.

BMRAW can be useful is some 3rd party converter where you can convert other RAW format into eg. DNG RAW into BMRAW. Otherwise anything else than trimming make no sense. You would never want to export final Resolve project to BMRAW.

It's format to store RAW sensor data, not final video.

At 24:43 in the release video Grant clearly states it can be rendered out. He goes into some detail. it does not appear he is just misspeaking about how you can trim videos.

Prores and DNxHR are also not for use as final video yet you are still able to render these.

I also can not find how to do this from the render page.

I think you're misreading him. That segment concerns project consolidation and hand-off of footage to another facility.

Using Media Management, you can currently copy/move and consolidate braw files -- and the output is braw. The same is not available through Delivery, for reasons given above.

At 24:43 in the release video Grant clearly states it can be rendered out. He goes into some detail. it does not appear he is just misspeaking about how you can trim videos.

Prores and DNxHR are also not for use as final video yet you are still able to render these.

I also can not find how to do this from the render page.

Don't believe so much what Grant is saying

I don't think the OP or myself are thinking of BRAW as a final viewable file but perhaps for use in "project consolidation and hand-off of footage to another facility."

I see in another topic Andrew states "Could BM introduce intermediate codec based on it? Yes, just not sure if we need another intermediate codec"

I am not sure either but if it were an option we would be able to find out if it has value.

BTW, I tried posting a reply earlier and it did not post. I apologize in advance if it shows up later as a double post.

I have to admit, I also thought Grant meant this would be an option on the Deliver page. I was going to write and ask the developer of Playback Pro to include the SDK and make BRAW files compatible.

It would be nice to transcode our existing Red RAW and RAW DNG footage to a single Blackmagic RAW file for more efficient media management and stock footage use.

I was also under the impression that we could render to BRAW at some point...the mere fact alone that it retains all of the RAW advantages, at a vastly smaller bandwidth than any other high-quality codec, is enough to make it viable archiving format. It's why I invested $3000 into a Cineform license back in 2001, to be able to tame the huge files that my 3-5K Timelapse files would end up being. I dearly miss the continued support of the Cineform codec, and was overjoyed to learn of BMRAW...but that was, in part, because I thought that I could then render my timelapses to BRAW.

Why would that *not* be a viable option?

Maybe because of the in-camera treatment.
But Cineform still works for me.

So, is the in-camera part of the processing a necessity to make BRAW work, or is it just a clever way of supporting part of the processing in-camera and taking that part off the computer's CPU/GPU, in advance, so to say?

I mean, sure, it's not like Cineform can't be used anymore, but using a format that is now not in development anymore means that at some point it will probably be necessary to transcode it back into another format for safe-keeping. I'd just rather settle on a format now and leave it at that. Looks like BRAW will be around for a long time, with Blackmagic's continuing gain of users in the industry.

What I'd rather like to see happen is of no consequence here, of course...but maybe, just maybe, if enough users express their wish to see this format supported as a delivery option in Resolve, then BM might be more inclined to make it work?

Is anyone here *against* being able to render to it?

[Peter Chamberlain]

Braw can only be generated in camera.
Resolve and other apps can’t render to it.
Some can trim the clips to media manage but they are not rendering a newly processed clip.

thanks, Peter. I can live with that, and it does end this discussion of rendering to it definitively.

out of interest, would you mind explaining what it is that happens in the camera, that a computer cannot do?

Adobe has DNG converter... Can BM have something similar? It is a major pain to deal with those sequences.

Can you tell us about your workflow? Resolve offers a lot of common sequence formats, just not DNG.

BRaw is clearly meant to be an acquisition codec.

I know this is a very old thread, but it is something I have interest in, and I have something to add that may help explain things a bit.

So, RedRAW is exclusive to Red cameras, and is considered the ultimate output format for maximum possible quality. All other RAW formats are attempts to attain close to this quality, without violating any patents. BRAW does this with some in-camera image processing. Very good image quality is maintained, file size is greatly reduced, and no patents are violated.

This still doesn't explain why we cannot export BRAW in DR. I assumed we could...at the very least in DR studio. Why would a person want to export to BRAW? Obviously, for archival purposes. Maintaining that high image quality with the reduced size is THE reason BRAW exists at all. It just doesn't make any sense to not incorporate the ability to export BRAW in, at the very least, DR studio.

Sure, I can understand BM not wanting it in DR, since that effectively would provide the world with a free method to convert to BRAW...in spite of this dramatically increasing the potential to adopt BRAW as a primary standard format industry-wide. But, honestly, DR studio would be worth the $$$ for people who don't work in DR at all just to get access to the ability to convert files to BRAW. Or, at least, that is what I am currently convinced of...

*rant over* lol

You have your project and can archive it keeping trimmed BRAW files. What else you need?
RAW format is basically for recording.

You can in theory take other RAW format and convert it to BRAW, but it's not so easy and makes sense only for some of them (for others it's even simply impossible).
You can't take any prosumer (h264/5, ProRes, etc) already debayered formats and convert to BRAW. It makes zero sense. Once data went through debayering you basically can forget about RAW. It's like converting h264 camera recording to ProRes to me it better quality
Current Resolve has about all needed functionality around BRAW, which is trimming.

RED RAW is not any benchmark today. It's just JPEG2000 and new version is DCT based format like BRAW or PoResRAW. There is no magic there- only RED's pr and internet myth.

Rebayering an already debayered material is the equivalent of chroma subsampling or downscaling the footage. Does it gain any quality from this? No. So for same effect, just lose some of the data by downscaling 2x and do a quality upscale later, no need for braw or any other raw format. The only reason raw formats exist is that they are closer to the data sensor captures, they store either the same data or a subset of that (when using lossy compression). Debayering increases data amount by interpolating the missing information to form full image planes for each color component.

RED RAW is not any benchmark today. It's just JPEG2000 and new version is DCT based format like BRAW or PoResRAW. There is no magic there- only RED's pr and internet myth.

Yeah... this video sums it all up. In the first moments they can't stop talking about how their raw codec is the solution to everyone's 'problem'. Cringetastic. People defend this stuff even.

Why would a person want to export to BRAW? Obviously, for archival purposes.

For archival purposes there are plenty other formats. If size is a consideration ProRes4444 is just fine. Uncompressed formats will do the job otherwise. Raw formats are intended for acquisition only like others mention, because it holds information of the sensor which isn't present anymore once it's processed, edited, graded, composited etc. No point putting it back in such a container.

ACES recommends EXR as an archival format.

RED RAW is not any benchmark today. It's just JPEG2000 and new version is DCT based format like BRAW or PoResRAW. There is no magic there- only RED's pr and internet myth.

Yeah... this video sums it all up. In the first moments they can't stop talking about how their raw codec is the solution to everyone's 'problem'. Cringetastic. People defend this stuff even.

Why would a person want to export to BRAW? Obviously, for archival purposes.

For archival purposes there are plenty other formats. If size is a consideration ProRes4444 is just fine. Uncompressed formats will do the job otherwise. Raw formats are intended for acquisition only like others mention, because it holds information of the sensor which isn't present anymore once it's processed, edited, graded, composited etc. No point putting it back in such a container.

Have RED really made this video ?
Who is it intended for - prosumers? I don't believe they shot it for pro users are they know RED cameras enough, so for them such a video is cheap marketing (they will never choose a camera because of this video).
Anyway...RED is just 1 of many choices today, not an only choice.

You have your project and can archive it keeping trimmed BRAW files. What else you need?
RAW format is basically for recording.

You can in theory take other RAW format and convert it to BRAW, but it's not so easy and makes sense only for some of them (for others it's even simply impossible).
You can't take any prosumer (h264/5, ProRes, etc) already debayered formats and convert to BRAW. It makes zero sense. Once data went through debayering you basically can forget about RAW. It's like converting h264 camera recording to ProRes to me it better quality
Current Resolve has about all needed functionality around BRAW, which is trimming.

RED RAW is not any benchmark today. It's just JPEG2000 and new version is DCT based format like BRAW or PoResRAW. There is no magic there- only RED's pr and internet myth.

A person would need to have BRAW files to begin with...which is the problem...and why the desire to be able to export BRAW.

And, yeah...RedRAW is pure, uncompressed sensor data. From what I have read, it is the only uncompressed/unprocessed sensor data format because RED has the method patented. Every other "RAW" format is not true uncompressed/unprocessed sensor data.

All that said, I only learned this stuff over the past approximately week or two, so I may have misread something, or misunderstood someone's explanation.

Anyway, the point being, if I have RedRAW, it would be awesome to convert it BRAW for archival. As for converting one RAW format to another, I haven't learned enough about what debayering even is to know anything about that. I will have to take your word for it as of right now.

Rebayering an already debayered material is the equivalent of chroma subsampling or downscaling the footage. Does it gain any quality from this? No. So for same effect, just lose some of the data by downscaling 2x and do a quality upscale later, no need for braw or any other raw format. The only reason raw formats exist is that they are closer to the data sensor captures, they store either the same data or a subset of that (when using lossy compression). Debayering increases data amount by interpolating the missing information to form full image planes for each color component.

As I pointed out in my previous post...I still haven't gotten around to learning what debayering even is yet. Thus, at the time, I have been understanding it as a sort of "encryption" process. Basically, processing is done to the sensor data. If processing is done, sometimes it can be reversed...zip files are a simple example. BUT...as I said, I don't know what debayering even is yet...beyond some sort of processing done to the RAW sensor data. I have been of the early opinion that it is a process that could, in theory at least, be reversed.

RED RAW is not any benchmark today. It's just JPEG2000 and new version is DCT based format like BRAW or PoResRAW. There is no magic there- only RED's pr and internet myth.

Yeah... this video sums it all up. In the first moments they can't stop talking about how their raw codec is the solution to everyone's 'problem'. Cringetastic. People defend this stuff even.

Why would a person want to export to BRAW? Obviously, for archival purposes.

For archival purposes there are plenty other formats. If size is a consideration ProRes4444 is just fine. Uncompressed formats will do the job otherwise. Raw formats are intended for acquisition only like others mention, because it holds information of the sensor which isn't present anymore once it's processed, edited, graded, composited etc. No point putting it back in such a container.

I agree that most people don't need RedRAW. RedRAW is only important when preservation of ALL data is critically important. In other words, it's only a big deal if you require maximum possible quality. Since, in all honesty, that is far from even important to the overwhelming majority...RedRAW isn't that big a deal. At this point, it becomes about excellent sensor data preservation with minimum size. This is why BRAW is a big deal at all. It does this well. That's why it would be useful to have access to BRAW as an export option...from what I have read, the files are smaller than the other psuedoRAW formats...while still having access to most of the original sensor data. It's not really a RAW file...since RedRAW is the only actual RAW file format.

Of course...I have only been looking into RAW file formats for a couple weeks...so maybe I don't know enough yet???

ACES recommends EXR as an archival format.

Good to know. I like EXR quite a lot as a still image format. Quality is better than PNG, you still have access to a lot of the image data PNG looses, and I have often seen EXR files be smaller than PNGs for the exact same image.

You have your project and can archive it keeping trimmed BRAW files. What else you need?
RAW format is basically for recording.

You can in theory take other RAW format and convert it to BRAW, but it's not so easy and makes sense only for some of them (for others it's even simply impossible).
You can't take any prosumer (h264/5, ProRes, etc) already debayered formats and convert to BRAW. It makes zero sense. Once data went through debayering you basically can forget about RAW. It's like converting h264 camera recording to ProRes to me it better quality
Current Resolve has about all needed functionality around BRAW, which is trimming.

RED RAW is not any benchmark today. It's just JPEG2000 and new version is DCT based format like BRAW or PoResRAW. There is no magic there- only RED's pr and internet myth.

A person would need to have BRAW files to begin with...which is the problem...and why the desire to be able to export BRAW.

And, yeah...RedRAW is pure, uncompressed sensor data. From what I have read, it is the only uncompressed/unprocessed sensor data format because RED has the method patented. Every other "RAW" format is not true uncompressed/unprocessed sensor data.

All that said, I only learned this stuff over the past approximately week or two, so I may have misread something, or misunderstood someone's explanation.

Anyway, the point being, if I have RedRAW, it would be awesome to convert it BRAW for archival. As for converting one RAW format to another, I haven't learned enough about what debayering even is to know anything about that. I will have to take your word for it as of right now.

About all you say is somehow wrong.
Just read what RAW is, how it looks and what you can do with it

RED RAW is actually not pure RAW, but compressed RAW. It's RAW sensor data which then gets compressed to JPEG2000 or their new variant. BRAW is the same, but there is some extra processing before it gets compressed. It's about meaningless for end user. If you want RAW data out of sensor then closest is ARRI which is uncompressed RAW. As long as compression is mild then it's all harmless in real world, but makes recording easier.

Your idea is to be able to convert between RAW formats, which has only tiny sense.
For example it can't be done with mentioned RED RAW as their SDK doesn't provide RAW data only debayered one, so we have nothing to start with.
You can do it with eg. ProResRAW, but this is about pointless as it's already similar format to BRAW (lack of Resolve support aside).
Of course any other format which is not RAW makes absolutely 0 sense to be converted. It was debayered and heavily compressed, so it's already "broken". Absolutely no point trying to make it RAW again.
Only format which has at least some sense is uncompressed Arri RAW as we could gain some space savings. Problem is that people who shoot Arri RAW are fine with its size. There is now lossless compression for Arri RAW, so for those who wants to save space they use it. Other issue is that BRAW requires detailed info about camera and sensor in order to work, which may not be a pubic info.

In summary- forget about BRAW export as it's not going to happen because it makes about 0 sense. It's not a codec to export to, it's codec to record to straight in camera. Later conversion between RAW formats is questionable and serves almost no role.

There is for example ProResRAW to CDNG converter for those who want to use Resolve on ProResRAW files. It works, but at then end it's work around. Proper solution is for Resolve to get ProResRAW support. This is just another transcoding as at the end conversion between RAW formats is the same as conversion between eg. h265 and ProRes. You waste time and space. We could use BRAW instead of CDNG if encoder was public. We could then use Resolve to work with BRAW, but this is just another workaround (and double compression for no real reason).

Going from any format to BRAW won't make your quality better (technically always bit worse). If you want to save space just RAR your RAW files. If they are not already compressed you gain a lot. If they are then BRAW will be similar size anyway, so pointless conversion.

You have your project and can archive it keeping trimmed BRAW files. What else you need?
RAW format is basically for recording.

You can in theory take other RAW format and convert it to BRAW, but it's not so easy and makes sense only for some of them (for others it's even simply impossible).
You can't take any prosumer (h264/5, ProRes, etc) already debayered formats and convert to BRAW. It makes zero sense. Once data went through debayering you basically can forget about RAW. It's like converting h264 camera recording to ProRes to me it better quality
Current Resolve has about all needed functionality around BRAW, which is trimming.

RED RAW is not any benchmark today. It's just JPEG2000 and new version is DCT based format like BRAW or PoResRAW. There is no magic there- only RED's pr and internet myth.

A person would need to have BRAW files to begin with...which is the problem...and why the desire to be able to export BRAW.

And, yeah...RedRAW is pure, uncompressed sensor data. From what I have read, it is the only uncompressed/unprocessed sensor data format because RED has the method patented. Every other "RAW" format is not true uncompressed/unprocessed sensor data.

All that said, I only learned this stuff over the past approximately week or two, so I may have misread something, or misunderstood someone's explanation.

Anyway, the point being, if I have RedRAW, it would be awesome to convert it BRAW for archival. As for converting one RAW format to another, I haven't learned enough about what debayering even is to know anything about that. I will have to take your word for it as of right now.

About all you say is somehow wrong.
Just read what RAW is, how it looks and what you can do with it

RED RAW is actually not pure RAW, but compressed RAW. It's RAW sensor data which then gets compressed to JPEG2000 or their new variant. BRAW is the same, but there is some extra processing before it gets compressed. It's about meaningless for end user. If you want RAW data out of sensor then closest is ARRI which is uncompressed RAW. As long as compression is mild then it's all harmless in real world, but makes recording easier.

Your idea is to be able to convert between RAW formats, which has only tiny sense.
For example it can't be done with mentioned RED RAW as their SDK doesn't provide RAW data only debayered one, so we have nothing to start with.
You can do it with eg. ProResRAW, but this is about pointless as it's already similar format to BRAW (lack of Resolve support aside).
Of course any other format which is not RAW makes absolutely 0 sense to be converted. It was debayered and heavily compressed, so it's already "broken". Absolutely no point trying to make it RAW again.
Only format which has at least some sense is uncompressed Arri RAW as we could gain some space savings. Problem is that people who shoot Arri RAW are fine with its size. There is now lossless compression for Arri RAW, so for those who wants to save space they use it. Other issue is that BRAW requires detailed info about camera and sensor in order to work, which may not be a pubic info.

In summary- forget about BRAW export as it's not going to happen because it makes about 0 sense. It's not a codec to export to, it's codec to record to straight in camera. Later conversion between RAW formats is questionable and serves almost no role.

There is for example ProResRAW to CDNG converter for those who want to use Resolve on ProResRAW files. It works, but at then end it's work around. Proper solution is for Resolve to get ProResRAW support. This is just another transcoding as at the end conversion between RAW formats is the same as conversion between eg. h265 and ProRes. You waste time and space. We could use BRAW instead of CDNG if encoder was public. We could then use Resolve to work with BRAW, but this is just another workaround (and double compression for no real reason).

Going from any format to BRAW won't make your quality better (technically always bit worse). If you want to save space just RAR your RAW files. If they are not already compressed you gain a lot. If they are then BRAW will be similar size anyway, so pointless conversion.

Ah! okay, I see where I was getting some things confused. RedRAW is the only unprocessed compressed RAW. All the other types are processed compressed RAW. Also, your point about BRAW being camera dependent now makes sense to me in light of some stuff I learned about color grading this week.

I have no belief that going from one compressed/processed format to a different compressed/processed format would be of any benefit. As I said, I am just learning this stuff and going off what I have read in the past couple weeks. Part of that was BRAW is supposedly smaller files than other RAW formats, while being at, or very close to, the quality of other formats. I have no delusions that changing file formats will somehow magically improve image quality. What I am is...lacking information about RAW file formats...not stupid. It's a lot of new information to assimilate when a person has had zero exposure to it. Best I can do at first is try to make generalizations from my knowledge base in an attempt to understand it all until I reach critical mass with the information.

Hehehe! Nice. A video about RED and their litigious penchant actually explained more about RAW formats than most discussions I have seen.

RED's Compressed Internal RAW and the NEVER ENDING Lawsuit

There are other unprocessed RAW (some of them are even compressed like RED) formats. Arri is unprocessed and uncompressed. ProResRAW is like RED- they pay licensing fees. Sony is unprocessed and compressed as RED gave up on Sony. BRAW to avoid patent issue is processed a bit before compression.
BRAW is not smaller than RED or ProResRAW as you have to keep only mild compression (you can go from 3:1 to 8:1 for high quality). If you do strong compression on RAW you actually loose too much and loose sense of RAW source which is linked to high-quality productions. You may just record h264/5 then.

...your point about BRAW being camera dependent now makes sense to me in light of some stuff I learned about color grading this week....

A key point is true RAW formats are low-level camera-specific sensor data. RAW converters must know the specific sensor characteristics to decode that, and they assume it is unaltered. In general no editing app for video OR stills can export edited RAW data, else by definition it would no longer be RAW.

This isn't limited to Resolve exporting edited BRAW. E.g, if you edit a Nikon NEF file in Photoshop or Lightroom, you cannot export that as an edited RAW NEF file including changes. The edits of a RAW file are usually external to the image file, although they could theoretically be in a header. The key concept is edits to RAW stills or video are stored as external metadata and the RAW data itself is never altered or re-encoded as RAW. Otherwise it would no longer be RAW.

E.g, in Lightroom if you edit a RAW still then use a 3rd-party plugin on it, a modified RAW still is not handed to the plugin. Rather the metadata edits are applied to the RAW data and then transparently converted to to a TIFF file which includes the Lightroom edits, and *that* is handed to the plugin.

What about Blackmagic Video Assist recorders that encode (for example) Panasonic video data as BRAW? Isn't BRAW partially debayered inside the camera? It is for BMD cameras but obviously not for Panasonic. In this case the Panasonic camera is sending a proprietary RAW data stream to the Video Assist which (being made by Blackmagic) obviously knows how to encode BRAW. Panasonic had to disclose low-level sensor data to Blackmagic. Given that info, the Video Assist firmware could interpret the Panasonic RAW stream and reformat it as BRAW.

You cannot properly convert a non-RAW format to BRAW (or ProRes RAW or REDRAW) because that is demosaiced data. An H264, HEVC or ProRes 422 file has certain characteristics baked in such as white balance. You cannot undo that and produce a RAW video file (which has no intrinsic white balance).

The reason a Video Assist can encode BRAW from a Panasonic camera is (1) They are both RAW formats (2) Panasonic disclosed low-level sensor-specific engineering data to BMD which allowed the interpretation of their proprietary RAW stream and (3) Blackmagic knows the undocumented details of how to encode BRAW. There is no SDK or non-Blackmagic hardware which can encode BRAW.

If you had the undocumented details of BRAW encoding you could physically produce an output file from a H264/HEVC/ProRes 422 input file, and Resolve might read that. However it would not work as expected. E.g if you tried to adjust white balance it wouldn't look right since the previous camera baked that into the H264 file and you cannot undo that.

I used white balance because it's an easy example. However there are many other low-level sensor details you'd have to just make up or guess at, since the data isn't in the H264 file. Without knowing those exact details the BRAW file would not function as expected. You cannot undo a baked cake, extract the original raw ingredients then give that to another chef to produce a modified cake.

What you can process in camera you can process in recorder (or even with PC).
People read things to directly, specially when it comes to some pr materials which are written in very specific way.

You can convert any video back to RAW (with some fairly good accuracy). This is how Cineform tools were converting RED RAW back to CF RAW (as RED doesn't provide RAW data in their SDK). In order to make it 'perfect' you would need some metadata recorded together with video. Then you could even have white balance etc. working properly. You just need a start point which represent your RAW data accurately. It's not 100% perfect process though. For that you need RAW data to start with.

Whole argument about RAW been not baked is not that important today. With good codecs about same data can be still recovered (unless your recording is done crazy badly). Key point is fact that by compressing RAW you get most efficient recording data (and we all want more storage and cheap recording medium). RAW is just a single channel B&W data and after debayering you're getting 3 channels so tons more to compress and store. This is key benefit of RAW, not really the un-baked look. This is also the most annoying bit which RED patent is blocking.

What you can process in camera you can process in recorder (or even with PC).
People read things to directly, specially when it comes to some pr materials which are written in very specific way.

You can convert any video back to RAW (with some fairly good accuracy). This is how Cineform tools were converting RED RAW back to CF RAW (as RED doesn't provide RAW data in their SDK). In order to make it 'perfect' you would need some metadata recorded together with video. Then you could even have white balance etc. working properly. You just need a start point which represent your RAW data accurately. It's not 100% perfect process though. For that you need RAW data to start with.

Whole argument about RAW been not baked is not that important today. With good codecs about same data can be still recovered (unless your recording is done crazy badly). Key point is fact that by compressing RAW you get most efficient recording data (and we all want more storage and cheap recording medium). RAW is just a single channel B&W data and after debayering you're getting 3 channels so tons more to compress and store. This is key benefit of RAW, not really the un-baked look. This is also the most annoying bit which RED patent is blocking.

That's kind of what I have been basing my entirely original assumptions on. Granted, I wasn't factoring the camera specific color reference. But, even now, it seems like, if the appropriate metadata was available, it should be possible to convert between formats fairly accurately. Really the only thing I did not realize is that BRAW isn't actually compressed any more than any other format. That alone would make it mostly pointless to convert from any other format into BRAW...AFAIK now...

Forget RAW name and if you look at data then this is nothing special. Just some B&W pixels which can be compressed as any other video. Whole myth about it been something special etc. is just a ...myth. Same myth as REDCODE been anything unique and amazing.
It's just data which doesn't represent usable video without extra processing for which you need bit of metadata which describes it. Today even phones can process RAW video data

And today you can have H.265 in 10 bit and 4:2:2 with pretty decent data rates in log.
That can be used for some decent (but not extreme) grading and it's highly compressed.