Internal ProRes RAW for Pyxis?

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

Will Vazquez

  • Posts: 198
  • Joined: Thu Mar 30, 2017 7:40 pm

Internal ProRes RAW for Pyxis?

PostSat Feb 22, 2025 12:58 pm

Now that Nikon owns RED's patents, they are starting to license internal RAW recording to other manufacturers. We see it in the GH7 and soon in the new Lumix S1RII that will be released next Tuesday (according to L-Rumors.com). I expected this would happen because Nikon is a publicly traded company and would make more money licensing the tech than just hoarding it for their own cameras.

According to Grant Petty, BRAW is partially de-mosaiced before compression, thus it is not true RGB RAW sensor data being recorded. I've witnessed the softening of the image when BMD went from Cinema DNG to BRAW years ago. I love a lot of aspects of BRAW, but not the plastic looking image.

Is there any chance that Blackmagic can license true internal BRAW from Nikon for their cameras? Perhaps they can develop a new BRAW2 codec that features the true RAW.

The camera industry is shrinking and if ARRI LogC3 is offered as a $200 license for the new S1RII as it is for the GH7, this will be huge, combined with ProRes RAW. Wow!
Offline

John Brawley

  • Posts: 4499
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Los Angeles CA

Re: Internal ProRes RAW for Pyxis?

PostSat Feb 22, 2025 11:19 pm

In what way do you see the current BRAW codec not being raw?

Serious question.

How is it actually not raw enough for you? What does that mean in terms of images? Where are you seeing it? What types of shots?

JB
John Brawley ACS
Cinematographer
Los Angeles
Offline
User avatar

Alex Mitchell

  • Posts: 356
  • Joined: Tue Mar 18, 2014 5:32 pm

Re: Internal ProRes RAW for Pyxis?

PostSun Feb 23, 2025 3:35 am

John Brawley wrote:What does that mean in terms of images?

See below?
Will Vazquez wrote:I've witnessed the softening of the image when BMD went from Cinema DNG to BRAW years ago. I love a lot of aspects of BRAW, but not the plastic looking image.

Personally, I'm on the fence about this. I have done a lot of A/B comparisons between BRAW and CinemaDNG, and while I do find that the CinemaDNG pipeline produces images that have a higher perceptual sharpness and do retain marginally more detail, a lot of that "sharpness" is heightened edge contrast and aliasing. To my eye, I don't think there's enough of a difference in motion to really warrant much fuss. I totally see where you're coming from though and sympathize.
Will Vazquez wrote:Is there any chance that Blackmagic can license true internal BRAW from Nikon for their cameras? Perhaps they can develop a new BRAW2 codec that features the true RAW.

Anything is possible but I really, really don't think so. BMD has now developed camera sensors that leverage technologies unique to BRAW, so I kinda doubt they're gonna abandon that just to meet some arbitrary standard of what qualifies as "raw". Image quality aside, it also bears mentioning that BRAW is an incredibly efficient codec too—both in terms of its resiliency to compression and its computational requirements on the post side—and that has always been a selling point for BMD. You'd be missing out on that without the extra in-camera processing that happens with existing BRAW.

So yeah, I kinda wish there was more of that clarity you miss from CinemaDNG in BRAW, but I also think that what you're talking about are the growing pains. It feels like BRAW performs best with the RGBW sensors in the 12K Mini, 12K Cine, and 17K bodies, but does introduce a little extra softness in a typical Bayer pattern sensor. Maybe some day BMD will have an entire lineup of RGBW sensors and this'll all just be a memory...
Offline

ShaheedMalik

  • Posts: 1560
  • Joined: Wed Aug 19, 2020 5:28 am
  • Real Name: Shaheed Malik

Re: Internal ProRes RAW for Pyxis?

PostSun Feb 23, 2025 4:54 am

Ehh. They are comparing uncompressed raw to BRAW.

ProRes Raw is a waste.
Offline

John Brawley

  • Posts: 4499
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Los Angeles CA

Re: Internal ProRes RAW for Pyxis?

PostSun Feb 23, 2025 5:52 am

Ohh the great mythology of DNG being sharper than BRAW.

Maybe. Or maybe it’s because of the lack of OLPF and all the extra false impression of sharpness because of FALSE resolution that leads to an impression of a sharper image?

None of those cameras had OLPF. I wonder if they did like they do now, would the sharpness have the same perceptual difference? I suspect that they would.

People used to also say that ProRes looked softer than DNG. Likely the compression and sample size blurring out that false information from the uncompressed DNG.

I just don’t understand the language of raw / pure raw. What does that actually mean? It’s being used as language in a pejorative way but I still don’t see anyone saying how ProRes RAW would be better for being somehow more pure.

JB
John Brawley ACS
Cinematographer
Los Angeles
Offline
User avatar

Jamie LeJeune

  • Posts: 2084
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Internal ProRes RAW for Pyxis?

PostSun Feb 23, 2025 11:32 am

John Brawley wrote:I still don’t see anyone saying how ProRes RAW would be better for being somehow more pure.
That is an excellent question.

It's also worth noting that BRAW has a number of advantages over ProRes RAW:
- more tone curve and gamut options built into the SDK
- the option to enable or disable highlight recovery
- the option to enable or disable gamut compression
- the option to embed custom 3D LUTs as metadata
- easily scripted JSON format sidecar files that can control all those options
- more compression options
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

WahWay

  • Posts: 1029
  • Joined: Tue Apr 07, 2020 11:54 am
  • Real Name: Simon Chan

Re: Internal ProRes RAW for Pyxis?

PostSun Feb 23, 2025 12:19 pm

ProAV did a test on the Ursa Cine 12k LF in 4k mode and it preserve details much more than the Pyxis 6K at 6k mode so the way Braw deals with RGBW sensor differs in the way it handles other sensors and it could be why Braw will probably never challenge Prores RAW unless more manfacturers develop RGBW sensors but this a BMD developed sensor so that is unlikely to happen. Maybe the next genration of Braw find a way?
Offline
User avatar

rick.lang

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

Re: Internal ProRes RAW for Pyxis?

PostSun Feb 23, 2025 4:17 pm

WahWay wrote:ProAV did a test on the Ursa Cine 12k LF in 4k mode and it preserve details much more than the Pyxis 6K at 6k mode so the way Braw deals with RGBW sensor differs in the way it handles other sensors…


Jamie’s list above could be augmented with the ability of BRAW on RGBW sensors to retain detail with the full sensor field of view providing multiple lower resolutions without traditional line skipping or binning. This is special, applied to both 12K and 17K sensors.
Rick Lang
Offline
User avatar

Jamie LeJeune

  • Posts: 2084
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Internal ProRes RAW for Pyxis?

PostSun Feb 23, 2025 11:07 pm

rick.lang wrote: Jamie’s list above could be augmented with the ability of BRAW on RGBW sensors to retain detail with the full sensor field of view providing multiple lower resolutions without traditional line skipping or binning. This is special, applied to both 12K and 17K sensors.
Thank you Rick! I can't believe I neglected to list that one!
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Mark Grgurev

  • Posts: 958
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Internal ProRes RAW for Pyxis?

PostMon Feb 24, 2025 2:55 am

John Brawley wrote:Ohh the great mythology of DNG being sharper than BRAW.

Maybe. Or maybe it’s because of the lack of OLPF and all the extra false impression of sharpness because of FALSE resolution that leads to an impression of a sharper image?

None of those cameras had OLPF. I wonder if they did like they do now, would the sharpness have the same perceptual difference? I suspect that they would.


I remember seeing comparisons between compressed DNG and BRAW on the UMP 4.6K where it was evident that DNG was sharper.

John Brawley wrote:People used to also say that ProRes looked softer than DNG. Likely the compression and sample size blurring out that false information from the uncompressed DNG.


False information?

John Brawley wrote:I just don’t understand the language of raw / pure raw. What does that actually mean? It’s being used as language in a pejorative way but I still don’t see anyone saying how ProRes RAW would be better for being somehow more pure.

