Topics

new 'Black Magic Raw' codec announced.

Colin Elves
 

https://www.blackmagicdesign.com/products/blackmagicursaminipro/blackmagicraw

Looks like BMD have developed their own version of ProRes Raw (no wonder they seemed a bit pissed off when Apple announced it earlier in the year).

Obviously it’s integrated into Resolve and they’ve released an SDK for incorporate into other company’s software - which is a big plus over PRR, but it does sound like it might be limited to BMD cameras only, which could be a bit of a negative. 

I hope this doesn’t mean they’ll avoid adding PRR support to Resolve. 

But I guess the 'raw wars' have now officially started! 

Colin Elves
Director of Photography
Berlin



Geoff Boyle
 

I'll post about this later when I have a keyboard.
It's cool and I've been dying to tell you about it.
There's other good stuff here this year and I'll post about it all later

Geoff

On Fri, 14 Sep 2018, 11:55 Colin Elves, <colin@...> wrote:
https://www.blackmagicdesign.com/products/blackmagicursaminipro/blackmagicraw

Looks like BMD have developed their own version of ProRes Raw (no wonder they seemed a bit pissed off when Apple announced it earlier in the year).

Obviously it’s integrated into Resolve and they’ve released an SDK for incorporate into other company’s software - which is a big plus over PRR, but it does sound like it might be limited to BMD cameras only, which could be a bit of a negative. 

I hope this doesn’t mean they’ll avoid adding PRR support to Resolve. 

But I guess the 'raw wars' have now officially started! 

Colin Elves
Director of Photography
Berlin



Paul Curtis
 

On 14 Sep 2018, at 10:55, Colin Elves <colin@...> wrote:
But I guess the 'raw wars' have now officially started!
Coined by you here.

This RAW looks to be BMD Cameras only because they say that part of the debayer has been moved in camera. They're not very specific with that though but one of the beauties of RAW decoding is the ability to swap algorithms for different needs (although truth be told i suspect there's only a tiny % of high end productions that would do this)

Looks interesting but if it's debayering is in camera then is this really RAW? Or is it just a 4:4:4 style video file in a log encoded camera wide colour space? Look forward to hearing some more about it.

cheers
Paul

Paul Curtis, VFX & Post | Canterbury, UK

Colin Elves
 

Yeah ‘split debayer’ WTF is that?! 

It’s an interesting development. Sounds like it will only be available for BMD Cameras, but software agnostic (is the idea at least) sort of the opposite of ProRes Raw - which is camera agnostic but can only be used in FCPX. 

Hopefully this competition will push BMD to Open up BMR to other camera manufacturers and Apple to open PRR to other software companies. 

Both developments are great for us users though. Kinda sucks for companies still trying to push Mirrorless stills cameras as ‘entry level’ cinema cams though. Why would you want to shoot on 8 bit 420 H264 when you can shoot Raw? 

Hell, why would you shoot Vanilla ProRes?!

Looks like we’ll all be shooting large format high-performance compressed raw from now on and handing it straight to the editor untouched. It’s a brave new world! 

Colin Elves
Director of Photography
Berlin




Looks interesting but if it's debayering is in camera then is this really RAW? Or is it just a 4:4:4 style video file in a log encoded camera wide colour space? Look forward to hearing some more about it.
_._,_._,_

Daniel Rozsnyó
 

Finally a good question to answer:

    Split debayer is a way to avoid getting sued for making a camera that records "compressed RAW format" into a single file.

Whatever it really technically is does not matter at all.


Ing. Daniel Rozsnyo
camera developer
Prague, Czech Republic



On 09/14/2018 04:00 PM, Colin Elves wrote:
Yeah ‘split debayer’ WTF is that?! 

Adam Wilt
 

Kinda sucks for companies still trying to push Mirrorless stills cameras as ‘entry level’ cinema cams though. Why would you want to shoot on 8 bit 420 H264 when you can shoot Raw? 

