Date
1 - 20 of 23
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
|
|
|
|
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:
|
|
|
|
Paul Curtis
On 14 Sep 2018, at 10:55, Colin Elves <colin@...> wrote: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?!
toggle quoted messageShow quoted text
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
|
|
|
|
Daniel Rozsnyó
Finally a good question to answer:
toggle quoted messageShow quoted text
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)
|
|
|
|
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:
|
|
|
|
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
Kinetta jeff@... kinetta.com Sent from iPhone. On Sep 14, 2018, at 12:18 PM, Daniel Rozsnyó <daniel@...> wrote: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? 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.
toggle quoted messageShow quoted text
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
|
|
|
|
axel.mertes
I've watched the presentation, downloaded the SDK and sample
files.
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:
|
|
|
|
Olaf Matthes
axel.mertes schrieb:
Using a single streaming file in its very own container makes sense overWhen 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. 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:
|
|
|
|
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
Where did you find them?
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:
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
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.
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. Cinematographer Atlanta Georgia (Occasional test pilot for BMD)
|
|
|
|
Paul Curtis
On 18 Sep 2018, at 19:58, axel.mertes <axel.mertes@...> wrote: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
|
|
|