JB


ProRes RAW is actually RGB (or RGBW) data while BRAW converts to YCbCr before compression. That's likely what BMD was referring to when they said the RGBW sensor was "made for BRAW". With only RGB channels, the luma and chroma information needs to derived from them which means that even before compression, none of the channels are 100% representative of what the camera recorded. For mosaicked RGB data, that requires debayering first however, if you have a W channel than it's information is directly usable by the Y channel without modification.

Other than that, people have done tests between BRAW and Prores RAW using external recorders and found that Preres RAW is noisier and thus preserves more detail.
Offline

Mark Grgurev

  • Posts: 958
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Internal ProRes RAW for Pyxis?

PostMon Feb 24, 2025 3:17 am

Alex Mitchell wrote:Personally, I'm on the fence about this. I have done a lot of A/B comparisons between BRAW and CinemaDNG, and while I do find that the CinemaDNG pipeline produces images that have a higher perceptual sharpness and do retain marginally more detail, a lot of that "sharpness" is heightened edge contrast and aliasing. To my eye, I don't think there's enough of a difference in motion to really warrant much fuss. I totally see where you're coming from though and sympathize.


Unless you're suggesting that sharpening was done prior to compression or comparison, "heightened edge contrast" is exactly what sharpness is.

Alex Mitchell wrote:Anything is possible but I really, really don't think so. BMD has now developed camera sensors that leverage technologies unique to BRAW, so I kinda doubt they're gonna abandon that just to meet some arbitrary standard of what qualifies as "raw". Image quality aside, it also bears mentioning that BRAW is an incredibly efficient codec too—both in terms of its resiliency to compression and its computational requirements on the post side—and that has always been a selling point for BMD. You'd be missing out on that without the extra in-camera processing that happens with existing BRAW.


My last post talks about the part I bolded in this snippet of your post but having a W pixel isn't really a unique concept in camera sensor they just aren't typical.

Also while the RGBW sensor maps to YCbCr slightly better, that doesn't help with any of their other cameras and it wouldn't put other RAW codecs at a disadvantage. A RAW codec that doesn't require in-camera de-mosaicking just stores sensor data as it was recorded: as a single channel. It doesn't really care about the color filter that was used. It also looks the same to it. As long as the software that decodes it is aware of how to demosaic it, it's fine.

The RGBW sensor might work better for BRAW than an RGB sensor since the Y channel can use the W photosites without modification, but that doesn't mean that the best RAW codec for it is BRAW. RAW codecs that don't convert to YCBCR can use the data from all of the photosites without modification.
Offline

Mark Grgurev

  • Posts: 958
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Internal ProRes RAW for Pyxis?

PostMon Feb 24, 2025 3:27 am

rick.lang wrote:Jamie’s list above could be augmented with the ability of BRAW on RGBW sensors to retain detail with the full sensor field of view providing multiple lower resolutions without traditional line skipping or binning. This is special, applied to both 12K and 17K sensors.


The ability of the sensor to record at lower resolutions without line-skipping or cropping has nothing to do with the codec at all and everything to do with how the sensor does it's readout. Much like with cropping, when the 12K records 8K, only an 8K-images-worth of data is coming out of the sensor. That's why recording at 8K is has a faster readout speed than 12K.

Nothing would change if the 12K and 17K used ProRes RAW or some other RAW codec. Also using RGBW doesn't uniquely allow the sensor to downsample during readout. That can be done with bayer sensors as well and some bayer sensors do that. RGBW has advantages on its own and uniquely helps BRAW.
Offline

Will Vazquez

  • Posts: 198
  • Joined: Thu Mar 30, 2017 7:40 pm

Re: Internal ProRes RAW for Pyxis?

PostTue Feb 25, 2025 3:25 am

John Brawley wrote:

How is it actually not raw enough for you? What does that mean in terms of images? Where are you seeing it? What types of shots?

JB


Everything is about subtleties. The difference between the rendering of an Alexa LF vs a Sony FX3 is maybe 5%. But that 5% is the magic pixie dust. To my eye, I preferred the look of Cinema DNG images from my old Pocket 4K over the images that were recorded in BRAW. It lost a little pixie dust to my eye when I upgraded the firmware. There was a more organic look that I preferred.

As I understand, RAW recording is when RAW sensor data is recorded directly from the sensor. ProRes compresses and records RAW sensor data. I heard Grant Petty say that BRAW is partially de-bayered from the RAW sensor data before compressing and recording. So thus it would not be true RAW.

Because RED cameras record RAW sensor data, when they went to the IPP2 color pipeline, you could develop footage recorded years prior and there was a dramatic improvement in color and image quality to even footage from old cameras.

I don't necessarily want ProRes RAW, but maybe if they licensed from Nikon they could make a BRAW2 that is RAW sensor data. What I really want is a more textured, organic look that I feel Blackmagic cameras have lost since going BRAW.
Offline

John Brawley

  • Posts: 4499
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Los Angeles CA

Re: Internal ProRes RAW for Pyxis?

PostTue Feb 25, 2025 3:38 am

If RED compresses the file then it’s not pure raw either.

The RED IP relates only to a compressed version of raw.

So other than saying DNG was sharper (which I’m certain is for other reasons) and also by the way was uncompressed or less compressed than REDCODE….

Semantics?

Is that it?

What is pure raw?

It’s a myth. You think uncompressed Arri is pure raw? It’s not. It’s not data direct from the sensor. That’s a gross simplification. There is a bunch of image processing happening you have no control over. Dead pixels are mapped out. Calibration is applied per sensor to make them appear to be generating a similar spec out the box. Some kind of Arri texture is added on the latest workflow (there isn’t an option to not have it)

It’s marketing speak. It’s like saying fresh frozen.

JB
John Brawley ACS
Cinematographer
Los Angeles
Offline
User avatar

Uli Plank

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

Re: Internal ProRes RAW for Pyxis?

PostTue Feb 25, 2025 6:57 am

Not to forget that your sensor is linear, but always converted to log. Which is already some data loss in theory, but better adapted to how our eyes perceive light intensity. The last time I’ve seen linear straight out of a camera was with a very early version of RedCine-X, where you could switch.
My disaster protection: export a .drp file to a physically separated storage regularly.
www.digitalproduction.com

Studio 19.1.3
MacOS 13.7.4, 2017 iMac, 32 GB, Radeon Pro 580 + eGPU
MacBook M1 Pro, 16 GPU cores, 32 GB RAM, MacOS 14.7.2
SE, USM G3
Offline

Mark Grgurev

  • Posts: 958
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Internal ProRes RAW for Pyxis?

PostTue Feb 25, 2025 8:06 am

John Brawley wrote:If RED compresses the file then it’s not pure raw either.

The RED IP relates only to a compressed version of raw. .. Semantics? Is that it? What is pure raw? It’s a myth. ... It’s marketing speak. It’s like saying fresh frozen.

Yes, you could argue that any lossy compressed RAW isn't real RAW and only uncompressed or losslessly compressed RAW, like CDNG, is real RAW. However, because BRAW debayers and converts to Ycbcr, it is further from RAW than codecs that don't do that.

I've seen examples where BRAW introduced haloing in the color channels that CDNG didn't have. The same haloing was also introduced with ProRes which is also YCbCr.

Another thing that can consider is that the color filter array is completely irrelevant to BRAW because it's going to do the demosaicking of the sensor data in-camera and converted to its own format anyway. By the time it gets to the decoder, the color filter doesn't matter any more. It has no idea if it's luma channel was derived from RGBG data or an RGBW data and it can't determine what data was derived from the W pixels and the chroma pixels as they've been combined.

An actual RAW codec would require the decoder to know the pixel layout in order to decode it properly. This brings with it the benefit of being able to choose the de-mosaicking algorithm in post. Also through de-mosiacking, RGBW data would produce two luma channels that are exposed slightly differently. If this is done in-camera before compression then it will only be a 12-bit luma channel. If the two channels are derived in post then they can be summed into a 13-bit luma channel.