“The best is the enemy of the good”, but it’s also true that, often, “the good is the enemy of the best”. Raw is still bigger and bulkier than a compressed WYSIWYG or log file and is (arguably) overkill for a lot of uses. It’s often more painful in post (BMD raw seems to have that nicely under control, though), and it’s much harder to “bake” a look into a raw file so those pesky post people don’t mess with your vision. ;-)

Folks at a rental house (the ever-helpful Chater Camera in Berkeley) told me that their Alexas rarely went out with raw recorders; most of the time, ProRes was good enough. Even when crews took raw recorders out, they often recorded ProRes working files, then wound up using those through post; the raw served as a safety master for comfort purposes but was never used.

Besides, some of those mirrorless still cams can record and/or output 10-bit 4:2:2, which may not be state of the art but is a darned sight better than 8-bit 4:2:0, especially for log recording.

Horses for courses!

Cheers,
Adam Wilt
technical services: consulting / coding / camerawork
Vancouver WA USA (no, not that Vancouver, the other one)

Geoff Boyle
 

Yeah but read the cml website front page😁

Geoff
On a tram
On my way to IBC, again.

On Sat, 15 Sep 2018, 07:31 Adam Wilt, <adam@...> wrote:
Kinda sucks for companies still trying to push Mirrorless stills cameras as ‘entry level’ cinema cams though. Why would you want to shoot on 8 bit 420 H264 when you can shoot Raw? 

“The best is the enemy of the good”, but it’s also true that, often, “the good is the enemy of the best”. Raw is still bigger and bulkier than a compressed WYSIWYG or log file and is (arguably) overkill for a lot of uses. It’s often more painful in post (BMD raw seems to have that nicely under control, though), and it’s much harder to “bake” a look into a raw file so those pesky post people don’t mess with your vision. ;-)

Folks at a rental house (the ever-helpful Chater Camera in Berkeley) told me that their Alexas rarely went out with raw recorders; most of the time, ProRes was good enough. Even when crews took raw recorders out, they often recorded ProRes working files, then wound up using those through post; the raw served as a safety master for comfort purposes but was never used.

Besides, some of those mirrorless still cams can record and/or output 10-bit 4:2:2, which may not be state of the art but is a darned sight better than 8-bit 4:2:0, especially for log recording.

Horses for courses!

Cheers,
Adam Wilt
technical services: consulting / coding / camerawork
Vancouver WA USA (no, not that Vancouver, the other one)

Colin Elves
 

Whatever it really technically is does not matter at all.
Well. I suppose, but isn’t one of the supposed manic advantages of a raw workflow is that the debayer method can be changed (and improved over time) as needed?

So I guess it matters if it interferes with that.

i’m afraid i don’t know enough about debayering: is it a multi-stage process these days? Can you really split it up?

Jeff Kreines
 

Jeff Kreines
Kinetta
jeff@...
kinetta.com

Sent from iPhone.

On Sep 14, 2018, at 12:18 PM, Daniel Rozsnyó <daniel@...> wrote:

Split debayer is a way to avoid getting sued for making a camera that records "compressed RAW format" into a single file.
Sued by who? CineForm?

Mitch Gross
 

On Sep 15, 2018, at 5:02 AM, Colin Elves <colin@...> wrote:

Well. I suppose, but isn’t one of the supposed manic advantages of a raw workflow is that the debayer method can be changed (and improved over time) as needed?

That’s just marketing. How often does one go back to old original RAW files because the deBayer method improved? And on that note, what’s to say that this system couldn’t also offer such improvements? I really don’t know how BMD is defining this, but I don’t think it makes much of a difference. We’re all mostly working project-based. 

Mitch Gross
Cinema Product Manager 
Panasonic Systems Solutions Company of North America
New York


Colin Elves
 

Well people seem to go back to original negatives to ‘digitally remaster’ old films. So I don’t see why it wouldn’t happen.

And if you’re shooting a documentary over a number of years debayer methods could improve over the same time as well.

But I’m just saying: isn’t that supposed to be what’s special about raw? Is there much else you can do with it that’s not possible with video and competent grading skills?

Colin Elves
Director of Photography
Berlin

On 15 Sep 2018, at 18:03, Mitch Gross <mitchgrosscml@...> wrote:

On Sep 15, 2018, at 5:02 AM, Colin Elves <colin@...> wrote:

Well. I suppose, but isn’t one of the supposed manic advantages of a raw workflow is that the debayer method can be changed (and improved over time) as needed?

That’s just marketing. How often does one go back to old original RAW files because the deBayer method improved? 

axel.mertes
 

I've watched the presentation, downloaded the SDK and sample files.
I can't find the BRAW Player for Windows. Is it just me? Or is there none yet?
If you see it, send me the link.

I still wonder what part of the story is split DeBayer here?

The color/metadata handling reminds me strongly of CineForm FirstLight and RED CINE-X.

Am I getting this right, you can export RGB back to BRAW?
Good idea. We did that with CineForm RAW like 5 years ago, to convert RED RAW to CineForm RAW, be reading RED files decoded as RGB and then dropping the interpolated pixel values (which is easy when you know the Bayer pattern orientation).

Using a single streaming file in its very own container makes sense over using unloved AVI and hated Quicktime...

Can't wait to check it out and include it in my codec tests. Got 3 new Codec SDKs on IBC now, that'll be a big project as it seems.

Mit freundlichen Grüßen,
Best regards,

Axel Mertes

Workflow, IT, Research and Development
Geschäftsführer/CTO/Founder
Tel: +49 69 978837-20
eMail: Axel.Mertes@...

Magna Mana Production
Bildbearbeitung GmbH
Jakob-Latscha-Straße 3
60314 Frankfurt am Main
Germany
Tel: +49 69 978837-0
Fax: +49 69 978837-34
eMail: Info@...
Web: http://www.MagnaMana.com/

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren
sowie die unbefugte Weitergabe dieser E-Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.


Am 14.09.2018 um 14:09 schrieb Geoff Boyle:

I'll post about this later when I have a keyboard.
It's cool and I've been dying to tell you about it.
There's other good stuff here this year and I'll post about it all later

Geoff

On Fri, 14 Sep 2018, 11:55 Colin Elves, <colin@...> wrote:
https://www.blackmagicdesign.com/products/blackmagicursaminipro/blackmagicraw

Looks like BMD have developed their own version of ProRes Raw (no wonder they seemed a bit pissed off when Apple announced it earlier in the year).

Obviously it’s integrated into Resolve and they’ve released an SDK for incorporate into other company’s software - which is a big plus over PRR, but it does sound like it might be limited to BMD cameras only, which could be a bit of a negative. 

I hope this doesn’t mean they’ll avoid adding PRR support to Resolve. 

But I guess the 'raw wars' have now officially started! 

Colin Elves
Director of Photography
Berlin



Olaf Matthes
 

axel.mertes schrieb:
Using a single streaming file in its very own container makes sense over
using unloved AVI and hated Quicktime...
When you change file extension from .braw to .mov you'll see that the
file format is quite a lot like QickTime. You can run it through
MediaInfo then and it'll show whats in there. So basically Blackmagic
invented a codec with the four-character-code 'brxq' and stuffed it into
a QuickTime MOV container.

But to be fair, Canon's CRM (and CR3) format works exactly the same, in
that they use the QuicktTime File Format, stuff their own codec in there
and come up with a new file extension.

Olaf Matthes
EU-based freelance software developer

Miga Bär
 

“I can't find the BRAW Player for Windows. Is it just me? Or is there none yet?
If you see it, send me the link.”

That’s correct, there is no stand-alone player for Windows available. I didn’t catch if there is one on the future roadmap at the demo I got.

Miga Bär
DI specialist
Amsterdam area


axel.mertes
 

Yes, its the same with H264 - it uses the Quicktime container. Rename any .MP4 in .MOV and it will play in Quicktime. Its the same thing.

Mit freundlichen Grüßen,
Best regards,


Axel Mertes

Workflow, IT, Research and Development
Geschäftsführer/CTO/Founder
Tel: +49 69 978837-20
eMail: Axel.Mertes@...