John Brawley wrote:So other than saying DNG was sharper (which I’m certain is for other reasons) and also by the way was uncompressed or less compressed than REDCODE….

I've seen examples where 3:1 compressed DNG was still sharper than BRAW, too. Btw, when BMD's cameras could record CDNG, they were always using compression, even when shooting at ratios above 3:1 it was just lossless which means the compression ratio was dynamic.

John Brawley wrote:You think uncompressed Arri is pure raw? It’s not. It’s not data direct from the sensor. That’s a gross simplification. There is a bunch of image processing happening you have no control over. Dead pixels are mapped out. Calibration is applied per sensor to make them appear to be generating a similar spec out the box. Some kind of Arri texture is added on the latest workflow (there isn’t an option to not have it)

Even if that were true, does any of that matter when Arri RAW is still much closer to the actual sensor data than BRAW? Sure, dead pixels are mapped out and there may be some calibration as well but those things can be stored as additional metadata. They don't necessarily infer that data was modified after recording and before encoding. In some cases, the calibration may be at the sensor level before the readout phase so it will still very much be real RAW data.
Offline

Mark Grgurev

  • Posts: 958
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Internal ProRes RAW for Pyxis?

PostTue Feb 25, 2025 8:12 am

Uli Plank wrote:Not to forget that your sensor is linear, but always converted to log. Which is already some data loss in theory, but better adapted to how our eyes perceive light intensity. The last time I’ve seen linear straight out of a camera was with a very early version of RedCine-X, where you could switch.


Unless I'm mistaken, the conversion to log happens during the readout so there's no real data loss. I don't see how there would be any advantage in converting to log after the analog-to-digital conversion as that defeats the whole purpose of shooting log.
Offline
User avatar

carlomacchiavello

  • Posts: 3062
  • Joined: Tue Aug 28, 2012 6:04 pm
  • Location: italy

Re: Internal ProRes RAW for Pyxis?

PostTue Feb 25, 2025 9:03 am

Have you tried braw Q0?
I often do shooting photo using pocket6k like super high speed photo cam, and I did many comparisons between dng uncompressed shooted from camera and q0 videos and difference is so thin that no one saw in a large print or in videos 4k.

Are you sure that you have did comparison with latest cam and latest braw compression?

Here you can see some photo done with cc6k which I rent to test it, at today I only had pocket 6k

https://www.macchiavello.com/wp/it/blac ... era-6k-ff/

I had another post where you can download photo dng and braw to verify how are very near to be not necessary the cdng.
Check on

https://www.macchiavello.com/wp/it/foto ... cineprese/


Inviato dal mio iPhone utilizzando Tapatalk
Offline
User avatar

Robert Niessner

  • Posts: 5627
  • Joined: Thu Feb 21, 2013 9:51 am
  • Location: Graz, Austria

Re: Internal ProRes RAW for Pyxis?

PostTue Feb 25, 2025 9:56 am

Mark Grgurev wrote:
John Brawley wrote:Ohh the great mythology of DNG being sharper than BRAW.

Maybe. Or maybe it’s because of the lack of OLPF and all the extra false impression of sharpness because of FALSE resolution that leads to an impression of a sharper image?

None of those cameras had OLPF. I wonder if they did like they do now, would the sharpness have the same perceptual difference? I suspect that they would.


I remember seeing comparisons between compressed DNG and BRAW on the UMP 4.6K where it was evident that DNG was sharper.


I've made the comparison back then here, 6 years ago:
viewtopic.php?f=2&t=91802
Saying "Thx for help!" is not a crime.
--------------------------------
Robert Niessner
LAUFBILDkommission
Graz / Austria
--------------------------------
Blackmagic Camera Blog (German):
http://laufbildkommission.wordpress.com

Read the blog in English via Google Translate:
http://tinyurl.com/pjf6a3m
Offline
User avatar

Akpe Ododoru

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

Re: Internal ProRes RAW for Pyxis?

PostTue Feb 25, 2025 11:10 am

I have graded ArriRaw on the same timeline as BRAW, and there was nothing i could do with ArriRaw i could not do to BRAW (same with R3D files).
I really do not care about the ones and zeros that make up the file format, as long as it gives me ALL the advantages of RAW files, then thats RAW enough for me.
1) It allows me adjust my WB in post
2) It allows me adjust my ISO in post
3) Its a 12bit images that grades so well
What more can any RAW file (ArriRaw, R3D, CDNG) do that BRAW can't do?
It doesn't make it better just bcus you have to zoom in 800% to notice CDNG is sharper. The Dji Inspire 2 is also sharper than an arri image when zoomed in at 800% (test was done on CineD website years ago), does that mean its better than an Arri?
I did notice though that BRAW grades far better and easier than the previous CDNG files.
Akpe Ododoru
Cinematographer
London
www.akpe.co.uk
Offline
User avatar

Johannes Jonsson

  • Posts: 457
  • Joined: Mon May 01, 2017 2:35 pm
  • Location: Iceland

Re: Internal ProRes RAW for Pyxis?

PostTue Feb 25, 2025 11:41 am

The main difference I had seen between BRAW and DNG is when when I did a test on Chroma key shot on the same camera I saw that in really fine details like in hair the DNG came out better in those details, my guess is that some denoising in BRAW is the cause of that
Johannes
Davinci Resolve Studio 19.1
Fusion Studio 19.1
Intel i7 14700K
128GB RAM
Nvidia RTX 4070 Ti Super 16gb
Offline

Mark Grgurev

  • Posts: 958
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Internal ProRes RAW for Pyxis?

PostTue Feb 25, 2025 3:25 pm

Robert Niessner wrote:I've made the comparison back then here, 6 years ago:
viewtopic.php?f=2&t=91802

Yup! That's one of the groups of tests I recalled. I also remember seeing two other tests: one of with a green screen and one with a red cloth.

Johannes Jonsson wrote:The main difference I had seen between BRAW and DNG is when when I did a test on Chroma key shot on the same camera I saw that in really fine details like in hair the DNG came out better in those details, my guess is that some denoising in BRAW is the cause of that

It's either de-noising or a result of the haloing that can occur.

Akpe Ododoru wrote:I have graded ArriRaw on the same timeline as BRAW, and there was nothing i could do with ArriRaw i could not do to BRAW (same with R3D files).

I agree that BRAW gets you like 99% of the advantage of other RAW formats. I'm not here to say that BRAW is bad or anything but if another RAW codec gets better quality with similar file sizes and you have the option for that then why wouldn't you use that?

Where you're more likely to notice differences is when green screening or when trying to clean up noisy footage. For one reason or another, BRAW seems to have less noise than other codecs which is undesirable in a RAW codec because it means detail was destroyed that you can't get back.

It's important to remember that with pristine footage where the shot is well-lit and the the dynamic range of the scene fits well within the dynamic range of the camera's sensor, even the difference between 10-bit h.265 and BRAW won't seem as big as it actual is. When judging RAW codecs, you need to compare them stressing scenarios.

shows that by Neatvideo's metric for measuring noise, BRAW has about half as much noise as Prores RAW which means Prores RAW will get you cleaner footage and thus better dynamic range when shooting low-light footage or exposing to protect highlights in high-dynamic range shots.

Akpe Ododoru wrote:What more can any RAW file (ArriRaw, R3D, CDNG) do that BRAW can't do?


That's difficult to know when you often don't have the option of what RAW codec you can shoot on a camera. Like I said before, with the way the 12K's RGBW filter works, you might be leaving some dynamic range on the table with BRAW that could potentially be preserved with other RAW codecs. It may not be enough to matter to you as you can't miss what you didn't know existed but if you're shooting in a situation that stressing the camera's DR you're gonna want that. On cameras that use bayer filters there may be less of an advantage.

Akpe Ododoru wrote:It doesn't make it better just bcus you have to zoom in 800% to notice CDNG is sharper. The Dji Inspire 2 is also sharper than an arri image when zoomed in at 800% (test was done on CineD website years ago), does that mean its better than an Arri?


When everything else is the same but using one codec gets you more detail than the other, then yes, it's better in measurable way. I'm not sure why you're bringing up cross camera comparisons as that's not what anybody is talking about.

Also sometimes you're literally viewing zoomed-in footage ion final product. If you need to shoot slow motion, a majority of BMD's cameras require you to crop below 4K, sometimes as low as 1080p. You're going to want to preserve any detail you can knowing that it will be blown up and cut alongside 4K footage.

Akpe Ododoru wrote:I did notice though that BRAW grades far better and easier than the previous CDNG files.


I don't think there can be any real truth to that. There's nothing about BRAW that would make it grade any better than CDNG. I believe there was a change in color science at the same time that BMD's cameras switched from CDNG to BRAW but that has nothing to do with the codec.
Offline
User avatar

rick.lang

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

Internal ProRes RAW for Pyxis?

PostTue Feb 25, 2025 3:37 pm

I always record CinemaDNG lossless original UM4.6K camera (Gen4) alongside the BMPCC4K (Gen5). In Resolve Camera raw tab, I can select Gen4 so the BMPCC4K footage should match the UM4.6K colour science.
Last edited by rick.lang on Wed Feb 26, 2025 12:03 am, edited 1 time in total.
Rick Lang
Offline
User avatar

carlomacchiavello

  • Posts: 3062
  • Joined: Tue Aug 28, 2012 6:04 pm
  • Location: italy

Re: Internal ProRes RAW for Pyxis?

PostTue Feb 25, 2025 4:01 pm

Just a quick note, why do you want to record in a format [ProresRaw] that you cannot handle inside daVinci?
you should convert before to manage in a less confortable sequence of cdng.
Offline

John Brawley

  • Posts: 4499
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Los Angeles CA

Re: Internal ProRes RAW for Pyxis?

PostTue Feb 25, 2025 7:18 pm

BRAW is 100% better than DNG.

Only because of the workflow.

No one is going to be able to playback a 12k uncompressed DNG for starters. It’s a very inefficient codec as far as workflow and there is little consistency in the way they are decoded. It’s still a pain everytime I shoot DNG to get post to handle them correctly and consistently. Let alone what happens when you do VFX pulls. Plus there’s no metadata, LUT side car type advantages either.

That’s what’s silly about making these kinds of arguments.

The only single true difference that maybe you can argue makes raw not so pure that no one has mentioned is the ability to de-mosaic with a different algorithm. No one even mentioned this until now. I was waiting.

In practice this actually doesn’t seem to make much difference in the real world. Many tools don’t even offer the ability to choose different algorithms.

The whole YUV argument is misunderstood. Yes there is a transform but if you read the patent there’s a transform back again to reconstruct the photosite data. That is how they don’t infringe the RED ip. It’s like LIN to LOG back to Lin. Those kinds of transforms are more mathematical.

To me raw means

Can I set the WB layer?
Can I set the ISO layer?
Can I re-process the footage?

Braw is two of those three. The third one I’ve never ever seen done professionally. BRAW could be described as raw like at worst.

I’m on a show right now that is shooting BRAW as the main codec. It’s for a major studio for a major streamer and they did EXTENSIVE testing to vet the codec for archival and IQ approval. Netflix have also done something similar with their approval process.

On blind testing with legit engineering QA people really trying to pick the difference between Q0 and Q5, none got it right visually even at 400% blow up. Even after we started to help them by doing keys and looking at mattes none were able to pick the difference.

BRAW is incredibly efficient, especially when dealing with high resolution files, is functional on shows that shoot a lot of footage everyday (I shot more than 8 hours yesterday) and there’s is no advantage whatsoever if this was uncompressed or DNG. In fact we couldn’t use BMDs camera if that was the only option.

There’s no argument that ProRes raw is better.
There’s no realistic argument to say DNG is better in any meaningful pragmatic way.

JB
John Brawley ACS
Cinematographer
Los Angeles
Offline

Tom Roper

  • Posts: 648
  • Joined: Sat Apr 14, 2018 4:59 pm
  • Real Name: Tom Roper

Re: Internal ProRes RAW for Pyxis?

PostTue Feb 25, 2025 9:17 pm

ProRes RAW is for use with Apple's ecosystem, macOS and Apple Silicon (M1) devices, where it benefits from hardware acceleration. ProRes RAW is tightly integrated into Final Cut Pro. It's less complex and good if you don’t need granular control over the debayering process.

Metadata-driven editing is a feature of BRAW that lets you tweak the raw data based on the camera settings stored in the file. BRAW is cross-platform, working seamlessly on Windows, macOS, and Linux, and other Blackmagic hardware.

Neither one is objectively superior; it’s all about the best fit for your workflow. This much can be said with certainty; BMD is focused on expanding its corner of the post edit universe as is Apple. Don't look for BMD to be assisting Apple's ambition by allowing its great cameras to be a transfer portal to the Apple ecosystem.
Offline

Mark Grgurev

  • Posts: 958
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Internal ProRes RAW for Pyxis?

PostWed Feb 26, 2025 8:32 am

carlomacchiavello wrote:Just a quick note, why do you want to record in a format [ProresRaw] that you cannot handle inside daVinci?

That's simple enough. Davinci would just add support for Prores RAW. Premiere supports it.

John Brawley wrote:BRAW is 100% better than DNG.

Only because of the workflow.

No one is going to be able to playback a 12k uncompressed DNG for starters. It’s a very inefficient codec as far as workflow and there is little consistency in the way they are decoded. It’s still a pain everytime I shoot DNG to get post to handle them correctly and consistently. Let alone what happens when you do VFX pulls. Plus there’s no metadata, LUT side car type advantages either.


You seem to be misunderstanding some stuff about CDNG.

First I'll repeat again that the version of CDNG that before BMD switched their cameras to BRAW, none of their cameras shot uncompressed CDNG. Even the original Pocket shot losslessly compressed CDNG. It was only about a 1.5:1 compression ratio on average but it was compressed. That's why each frame took up a different amount of storage. If they were uncompressed then each frame would be the same size. Also BMD themselves extended the format to add lossy compression and newer forms of compression could still be added now.

I have no idea what you're talking about when you say there's little consistency in how they're decoded.

Also you said there's no metadata? You know that isn't true since slate, ISO, and WB metadata was available since the BMD's first camera. CDNG is based off DNG which is used for RAW so off course it can store metadata.

Also the way that BMD used CDNG isn't the only way CDNG could be used. CinemaDNG clips can be stored as a folder full of DNGs like BMD did or it can be stored in an MXF container which itself supports metadata. CDNG also incorporates XMP metadata so you could use sidecar files. So you can have per-file and per-frame metadata as well as support for sidecar files just like BRAW.

Before BRAW I remember voicing that BMD should add the ability to record CDNG as MXF files. Using MXF files would have reduced CPU load a little because it wouldn't need to get file descriptors for each frame and it would have used up less space because slate data could be stored per-clip instead of per frame and it would leave way fewer file system blocks with un-used space.

You should actually read about the format.
https://en.wikipedia.org/wiki/CinemaDNG

John Brawley wrote:The only single true difference that maybe you can argue makes raw not so pure that no one has mentioned is the ability to de-mosaic with a different algorithm. No one even mentioned this until now. I was waiting.

In practice this actually doesn’t seem to make much difference in the real world. Many tools don’t even offer the ability to choose different algorithms.

I was gonna mention it but I knew you'd shoot it down as irrelevant because BMD never offered a way to use different algorithms.

John Brawley wrote:The whole YUV argument is misunderstood. Yes there is a transform but if you read the patent there’s a transform back again to reconstruct the photosite data.

Wrong.

Think of what it's doing to the sensor data of the 12K. That's four 12-bit channels (R,G,B,W) which are being de-mosaicked, the RGB data is being transformed into Ycbcr, then the W channel is combined with the luma channel. In the end you have just three 12-bit channels. You already can't reconstruct the photosite data from that.