Magna Mana Production
Bildbearbeitung GmbH
Jakob-Latscha-Straße 3
60314 Frankfurt am Main
Germany
Tel: +49 69 978837-0
Fax: +49 69 978837-34
eMail: Info@...
Web: http://www.MagnaMana.com/

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren
sowie die unbefugte Weitergabe dieser E-Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.


Am 16.09.2018 um 08:34 schrieb Olaf Matthes:

axel.mertes schrieb:
Using a single streaming file in its very own container makes sense over
using unloved AVI and hated Quicktime...
When you change file extension from .braw to .mov you'll see that the
file format is quite a lot like QickTime. You can run it through
MediaInfo then and it'll show whats in there. So basically Blackmagic
invented a codec with the four-character-code 'brxq' and stuffed it into
a QuickTime MOV container.

But to be fair, Canon's CRM (and CR3) format works exactly the same, in
that they use the QuicktTime File Format, stuff their own codec in there
and come up with a new file extension.

Olaf Matthes
EU-based freelance software developer
_._,_._

axel.mertes
 

I have read the SDK docs today.

I am not sure, but it feels like the RAW Bayer pattern image may be demosaiced on the camera, but color is left in its RAW state, which means all the color transforms are not yet performed.

The result would be a RGB file with sensor color values. You need to apply color processing to it to convert it to RGB color images that are nice to look at. Demosaic is something any Blackmagicdesign camera is capable of, because you need it to do a ProRes recording... By not applying the color processing, you keep the spirit of RAW and depending on the compression scheme its better than CinemaDNG and probably a bit bigger than ProRes, which is a fair deal.

No idea (yet) which compression/encoding scheme is underlying. Could be a wavelet, as they have the decoding options 1/2, 1/4, 1/8 as well. But must not necessarily be. I'd strongly appreciated it if it would be wavelet. Some tests might reveal that.

Given this, you would still be able to apply a better demosaic algorithm later again, by simply dropping the interpolated pixels again and reinterpolating using a new algorithm. Thats exactly what we did in Fusion with our CineForm for Fusion plugins. We could store away an RGB image as RAW again. By knowing the original cameras Bayer pattern orientation, thats easy to do. We transcoded from RED RGB to CineForm RAW this way and have been able to apply any of the 5 build in demosaic options of CineForm this way.

Is it just me or wasn't memtioned in the video by Grant Petty that they could export in that format too?
And wasn't it stressed that there is no 422 color subsampling happening?
...which is on the one hand nonsense, as ANY Bayer pattern sensor is doing 422 color subsampling by its nature of 2 green pixels per each red and blue pixel and on the other hand only possible by demosaicing from Bayer RAW 422 to demosaiced RAW 444 first and dealing the data as 444 stream from then on.

Would make perfectly sense to me and all the official info.

That could also mean we see any kind of RGB compression scheme in place, but probably I-frame only.

As always when it comes to codecs, I want to really understand ALL the details and what is really happing behind the curtain...

Any comments?
Anyone?

Mit freundlichen Grüßen,
Best regards,

Axel Mertes

Workflow, IT, Research and Development
Geschäftsführer/CTO/Founder
Tel: +49 69 978837-20
eMail: Axel.Mertes@...

Magna Mana Production
Bildbearbeitung GmbH
Jakob-Latscha-Straße 3
60314 Frankfurt am Main
Germany
Tel: +49 69 978837-0
Fax: +49 69 978837-34
eMail: Info@...
Web: http://www.MagnaMana.com/

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren
sowie die unbefugte Weitergabe dieser E-Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.

Paul Curtis
 



On 18 Sep 2018, at 18:46, axel.mertes <axel.mertes@...> wrote:
I have read the SDK docs today.

Where did you find them? 

As always when it comes to codecs, I want to really understand ALL the details and what is really happing behind the curtain...

Me too. So demosaiced in camera but not doing all the colour matrix stuff is not really RAW is it? That's something like RWG/LogG10 although perhaps the RGB is really XYZ space and is not in a specific bound colourspace but sensor native?

I'd be keen to understand why they think this is RAW, it's just a nice low overhead compressed full range RGB codec, but should be compared to ProRes/Cineform/DNxHR in terms of performance. Because it sounds like you could stick the same data into those containers.

I think you kind of throw away some good features doing it this way, it's nice to denoise and sharpen at the debayer level and that would be baked in by the camera with this approach.

Look forward to finding out what the difference is between this and plain ol' ProRes.

cheers
Paul

Paul Curtis, VFX & Post | Canterbury, UK





axel.mertes
 

I found them after downloading and unpacking from this link:

https://www.blackmagicdesign.com/support/latest-download/camera/windows

There is a PDF called "Blackmagic RAW SDK.pdf" that explains all function calls.

There is no single specific hint to my interpretation, but I think reading between the lines, hearing between the words makes sense and leads to this. May be I am totally wrong, but thats my first impression after collecting all information I found. If its a manageable file format, I don't care (thats what makes me think it may be wavelet based, as I think to remember that Grant also mentioned being able to play from a USB harddrive that could not play ProRes...).

Taking all this into account leads me to this speculation. This is by no means a critics to the format in any way, it its just the attempt to understand how it works "under the hood".


Am 18.09.2018 um 20:03 schrieb Paul Curtis:


On 18 Sep 2018, at 18:46, axel.mertes <axel.mertes@...> wrote:
I have read the SDK docs today.

Where did you find them? 



Mit freundlichen Grüßen,
Best regards,

Axel Mertes

Workflow, IT, Research and Development
Geschäftsführer/CTO/Founder
Tel: +49 69 978837-20
eMail: Axel.Mertes@...

Magna Mana Production
Bildbearbeitung GmbH
Jakob-Latscha-Straße 3
60314 Frankfurt am Main
Germany
Tel: +49 69 978837-0
Fax: +49 69 978837-34
eMail: Info@...
Web: http://www.MagnaMana.com/

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren
sowie die unbefugte Weitergabe dieser E-Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.


John Brawley
 




On Sep 18, 2018, at 1:46 PM, axel.mertes <axel.mertes@...> wrote:
 
...which is on the one hand nonsense, as ANY Bayer pattern sensor is doing 422 color subsampling by its nature of 2 green pixels per each red and blue pixel and on the other hand only possible by demosaicing from Bayer RAW 422 to demosaiced RAW 444 first and dealing the data as 444 stream from then on.

I’ve never really understood the maths on this one, though I’ve heard it said a lot. It doesn’t seem accurate to me but maybe I’m not understanding the case. 

One is encoded subsampled video in YUV and one is RGB sensor data. Aren’t they completely different ?

Yes the ratio of green to blue pixels happens to be the same ratio but the maths is different isn’t it once you “encode” it into video and throw an algorithm at it to encode it into video.  I know it’s not perfect but it surely is more precise than simply describing a ratio and saying it’s the same as the encoded ratio of another format ?

Where is an actual example of how you’d notice or measure this lack of colour precision ? Is it really as “bad” as saying it’s the same as “4:2:2” says because that’s not my experience in imaging. 



Any comments?
Anyone?


I wish I could say more but right now I can’t. 

But I was impressed by how quickly Assimilate seemed to be saying Scratch was up and running with it. 


John Brawley
Cinematographer 
Atlanta Georgia 
(Occasional test pilot for BMD)

Paul Curtis
 

On 18 Sep 2018, at 19:58, axel.mertes <axel.mertes@...> wrote:
There is a PDF called "Blackmagic RAW SDK.pdf" that explains all function calls.
Yeah, found that. Bit light on background details and i would read the same in between lines that you did

What i would say though is that perhaps the beauty of this isn't the codec (because so far that seems pretty standard) but BMD supplying a whole SDK including display of video - direct to the metal so to speak. Their concept of decoders are perhaps the secret sauce that enables speedier and more trouble free playback than QT (which really shows it's age). A simple unified codec/display system that can hold everything it needs to, colourwise, for all the flexibility in post.

I am still a bit unsure about the use of the word RAW though, i don't see anything in the SDK that suggests any control over demosiac or similar or what i would consider RAW.

Although i suspect most of these hinge around patents and god knows what in that murky world.

cheers
Paul

Paul Curtis, VFX & Post, Canterbury UK