On top of that, the patent even says that it's converted to Ycbcr420 data so the color channels are 1/4th the resolution of the luminance channel.

John Brawley wrote:It’s like LIN to LOG back to Lin. Those kinds of transforms are more mathematical.

No it's not.

John Brawley wrote:To me raw means

Can I set the WB layer?
Can I set the ISO layer?

Braw is two of those three. The third one I’ve never ever seen done professionally. BRAW could be described as raw like at worst.

WB and ISO layers? Also why would the WB and ISO settings make something a RAW codec? The WB and ISO settings are just metadata that instruct the decoder to apply certain gamma curves to the footage. As long as the ISO curve and WB aren't baked into the data then you do the exact same adjustments without those dropdowns.

BRAW is a 12-bit YCbCr420 high-bitrate codec. That's really it. Those existed before BRAW and nobody ever called them RAW-like.

John Brawley wrote:I’m on a show right now that is shooting BRAW as the main codec. It’s for a major studio for a major streamer and they did EXTENSIVE testing to vet the codec for archival and IQ approval. Netflix have also done something similar with their approval process.

On blind testing with legit engineering QA people really trying to pick the difference between Q0 and Q5, none got it right visually even at 400% blow up. Even after we started to help them by doing keys and looking at mattes none were able to pick the difference.
...
There’s no argument that ProRes raw is better.

The emboldened text is the whole point of that topic.

It's great that Q0 and Q5 look very similar. That's bound to be the case when you're still talking about very high bitrates. However when compared to an actual RAW codec like ProRes RAW, its lower quality despite having comparable bitrates.

John Brawley wrote:BRAW is incredibly efficient, especially when dealing with high resolution files, is functional on shows that shoot a lot of footage everyday (I shot more than 8 hours yesterday) and there’s is no advantage whatsoever if this was uncompressed or DNG. In fact we couldn’t use BMDs camera if that was the only option.

There’s no realistic argument to say DNG is better in any meaningful pragmatic way.

Well, no. The fact that CDNG is higher quality than BRAW is a realistic argument. You can't handwave that away. Sure, no camera has offered 12:1 compression of CDNG but that doesn't mean it can't do it or that it's inefficient. The general rule of thumb is that people will shoot BRAW at something like Q0 or 3:1 when shooting for VFX. You know what else supports 3:1 compression? Cinema DNG.

When given a choice between the two, BRAW will be fine for most scenarios but there is a reason why someone would choose CDNG over it.
Offline

Mark Grgurev

  • Posts: 958
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Internal ProRes RAW for Pyxis?

PostWed Feb 26, 2025 8:58 am

Tom Roper wrote:ProRes RAW is for use with Apple's ecosystem, macOS and Apple Silicon (M1) devices, where it benefits from hardware acceleration. ProRes RAW is tightly integrated into Final Cut Pro. It's less complex and good if you don’t need granular control over the debayering process.


Between BRAW and Prores RAW, the only format where you could conceivably control the debayering process is Prores RAW.

Tom Roper wrote:Metadata-driven editing is a feature of BRAW that lets you tweak the raw data based on the camera settings stored in the file.


Why do you think that Prores RAW doesn't support metadata? Most file formats support metadata, that's not unique to BRAW.

Tom Roper wrote:BRAW is cross-platform, working seamlessly on Windows, macOS, and Linux, and other Blackmagic hardware.


Fair point that Prores RAW doesn't run on Linux. It does work on Windows though and the fact that Blackmagic hardware doesn't have it doesn't mean much because the whole point of this topic is fixing that.

Tom Roper wrote:Neither one is objectively superior; it’s all about the best fit for your workflow. This much can be said with certainty; BMD is focused on expanding its corner of the post edit universe as is Apple. Don't look for BMD to be assisting Apple's ambition by allowing its great cameras to be a transfer portal to the Apple ecosystem.


Blackmagic constantly showcases Apple's hardware. Every time they demonstrate Resolve it's on a Mac and BMD was among the first software developers to support ARM Macs. They even have a version of Resolve for iPad. BMD's Immersive camera was made specifically for creating content for Apple Vision Pro. Apple has also showcased Resolve running on Macs. BMD has always loved Apple's ecosystem and they have an official partnership.

BMD isn't going to drive people to Apple's ecosystem any more than they currently are just by supporting ProRes RAW. If anything people would be drawn to Resolve who currently only use FCP to edit ProRes RAW.
Offline
User avatar

Robert Niessner

  • Posts: 5627
  • Joined: Thu Feb 21, 2013 9:51 am
  • Location: Graz, Austria

Re: Internal ProRes RAW for Pyxis?

PostWed Feb 26, 2025 1:55 pm

Mark Grgurev wrote:That's simple enough. Davinci would just add support for Prores RAW. Premiere supports it.


If that would be simple enough then we already would have ProRes RAW support in Resolve.
As Resolve does support a vast range of other RAW Formats from competitors the only conclusion for me is that somehow Apple doesn't wants them to.

Mark Grgurev wrote:You seem to be misunderstanding some stuff about CDNG.

First I'll repeat again that the version of CDNG that before BMD switched their cameras to BRAW, none of their cameras shot uncompressed CDNG. Even the original Pocket shot losslessly compressed CDNG. It was only about a 1.5:1 compression ratio on average but it was compressed. That's why each frame took up a different amount of storage. If they were uncompressed then each frame would be the same size. Also BMD themselves extended the format to add lossy compression and newer forms of compression could still be added now.


Originally the BMCC only had uncompressed CDNG, later with firmware 1.8 or 1.9 (afair) it got lossless compression which reduces file sizes to 50%-60%. And I had several tools which could not read compressed DNGs.

Mark Grgurev wrote:I have no idea what you're talking about when you say there's little consistency in how they're decoded.


I think he means that BRAW has an SDK making sure decoding is standardized, while CDNG isn't and every tool can use its own method for decoding.

Mark Grgurev wrote:Also you said there's no metadata? You know that isn't true since slate, ISO, and WB metadata was available since the BMD's first camera. CDNG is based off DNG which is used for RAW so off course it can store metadata.


There is more metadata needed than slate, ISO and WB.
I just checked out what metadata gets stored in old 2018 DNG files from my BMCC:
Slate
Date Recorded
Camera #
Timecode
Start / End frame / Bit Depth
Field Dominance
Data Level
Audio Channels / Bit Depth
Camera Type
Camera ID

BRAW adds:
Clip #
Camera FPS
Shutter Type
Shutter
ISO
WB
Camera Firmware
LUT used
Lens Type
Camera Aperture
Focal Point
Distance
ND Filter
Compression Ratio
Codec Bitrate
Gamma / Colorspace Notes


Mark Grgurev wrote:On top of that, the patent even says that it's converted to Ycbcr420 data so the color channels are 1/4th the resolution of the luminance channel.


You are aware that a Bayer sensor does only have 1/4 of red and blue and 1/2 of green sensels?
That's the trick here.

Mark Grgurev wrote:
John Brawley wrote:To me raw means

Can I set the WB layer?
Can I set the ISO layer?

Braw is two of those three. The third one I’ve never ever seen done professionally. BRAW could be described as raw like at worst.

WB and ISO layers?


I guess it should read as "later" instead of "layer".

Mark Grgurev wrote:Also why would the WB and ISO settings make something a RAW codec? The WB and ISO settings are just metadata that instruct the decoder to apply certain gamma curves to the footage. As long as the ISO curve and WB aren't baked into the data then you do the exact same adjustments without those dropdowns.

BRAW is a 12-bit YCbCr420 high-bitrate codec. That's really it. Those existed before BRAW and nobody ever called them RAW-like.


I think you should re-read the patent. If what you said was true, then we should get the same out of ProRes files when doing color manipulations - but that isn't the case. For example I have shots with lots of those saturated LEDs - I can get so much more out of BRAWs than from ProRes files.
Saying "Thx for help!" is not a crime.
--------------------------------
Robert Niessner
LAUFBILDkommission
Graz / Austria
--------------------------------
Blackmagic Camera Blog (German):
http://laufbildkommission.wordpress.com

Read the blog in English via Google Translate:
http://tinyurl.com/pjf6a3m
Offline
User avatar

rick.lang

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

Re: Internal ProRes RAW for Pyxis?

PostWed Feb 26, 2025 2:37 pm

It appears BMD has abandoned ProRes recording on its most recent cameras and that trend is not likely to reverse itself and see renewed support for ProRes. Speculation is that ProRes recording in camera requires a license to Apple’s benefit and that Apple also still must approve each actual implementation of a ProRes codec. Clearly BMD has had enough of that cost and process. Perhaps that also affects BMD’s lack of embrace of ProRes raw which comes with its own baggage. I agree with Tom that it’s not going to happen so, having stated your case, it’s time to rest your case.

At least BMD makes its proprietary BRAW freely available as I understand it so they’re not following the limitations of a ProRes-like business model. Even DaVinci Resolve Studio is virtually free as a license is included with the purchase of so many of BMD’s products. BMD’s business model is driven by hardware sales more than software sales. That’s also true of Apple in terms of hardware sales driving revenue historically while they abandoned charging for their operating systems.

If BMD chooses to decline to include support for ProRes raw in their cameras and their software, it’s their business decision. BMD certainly supports Apple in so many other ways as you know. As John has mentioned, with regard to the more onerous task of managing CinemaDNG versus the relative ease of working with BRAW, however common ProRes may be, including an indispensable feature of ARRI digital cameras, BMD has chosen to rely upon BRAW for its new high resolution cameras for which I don’t believe there is even an option from Apple to support ProRes 12K or 17K codecs. Resolve fully supports all flavours of ProRes and doesn’t want to support ProRes raw. Their decision.

Technical arguments on behalf of ProRes raw are like bringing a knife to a gunfight, meaning they are just irrelevant to changing the inevitable conclusion. Personally the business practices of most other successful companies are many times more abhorrent than this BMD strategic direction, so I can live without ProRes raw in my cameras. accessories, and software.
Rick Lang
Offline
User avatar

rick.lang

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

Re: Internal ProRes RAW for Pyxis?

PostWed Feb 26, 2025 2:58 pm

Robert Niessner wrote:... If what you said was true, then we should get the same out of ProRes files when doing color manipulations - but that isn't the case… I can get so much more out of BRAWs than from ProRes files.


Very true, and I get more out of uncompressed CinemaDNG than ProRes. Clearly ProRes is a limited capture codec that can work very well, best in a controlled shoot.

I have several archives generated with flat ProRes 444 XQ files. In testing that this recommended approach was one of the best practice options for archives that surely would outlive the raw files I captured with CinemaDNG, I brought those flat files back into resolve to grade as a remastered masterpiece. Well that didn’t go well as my ability to get great colour was pretty much limited to stretching the ProRes for a stop (or two at most) before the master showed signs of breaking. I’m considering trying another master codec and abandoning ProRes for good.
Rick Lang
Offline

WahWay

  • Posts: 1029
  • Joined: Tue Apr 07, 2020 11:54 am
  • Real Name: Simon Chan

Re: Internal ProRes RAW for Pyxis?

PostWed Feb 26, 2025 7:46 pm

We've been told "Apple loves BMD". Surely that kind of love affair getting a Prores license is not difficult.
Offline

John Brawley

  • Posts: 4499
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Los Angeles CA

Re: Internal ProRes RAW for Pyxis?

PostWed Feb 26, 2025 9:08 pm

Layers = later. Typo from set.

Apple love Blackmagic. Wonder what codec the new immersive camera BMD has built for Apple will shoot…

Apple LOVE to show their hardware off using Resolve.

There’s a small team within Apple that don’t love BMD. The ones whose livelihood is threatened by Resolve. That team look after ProRes too. Funny that their launch parter is the IP thieves that started Atomos.

I’m shooting. I can’t take a bunch more time to respond. If DNG was so good more camera companies would be using it.

JB
John Brawley ACS
Cinematographer
Los Angeles
Offline

John Paines

  • Posts: 6327
  • Joined: Tue Jul 28, 2015 4:04 pm

Re: Internal ProRes RAW for Pyxis?

PostWed Feb 26, 2025 9:32 pm

rick.lang wrote:
Robert Niessner wrote:... If what you said was true, then we should get the same out of ProRes files when doing color manipulations - but that isn't the case… I can get so much more out of BRAWs than from ProRes files.


Very true, and I get more out of uncompressed CinemaDNG than ProRes. Clearly ProRes is a limited capture codec that can work very well, best in a controlled shoot.


I can see this one getting into trouble, and Robert can correct me if he feels the need, but that's not what he said as I read it. He specified a very specific and limited use case ("For example I have shots with lots of those saturated LEDs").

Again, maybe for LEDs, but the idea that raw and quasi-raw formats are vastly superior to the likes of Prores is, forgive me, an urban myth. As has been pointed out many times, 7 figure features and TV shows are typically shot on Prores. Sure, those are "controlled shoots" but the idea that no-budget productions will be able to exploit raw, outside unique cases, and with colorists with no professional exposure or training (typical in the no-budget world) is a fantasy. And this fantasy is based in marketing, as if raw is going to cure everything else which is wrong with the production. And, consider the ultimate arbiter of reality -- the audience. Nobody watches a no-budget effort and remarks afterwards, "jeez, it would have been so much better on raw!"

Put even more bluntly, actual productions don't need raw, and non-actual ones can't readily exploit its typically minimal advantages, outside very specific use cases. The real advantage of braw over Prores is efficiency, not quality.

I can already hear the cries of execration, so let loose....
Offline

John Brawley

  • Posts: 4499
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Los Angeles CA

Re: Internal ProRes RAW for Pyxis?

PostThu Feb 27, 2025 12:15 am

It’s true.

A majority of shows still “only” shoot ProRes (and not raw)

JB
John Brawley ACS
Cinematographer
Los Angeles
Offline
User avatar

Uli Plank

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

Re: Internal ProRes RAW for Pyxis?

PostThu Feb 27, 2025 12:26 am

The majority of work with Arri cameras is shot in ProRes, at least in Europe.
My disaster protection: export a .drp file to a physically separated storage regularly.
www.digitalproduction.com

Studio 19.1.3
MacOS 13.7.4, 2017 iMac, 32 GB, Radeon Pro 580 + eGPU
MacBook M1 Pro, 16 GPU cores, 32 GB RAM, MacOS 14.7.2
SE, USM G3
Offline

Tom Roper

  • Posts: 648
  • Joined: Sat Apr 14, 2018 4:59 pm
  • Real Name: Tom Roper

Re: Internal ProRes RAW for Pyxis?

PostThu Feb 27, 2025 3:58 am

John Paines wrote:
I can see this one getting into trouble, and Robert can correct me if he feels the need, but that's not what he said as I read it. He specified a very specific and limited use case ("For example I have shots with lots of those saturated LEDs").

Again, maybe for LEDs, but the idea that raw and quasi-raw formats are vastly superior to the likes of Prores is, forgive me, an urban myth. As has been pointed out many times, 7 figure features and TV shows are typically shot on Prores. Sure, those are "controlled shoots" but the idea that no-budget productions will be able to exploit raw, outside unique cases, and with colorists with no professional exposure or training (typical in the no-budget world) is a fantasy. And this fantasy is based in marketing, as if raw is going to cure everything else which is wrong with the production. And, consider the ultimate arbiter of reality -- the audience. Nobody watches a no-budget effort and remarks afterwards, "jeez, it would have been so much better on raw!"

Put even more bluntly, actual productions don't need raw, and non-actual ones can't readily exploit its typically minimal advantages, outside very specific use cases. The real advantage of braw over Prores is efficiency, not quality.

I can already hear the cries of execration, so let loose....


So sauce for the goose is sauce for the gander, one codec = equality for all! I don't think anyone said raw and quasi-raw formats are "vastly superior," but it's probably fair to say that for some, they could be "vastly preferable" for reasons known to them or their so called fantasies to you but either way, BMD offers this choice to use BRAW and its user selectable compression levels, or mandates it for certain sensors or frame sizes. So why not? Nobody ever learned anything by shutting the door on knowledge and innovation.

Prores Raw is available through Atomos recorders. I don't see why it should be incumbent on BMD to write a Prores Raw plugin for every camera, and Prores Raw SDK for Resolve when other camera makers are generally not doing this.
Offline

Mark Grgurev

  • Posts: 958
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Internal ProRes RAW for Pyxis?

PostThu Feb 27, 2025 5:40 pm

Robert Niessner wrote:If that would be simple enough then we already would have ProRes RAW support in Resolve.
As Resolve does support a vast range of other RAW Formats from competitors the only conclusion for me is that somehow Apple doesn't wants them to.

Unlike those other RAW codecs, Prores RAW is the only one that actually competes with BRAW as it's the only other one available in external recorders.

Robert Niessner wrote:Originally the BMCC only had uncompressed CDNG, later with firmware 1.8 or 1.9 (afair) it got lossless compression which reduces file sizes to 50%-60%. And I had several tools which could not read compressed DNGs.

That's correct but since my post was already long I decided to say "Before they switched to BRAW" in an attempt to refer to the time period right before they switched to BRAW. At that point, none of their previous cameras could shoot uncompressed RAW any more.

Robert Niessner wrote:I think he means that BRAW has an SDK making sure decoding is standardized, while CDNG isn't and every tool can use its own method for decoding.

That's a good point. That could be addressed to some degree by creating a shared, open-source library for decoding CDNGs that other programs could adopt and contribute to.

But also one of the reasons BRAW can be so consistent with decoding is because the actual sensor information is irrelevant at the decoding step. It doesn't know if the sensor used to record the data was bayer, RGBW, or Foveon. All of the information related to how the sensor captured the image was discarded in-camera.

Robert Niessner wrote:There is more metadata needed than slate, ISO and WB.
I just checked out what metadata gets stored in old 2018 DNG files from my BMCC:
Slate
...

BRAW adds:
...

Those could be added to CDNGs as well. Both DNG and MXF support custom metadata so you're not limited to a specific set of fields, you can add any information you feel is relevant. Less metadata was stored in BMD's BRAW file vs their CDNG files because they decided to store less, not because their was limitation on what CDNG could store.

Robert Niessner wrote:You are aware that a Bayer sensor does only have 1/4 of red and blue and 1/2 of green sensels?
That's the trick here.

Y, cb, and cr don't translate to G,B, and R channels though. All of the sensels on a bayer sensor contribute to both the luma and color channels. After debayering an image, you still get full-resolution RGB channels even though each channel as information filed in with interpolated data.

When converted to Ycbcr, the luma channel is created with an weighted sum of the data in all three channels. The Cb and Cr channels don't store the absolutely brightness values of blue and red, they store them as the delta between them and the Y channel. When transforming back to RGB, you could say the green channel is derived from the information in the luma channel that the cb and cr channels didn't claim. Because the green chroma info is reliant on all three channels, once you lower the cb and cr channel resolutions to 25%, you're also lower the green chroma resolution to 25%.

If you look at the RGBW color filter on 12K sensors, half the sensels are contributing chroma information, 16% are contributing specific color information, and all of the sensels are contributing different degrees of luma information...or at least that's true when you're shooting 12K. Once you shoot 8K, every final pixel is made up of far more actual sensel information. By the time you're shooting 4K, every single channel from every single pixel will have been made up from the combined values of multiple red, green, blue, and clear sensels with no interpolated values.

Mathematically, the 12K should be able to record 4K video that looks as good or better than a Foveon sensor but the general belief is that it's 4K doesn't look as good as shooting 12K or 8K and downsampling in post. That's because 12K BRAW only stores color information at 6K, at 8K it's only storing color information at 4K, and at 4K it's storing color information at 2K.

A real RAW format that tries to preserve sensor readout data might store the 12K's 4K readout as four 12-bit channels and when it's expanded to 16-bit linear RGB in post, each channel would actually have precision closer to three 13-bit channels because the W channel's values would be added to the RGB channel without first reducing the actual RGB values to keep the total within a 12-bit range.

With losslessly compressed CDNG that would average between 600-730MB/s at 24fps. That's high because it's not storing a single bayer channel and instead storing 4 full-resolution channels but that's still less data than shooting Q0 12K to get a similar, but still technically inferior result. Then of course if you're okay with lossy compression the camera could combine in the W channel into the RGB channels in camera. That would immediately reduce the bit-rate to 450-550MB/s and that's before any DCT compression is done.

Robert Niessner wrote:I think you should re-read the patent. If what you said was true, then we should get the same out of ProRes files when doing color manipulations - but that isn't the case. For example I have shots with lots of those saturated LEDs - I can get so much more out of BRAWs than from ProRes files.

You could if the Prores file is 12-bit and doesn't have the ISO and white balance adjustments baked it. You don't even really have to compare it to another codec to show that the WB and ISO dropdowns aren't doing anything that can't be done with the other grading tools. You can take the same BRAW shot, put two copies of it into a Resolve timeline, and set one to ISO 100 and the other to ISO 1000 then try to match one to the other in the grading tools. Again, it's just metadata,
Offline
User avatar

carlomacchiavello

  • Posts: 3062
  • Joined: Tue Aug 28, 2012 6:04 pm
  • Location: italy

Re: Internal ProRes RAW for Pyxis?

PostThu Feb 27, 2025 6:34 pm

Mark Grgurev wrote:
Robert Niessner wrote:I think he means that BRAW has an SDK making sure decoding is standardized, while CDNG isn't and every tool can use its own method for decoding.

That's a good point. That could be addressed to some degree by creating a shared, open-source library for decoding CDNGs that other programs could adopt and contribute to.


The reason is that Adobe itself (creatore of dng) abandoned dng format in 2017, they only update tools to support it, but stop the development years ago.

Why not use a different and more powerful standard single still format like exr which is free, 32bit format, multilayer, multi data and more?

Or why not start to support again cineformRaw which is more powerful than every other raw, cost only 20$ per camera and it’s more flexible.
Can have all feature of braw and cdng, and more, it’s also a stereoscopic format, metadata active driven to color correction and more.

(Mine is a joke obviously)

At today I not found a proof that a correct shooting in Q1 or Q0 is worst than a cdng at the end of chain of editing, color and post.
I not found a real difference to get real sharp picture or ability to read difference in dynamic range or see difference in a quality of color.

I shoot for years cdng with production camera 4k, ursa mini pro G1, pocket4k and I did many test on real situation, not target and I not see difference, or in the worst situation on light i found more problem to clean up cdng than braw be cause some aliasing and false detail cause worst acting of denoising algorithm.

I also did photo shooting with both method and cdng correctly developed not give me more details than q0.


Inviato dal mio iPhone utilizzando Tapatalk
Offline

Mark Grgurev

  • Posts: 958
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Internal ProRes RAW for Pyxis?

PostThu Feb 27, 2025 7:19 pm

John Brawley wrote: can’t take a bunch more time to respond. If DNG was so good more camera companies would be using it.


That's a bad assumption. At this point, BMD, Canon, Sony, Red, and Arri all have the own formats. Canon and Sony actually have two RAW formats each: a RAW format and a "raw" format. The only camera manufacturers using a RAW codec that they didn't make are Panasonic (Prores RAW) and Sigma (CinemaDNG).

It doesn't look like any camera manufactures have intentions on finding the best codec of the bunch and then using that. Why? I have no idea. Similarly, many of these camera manufacturers have their own RAW formats for still images despite DNG being able to store all of the same data. Some, like Hassleblad, Richo, Leica, Pentax, Sigma, Samsung, and many smart phones, do use it.

How would that translate to CinemaDNG being bad? If you looked up CinemaDNG (and the specification it's built on) instead of just judging it exclusively based on BMD implemented it, you'd see that it's a better format than you think. In June of 2023, DNG even added JPEG XL as a compression method for lossless and lossy encoding. JXL can do visually lossless compression at up to a 20:1 ratio and can do mathematically lossless compression at very good ratios.
Last edited by Mark Grgurev on Thu Feb 27, 2025 7:41 pm, edited 1 time in total.
Offline

Mark Grgurev

  • Posts: 958
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Internal ProRes RAW for Pyxis?

PostThu Feb 27, 2025 7:36 pm

carlomacchiavello wrote:The reason is that Adobe itself (creatore of dng) abandoned dng format in 2017, they only update tools to support it, but stop the development years ago.

Why not use a different and more powerful standard single still format like exr which is free, 32bit format, multilayer, multi data and more?

Or why not start to support again cineformRaw which is more powerful than every other raw, cost only 20$ per camera and it’s more flexible.
Can have all feature of braw and cdng, and more, it’s also a stereoscopic format, metadata active driven to color correction and more.

(Mine is a joke obviously)


It doesn't really matter that Adobe abandoned it because it's an open format and it's just a way of using a few other standards together.

carlomacchiavello wrote:At today I not found a proof that a correct shooting in Q1 or Q0 is worst than a cdng at the end of chain of editing, color and post.
I not found a real difference to get real sharp picture or ability to read difference in dynamic range or see difference in a quality of color.


I feel like people have largely misunderstood what this conversation is about. Nobody is saying that BRAW is bad, unusable, or is significantly worse than CDNG or Prores RAW. All that's been stated is that the difference are there and they are measurable. Proof has been provided that Prores RAW and CDNG retain more detail than BRAW. It's irrelevant where you personally care about the difference. It's just insane to act like they don't exist or say that BRAW is definitely better than the other formats when it's not.

Also this topic is supposed to be about internal Prores RAW recording or making a BRAW2 codec that is closer to Prores RAW, not bringing back CDNG. The CDNG discussion started just because people got defensive about the objective truth that CDNG does retain more detail than BRAW.

carlomacchiavello wrote:I shoot for years cdng with production camera 4k, ursa mini pro G1, pocket4k and I did many test on real situation, not target and I not see difference, or in the worst situation on light i found more problem to clean up cdng than braw be cause some aliasing and false detail cause worst acting of denoising algorithm.

I also did photo shooting with both method and cdng correctly developed not give me more details than q0.


The aliasing isn't introduced by CDNG, it's an artifact of how the sensor works and of de-mosiacking. The reason BRAW has less is because there's some sort of anti-aliasing pass being done to the image. That same kind of processing can be done on a CDNG. It's just that you have to do it.

Also there's no way CDNG is giving you worse results when denoising. Maybe that's the case if you use Resolve built-in denoising (which I feel is only good for temporary denoising when color grading) but with something like Neatvideo, the format that preserves more detail is going to denoise better.
Offline

John Brawley

  • Posts: 4499
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Los Angeles CA

Re: Internal ProRes RAW for Pyxis?

PostThu Feb 27, 2025 8:32 pm

You forgot a few.

DJI (DNG)
Kinefinity. (KineRaw)
Z cam (Zraw)
Pretty sure Panasonic had VRAW for the varicam. ProRes raw is only since Nikon bought RED.
Sony had a couple of raw formats. One 3:1 16bit lin and one that was REDCODE in a different wrapper.

Really though, why didn’t Arri adopt DNG when they chose to go uncompressed?

DNG is run (if you can call it that) by a consortium. For a while BMD was driving it. They were the first to introduce the compressed versions. Others adopted it.

I haven’t seen any proof that ProRes RAW has more detail than BRAW.

It’s academic. DNG is a dead end.

JB
Last edited by John Brawley on Thu Feb 27, 2025 8:35 pm, edited 1 time in total.
John Brawley ACS
Cinematographer
Los Angeles
Offline

Mark Grgurev

  • Posts: 958
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Internal ProRes RAW for Pyxis?

PostThu Feb 27, 2025 11:09 pm

John Brawley wrote:Really though, why didn’t Arri adopt DNG when they chose to go uncompressed?

Great question. It uses the same MXF wrapper and since it's completely uncompressed it's probably nearly identical to MXF-wrapped CDNG.

John Brawley wrote:DNG is run (if you can call it that) by a consortium. For a while BMD was driving it. They were the first to introduce the compressed versions. Others adopted it.

It wasn't run by a consortium. I'll repeat again that it's just a way to use multiple existing standards together. There's really nothing to add to it. It's just a file structure for storing DNGs and audio. Blackmagic didn't add compression to the CDNG standard. CDNG doesn't define any compression because it's just a bunch of DNGs either in a folder or packaged as an MXF file. Compression is added per-frame just like in any intra-frame compression and in this case every frame is a DNG. BMD just implemented a form of lossy compression to the DNGs in their CDNGs they used because it's an open format so you can extend it for your own purposes if you want. The lossless compression they originally used was inherited from DNG.

Seriously what do you think needs to be added to CDNG to make it as good as BRAW for you? Do you think proprietary formats are just better? Do you think it's a bad thing for a standardized, license-free, open-source method of recording RAW video? Do you need features to be explicitly added to a format along with a version bump in order for it to feel modern to you?

I've seen you and others say so many incorrect things about the format in just this thread, things that can be very easily looked up, simply because you're assuming that when BMD does something, they do it to the fullest. BMD used CDNG and since they didn't store them as single files or store LUTS, accelerometer data, and ND data then you just assumed that means CDNG couldn't do any of that. BMD could have implemented constant quality modes in CDNG as well because absolutely nothing about the CDNG spec would prevent them from doing that....they just didn't.

John Brawley wrote:I haven’t seen any proof that ProRes RAW has more detail than BRAW.

Let me quote one of my previous posts in this topic that provides that proof. Feel free to ignore it again.

Mark Grgurev wrote:
shows that by Neatvideo's metric for measuring noise, BRAW has about half as much noise as Prores RAW which means Prores RAW will get you cleaner footage and thus better dynamic range when shooting low-light footage or exposing to protect highlights in high-dynamic range shots.


John Brawley wrote:It’s academic. DNG is a dead end.

Yes, and WAV is dead too, right John? The last update to the format was 17 years ago. John, you're talented cinematography but this isn't the first time you've argued with me about things above your level of tech understanding.
Offline
User avatar

Jamie LeJeune

  • Posts: 2084
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Internal ProRes RAW for Pyxis?

PostFri Feb 28, 2025 5:12 am

Mark Grgurev wrote: Seriously what do you think needs to be added to CDNG to make it as good as BRAW for you? Do you think proprietary formats are just better? Do you think it's a bad thing for a standardized, license-free, open-source method of recording RAW video?
Standardized? Not in my experience with it in post. CDNG creates a workflow nightmare when debayering in different apps yields different results.

With BRAW, I can use a simple script to make sidecar files that set the transfer function, primaries, gamut compression, and highlight recovery of the decode so that even if the files get run through by a collaborator who isn't paying close attention to their settings, the right results are rendered out. I can even make a separate set of sidecar files with a custom show LUT embedded to hand off to an AE for creating dailies or to give producers who want to play the BRAW files directly with that display LUT. As far as I've ever seen, there's no similar level of control for CDNG (nor does ProRes RAW offer such control).
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

John Brawley

  • Posts: 4499
  • Joined: Tue Aug 21, 2012 7:57 am
  • Location: Los Angeles CA

Re: Internal ProRes RAW for Pyxis?

PostFri Feb 28, 2025 8:29 am

Mark Grgurev wrote:
John Brawley wrote:It’s academic. DNG is a dead end.

Yes, and WAV is dead too, right John? The last update to the format was 17 years ago. John, you're talented cinematography but this isn't the first time you've argued with me about things above your level of tech understanding.


You make a great point!

WAV is widely used.

DNG is not. And it never will be.

JB
John Brawley ACS
Cinematographer
Los Angeles

Return to Cinematography

Who is online

Users browsing this forum: Bing [Bot] and 35 guests