Blackmagic Forum

Andrew Kolakowski wrote: Cineform seems to have more possibilities, which shows how advanced and unique it was many years ago.

And yet it's been a failure...Despite having plenty of chances and a long time of having this playing field to themselves.

Who want's to say why ?

JB

Zak Ray wrote:

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

Really? Now that's interesting...

Yes it's stored as 12-bit log for efficiency reasons but is decoded as 16-bit linear. The metadata is showing what it's being decoded as. This is info from Captain Hook.

John Brawley wrote:

Andrew Kolakowski wrote: Cineform seems to have more possibilities, which shows how advanced and unique it was many years ago.

And yet it's been a failure...Despite having plenty of chances and a long time of having this playing field to themselves.

Who want's to say why ?

JB

Simple answer- because it was developed by 1 guy who didn't have big $ or any support from company like Adobe, AVID etc. Another reason- whole post/broadcast industry is very "legacy" and slow with adoption of new technologies. There is big lack of real innovation (adaption of CinemaDNG is good example). Cineform 15 years ago was more advanced than about any other codec now. Ironically this is also another reason why it failed to gain proper support. There are also some RED patents around RAW compression in camera apparently, so this didn't help either.
Taking this into account its current support is actually not bad at all.

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

I would like to hear some details about it. I can't imagine what is partially debayered image? It's either stored as Bayer pattern (RAW) or not (non-RAW). There isn't really something in-between. Really keen to hear what is inside BMRAW.

Possibly this is what BM is using:

https://books.google.co.uk/books?id=2O5 ... CXoECAIQAQ

Mark Grgurev wrote:

Zak Ray wrote:

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

Really? Now that's interesting...

Yes it's stored as 12-bit log for efficiency reasons but is decoded as 16-bit linear. The metadata is showing what it's being decoded as. This is info from Captain Hook.

Interesting - I didn’t know that, but it makes sense.

Andrew Kolakowski wrote:I would like to hear some details about it. I can't imagine what is partially debayered image? It's either stored as Bayer pattern (RAW) or not (non-RAW). There isn't really something in-between. Really keen to hear what is inside BMRAW.

My assumption is that it's more like a double-debayering type of deal. Basically, I'm wondering if they're debayering in-camera to perform an analysis on the image based on what a lossless, debayered image would be and then just writing the bayered information to the file along with notes for the decoder to use.

For example, maybe they're doing something like a lossy version of Nvidia's delta frame buffer compression. Nvidia's delta compression basically stores common pixel patterns on-chip that can losslessly compress blocks in a frame buffer to 1/2 or 1/8th the size. If BMD tested for matches to these patterns on the uncompressed bayered image in camera-memory then stored notes as to where these matches were made, then the decoder would be able to use these notes to reconstruct the image based on knowledge of what it would have looked like before compression.

Another way to think of it would be to think about the fact that a bayer pattern is just 2x2 pixels. There's like a limited number of ways in which these pixels can be interpolated to produce accurate luma detail but if the debayering algorithm were to analyze the image as if these 2x2 groups were independent of each other then you'd get horrible moire and other issues. On the other hand, increasing the sample size has the potential to yield much better results but will be slower. So the camera could do a potentially intensive debayering algorithm with a larger sample size and then writing information to the file that tells the decoder which 2x2 pixel groups matched with which patterns so the decoder can just apply those transforms.

Even if these notes took the form of a lower-precision anti-aliased line art in 8x8 2bpp pixel groups they may still be useful. Each group could then contain only one of 256 possible patterns. Royally messed up that math but doesn't matter muchThe camera could then store that as "hint table" with 8-bit values that, for a for a 4K DCI image, would consist of 512x270 values which would take up about 138 KB max per frame. This data could be enough to give the decoder's demosaicing algorithm some hint as to the structure of underlying information.

Of course, there's never been a point in my life where I knew enough about compression where I would have been able to make my own codec so this all likely completely wrong and completely archaic. That being said, I think these examples are a decent enough way to demonstrate that a de-mosaicking process could be distributed between the encode and decode phase.

I have skipped through Mark, but going along with what you said. They are doing a debayer for video out and display. So, they could use that to analyse like you said. The language is too murky though.

michaeldhead wrote:

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

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

I doubt it, but I could be wrong. I imagine that giving out the SDK on the editing side is a way to make all the consumers/software developers happy while hoping to draw people into the BMD camera family.

I know I'm saving pennys for a UMP, and that's after I preordered the P4k (which will become the b-cam after I get the UMP).

Watched the video and Grant said they are actually 'considering' this, would require some modifications to cater to other sensors and they need to collaborate with others to get it working I think is what he said, so not out of the question, but maybe he would say that, why rule it out when trying to get a new standard adopted?

Would be great if BM could add a feature so the LUT could modify the sidecar file in real time, so as soon as you backup the footage the shots are almost there in terms of the look you want but would just need a final tweak in the grade, as apposed to starting from scratch each time, that would be amazing!!!

James Alexander Barnett wrote:Would be great if BM could add a feature so the LUT could modify the sidecar file in real time, so as soon as you backup the footage the shots are almost there in terms of the look you want but would just need a final tweak in the grade, as apposed to starting from scratch each time, that would be amazing!!!

When I open up the sample BMDraw files, that's pretty much what it does. The "as shot" look seems to be baked in, but the raw file is still there and you still have full control over it.

For example, on the shot of the girl looking at her phone in the bathroom(?), when I look at the Gamma in Resolve it starts off saying "Blackmagic Design Custom". I switch it to "Blackmagic Design Film" and it looks very flat. Same for Video and Extended Video - which is different from the "Custom" gamma.

It seems to be that the "as shot" look is listed as "Custom", but you still have full control over everything. This excites me a lot more than Prores raw.

michaeldhead wrote:

James Alexander Barnett wrote:Would be great if BM could add a feature so the LUT could modify the sidecar file in real time, so as soon as you backup the footage the shots are almost there in terms of the look you want but would just need a final tweak in the grade, as apposed to starting from scratch each time, that would be amazing!!!

When I open up the sample BMDraw files, that's pretty much what it does. The "as shot" look seems to be baked in, but the raw file is still there and you still have full control over it.

For example, on the shot of the girl looking at her phone in the bathroom(?), when I look at the Gamma in Resolve it starts off saying "Blackmagic Design Custom". I switch it to "Blackmagic Design Film" and it looks very flat. Same for Video and Extended Video - which is different from the "Custom" gamma.

It seems to be that the "as shot" look is listed as "Custom", but you still have full control over everything. This excites me a lot more than Prores raw.

What Michael is thinking is probably the same thing I'm thinking. Beyond that "Blackmagic Design Custom" where RAW Control Settings are adjusted to give a custom grade to the RAW, the LUT would be an actual look. Say something like Orange/Teal, or Dystopian, or Noir, etc. It's applying an actual LUT that changes color profile to emulate a certain look. So thus the LUT gets attached to the RAW file inside the Sidecar. Inside Resolve then you can edit with that LUT applied, but as soon as you get to the grade you can choose to disable it to use the LUTs source PowerGrade Nodes or add the LUT in as a Node on it's own. But the idea is that the Sidecar file references the LUT you shot with so that you're seeing that as well.

That's how I'm interpreting this request. And, this is also how I would suggest it all works.

Chris Chiasson wrote:

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

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

Actually mine (early 2013, i7, 16GB, GT650m) can in fact handle it like a beast!! Even if that CPU doesn't have AVX2 instruction set! Only downside is that at full 4.6k res it is a little choppy, but still, in half res or quarter res it's so flouid and fast to edit with!

timbutt2 wrote:What Michael is thinking is probably the same thing I'm thinking. Beyond that "Blackmagic Design Custom" where RAW Control Settings are adjusted to give a custom grade to the RAW, the LUT would be an actual look. Say something like Orange/Teal, or Dystopian, or Noir, etc. It's applying an actual LUT that changes color profile to emulate a certain look. So thus the LUT gets attached to the RAW file inside the Sidecar. Inside Resolve then you can edit with that LUT applied, but as soon as you get to the grade you can choose to disable it to use the LUTs source PowerGrade Nodes or add the LUT in as a Node on it's own. But the idea is that the Sidecar file references the LUT you shot with so that you're seeing that as well.

That's how I'm interpreting this request. And, this is also how I would suggest it all works.

hhmmm...on one level, that shouldn't be hard. A LUT is basically a numeric array that changes specific color values, which should fit in nicely into the sidecar file. But in practice, I have no idea how much coding that would require, both in-camera coding and in Resolve.

What might be easier is if the sidecar referenced the LUT name in camera, and if the same LUT lives on your Resolve system it is automatically applied.

timbutt2 wrote:What Michael is thinking is probably the same thing I'm thinking. Beyond that "Blackmagic Design Custom" where RAW Control Settings are adjusted to give a custom grade to the RAW, the LUT would be an actual look.

"Blackmagic Design Custom" means that these parameters are active:

{
"tone_curve_contrast": 1.080000,
"tone_curve_saturation": 1.800000,
"tone_curve_midpoint": 0.270000,
"tone_curve_highlights": 0.999000,
"tone_curve_shadows": 1.001000,
"tone_curve_video_black_level": 1,
}

When you have eg. Blackmagic Design Video/Film then this is sort of preset (which was created by BM) for all these parameters. When you set "viewing_gamma" to eg. "Blackmagic Design Video" these won't have any effect on the look. Other controls exposure/temp/iso/tin still will have an effect.
In order to use those custom curves settings you need to set "viewing_gamma" to "Blackmagic Design Custom".

This means sidecar file is sort of 1st level RAW adjustment. In order to have custom (2nd level) look we would need a way of specifying a LUT. This would cost some computation (like it does in Cineform RAW). Compared to this Cineform RAW is way more advanced and allows for much richer active metadata (like mentioned custom LUTs or even re-framing). This is why I said BM RAW is still not on pair with Cineform RAW which was developed 15 years ago
For those who are so amazed by BM RAW check what Cineform RAW was able to do years ago!
Start at around 3min30. I really advise to watch it (forget about all these grading which is done there) to the end, so you will get an idea what can bee done today ( and it's not about doing final grading using this active metadata):



maybe BM can copy it if there is no patent on it. Importan part is that it didn't need any spacial viewer either- all was happening in decoder and any change to metadata was visible in any app which had Cineform file open. You could even have many views embedded with LUTs store in remote location like Dropbox etc and quickly pass a view to someone who had file open. You can even turn on overlays with TC etc. I'm still amazed it never got properly used, yet people keep sending LUTs in emails, using special player to apply LUT etc. So legacy We are in 2018- time to change this 20 yers old approach to metadata, specially when now it can be applied in realtime in most cases (maybe on GPU) without any special player or app.

this is a gamechanger indeed!

I really hope they roll it out to their older cams. I still shoot with BMCC MFT and BMCC Production 4K.

Is Blackmagic Color Science V4 and Blackmagic RAW mutually exclusive?

Can you have one without the other?

I'd like to know as color science and noise performance is personally more important to me than RAW.

(Also, DNXHD ever gonna happen? lol)

BMRAW= v4 color. I don't think you can go back.
With DNG RAW in Resolve settings you either use "Camera Metadata" or v4. No other setting.

Stephen Fitzgerald wrote:Is Blackmagic Color Science V4 and Blackmagic RAW mutually exclusive?

Can you have one without the other?

I'd like to know as color science and noise performance is personally more important to me than RAW.

(Also, DNXHD ever gonna happen? lol)

I doubt you can have BRaw without v4 color, but you can almost certainly shoot v4 color on ProRes.

Well IF that's the case Blackmagic, PLEASE give original UM 4.6K the V4 color science AT LEAST, please and thank you!

(but also give us everything lol)

Is is common among camera companies for their customers to expect past models of cameras to be upgraded to current model software functionality? I'm not aware of any camera company that does that. Why do BM customers expect this?

Gene Kochanowsky wrote:Is is common among camera companies for their customers to expect past models of cameras to be upgraded to current model software functionality? I'm not aware of any camera company that does that. Why do BM customers expect this?

I had no idea that the 4.6k was a "past model" it's just a different version in the Ursa Mini line. Their website has all three listed as active products, none are discontinued or legacy.

It was interesting to lock the camera off on a wide shot and record the same shot in all the different flavours that braw offers. When you play back on the raw player, stop on a frame and, if you have a mac, use control and scroll to zoom in on any given prominent feature. It's neat that some lower settings will start to pixelate. As you look at the higher quality settings it take longer to happen. Once you get to the max, I think it turns to something, but it sure isn't pixels and it takes a lot of zoom to do so.

Stephen Fitzgerald wrote:I had no idea that the 4.6k was a "past model" it's just a different version in the Ursa Mini line. Their website has all three listed as active products, none are discontinued or legacy.

It clearly is a past model that is not discontinued. Similar to the GH4 vs the GH5 or the a7s vs the a7s2 and so forth. Customers of Panasonic or Sony understand this but for some reason BM customers do not. Why is that?

Gene Kochanowsky wrote:It clearly is a past model that is not discontinued. Similar to the GH4 vs the GH5 or the a7s vs the a7s2 and so forth. Customers of Panasonic or Sony understand this but for some reason BM customers do not. Why is that?

I’m not sure you’re understanding the difference between the status of the a7s, GH4 and UM4.6k. They are officially discontinued (you can find them in the discontinued product pages on their respective websites) and not in production. The 4.6k is still in production. There is a difference. I can understand your argument, it’s still an Ursa Mini though, I’m not sure if you want it to be a past model, but it sounds like you do, why is that?

Stephen Fitzgerald wrote:Well IF that's the case Blackmagic, PLEASE give original UM 4.6K the V4 color science AT LEAST, please and thank you!

If you shoot cDNG on the 4.6K you can choose to use Gen4 color in the raw tab of Resolve

timbutt2 wrote:the LUT would be an actual look. Say something like Orange/Teal, or Dystopian, or Noir, etc. It's applying an actual LUT that changes color profile to emulate a certain look. So thus the LUT gets attached to the RAW file inside the Sidecar. Inside Resolve then you can edit with that LUT applied, but as soon as you get to the grade you can choose to disable it to use the LUTs source PowerGrade Nodes or add the LUT in as a Node on it's own. But the idea is that the Sidecar file references the LUT you shot with so that you're seeing that as well.

That's how I'm interpreting this request. And, this is also how I would suggest it all works.

What you describe is how the ProRes files from ARRI Alexa/Amira cameras work in Resolve with two important differences:

1) The ARRI LUT is actually stored inside the file metadata, so you don't already need to have it loaded on the system. Resolve can read it right from the camera original file itself.

2) ASC CDL correction values can be combined with a LUT and both added in camera on Alexa/Amira. In Resolve you can choose to apply (or not) the LUT and the CDL values, with the latter being interpreted as primary corrections in a single node.
(this is covered in the "Using ARRI Looks" section on p1932 of the current Resolve v15 manual)

ARRI's workflow is quite flexible and future proof because of the ASC CDL addition. Not too many years from now, we'll all have to deal with SDR and HDR deliverables, and to do that most productions will be taking advantage of scene referred color managed systems like ACES or RCM. In those workflows, LUTs are specific to each on set display device and then the image is adjusted using ASC CDL values underneath, allowing the same look to be applied regardless of whether the output display is SDR REC709 or some level of HDR + REC2020 or P3 color.

Ideally, BMD will add a similar level of ability to more finely control the look metadata in camera, whether through ASC CDL values and LUTs or some other method of their own design.

Gene Kochanowsky wrote:Is is common among camera companies for their customers to expect past models of cameras to be upgraded to current model software functionality? I'm not aware of any camera company that does that. Why do BM customers expect this?

Well, Canon brought me at the mid of 2016 a firmware update for my XF305 - which is from 2010 - where they added WideDR Gamma, which is a feature from their Cinema EOS line. Last firmware update came 2017 - 7 years after the first release of the camera.
RED brought lots of features to older camera models, as long as it was possible by the hardware.

Fuji also does this: they'll keep rolling out updates until the hardware gives up and even then they'll often still add smaller features as long as the hardware allows it to older cameras.

JVC keeps updating it's LS300 camera.

There is a difference between updating and bringing the software up to the level of the current product.

It's not a good business model if you make money by selling cameras.

Gene, we know what you mean, but there is a flip side of the coin. Upgrading an older camera (within its physical limitations) can be a good business practice as it instills brand loyalty that the company will do its best to maximize the utility of its gear used in a professional context.

My state-of-the-art consumer camcorder (Canon HV20) received a minor firmware update (not to be confused with a firmware update like BRAW) and then was completely replaced by the HV30 that was replaced by the HV40 in a year. That behaviour from Canon soured me in two ways: no more consumer gear that is as disposable as a tissue and no more Canon motion cameras period. I don’t hate Canon, I use two of their quality printers. But the camera department isn’t my friend.

In comparison BMD is not a consumer ecosystem and they do tend to continue to update their cameras with unannounced features which are both reasons that I am brand-loyal. Yes they aren’t perfect with their track record of delivering announced features, but they have some balance overall by offering alternatives to help compensate where they have come up short.

BMD think BRAW is big. Way bigger than ProRes including ProRes raw. They are taking on Apple in a field where they have been a leader for many years. BRAW may not replace ProRes as an ubiquitous codec, but it’s going to eat an increasingly larger piece of pie just as Resolve is doing with its share of the post software market.

Dream big. But to fulfill that vision it needs to be added to as many cameras as is physically possible. Because the 4.6K sensor is the same as the Pro, I’m hopeful the original Mini 4.6K is third in line for the feature. BMD knows their sales figures and their projected sales. Both the Mini Pro and the BMPCC4K easily outsell the Mini 4.6K, but surely the sales of the latter camera merit a little more love. If not, of course, I’ll still make use of the Mini 4.6K camera, but my bet is BRAW will be so seductive that I’ll often turn to the BMPCC4K.

Rick, I get that BRAW could be a game changer. But in order to change that game it needs to appear on cameras other than Blackmagic cameras. BM putting it on older BM cameras is not gonna break that codec out into the larger world.

Now here is the odd thing, if BM works to get BRAW on other manufacturer's cameras it is creating it's own competition. If BM were a much bigger presence in the market that might make sense, but as BM stands now, it looks kinda crazy to me.

Game changer-- but needed on other cameras? I dunno how many other cameras run Redcode or Arriraw? I would argue either of them are much more game changing than, say, another RAW from a camera. Redcode, in as much as, well, boom, here you go, first "raw," and Arriraw inasmuch as, oh my god, we shot how many TB of data today? (and yes, I had the great job of ArriRaw on an Alexa65 and it's rather insane).

BRAW is nice-- it's nice to have it, it's a nice new thing. Game Changing? No, not really. It's just par for the course of lighter-weight RAWs coming to lower-priced cameras. It's nice; it's fun, it's great, I guess-- though honestly as a DoP I am slightly reserved about the ability of all my choices (and the directors) so easily removed in post. Granted, that's just part of the evolution of our jobs.

AdrianSierkowski wrote:Game changer-- but needed on other cameras? I dunno how many other cameras run Redcode or Arriraw?

This.

AdrianSierkowski wrote:BRAW is nice-- it's nice to have it, it's a nice new thing. Game Changing? No, not really. It's just par for the course of lighter-weight RAWs coming to lower-priced cameras. It's nice; it's fun, it's great, I guess-- though honestly as a DoP I am slightly reserved about the ability of all my choices (and the directors) so easily removed in post. Granted, that's just part of the evolution of our jobs.

I do think Braw is game changing for low-budget and indie productions that don't necessarily have the budget for PBs of storage and might not have post-house spec'd workstations.

I think much depends on how you qualify low budget. Hell, most low-budget productions I've been on have all been RED since in LA, basically renting a Red of some kind is cheaper than basically every other camera on the market-- including black magic. So low budget has been working on raw for a long time-- and ironically, higher budgeted productions have been some form of pro-res.
I think BRAW is great for no budget productions; but that's a wholly other beast. And hopefully BRAW might get into some kind of recorder-- like a Codex but you know, affordable. That would be very nice and really be a big deal for no budget and low budget productions in terms of work-flow streamlining. But time will tell. And in the end, honestly, I think many people will still just stick to pro-res or DNxHD because, while cameras change all the time, post really really doesn't keep up. Hell we're still making 2K DCPs . . .

You're right, I should have said ultra-low/no budget productions.

I think the next iteration of the BMD Video Assists will likely have the option to encode in Braw for cameras that can send out a raw stream - and with the HDMI-only Atomos Ninja V in the game, I do think that there will be enough pressure for camera manufactures to give us raw through HDMI as well as SDI.

Prores is still a good delivery format (and I think most broadcast TV still shoots Prores), and yeah, 2k DCP.... most 4k content delivery seems to be online (Netflix, Youtube, Vimeo, etc).

I think that's the real rub-- using BRAW as the de-factor RAW capture format on recorders for any camera which can output RAW. Now that would be a game-changer as yes, the next frontier, I think, in prosumer cameras is the RAW over SDI/HDMI as standard.

Gene Kochanowsky wrote:There is a difference between updating and bringing the software up to the level of the current product.

It's not a good business model if you make money by selling cameras.

With the JVC LS300 as an example. To completely do a new model is a major cost which has to be paid down (with low sales numbers of pro equipment). However, the LS300 has upgraded their features by update for years, allowing them to maintain the psy down on the existing manufacturing base and maybe cheapening parts. So, yesterday I still read somebody favorable to the camera's features. To me, ironically, I could have bought it at this price and feature level when it was released, and to me it's not much now. So, the updates have just kept it relevant and ashes going. However, it needed all those features at release, and something on the level of Pocket 4k festures by now. Anyway, just upgrading to BRaw on as many cameras as possible, enhances it's brand, as enhancing quality.

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

There were questions about Raw over HDMI discussed elsewhere, with it not being something HDMI is currently capable of.
However (and this is a vague recollection), isn't there something about Networking ability in HDMI?
Surely that would allow enough data to shift from camera to recorder to carry the Raw imagery.

Years ago, somebody I know came up with the Bayer over HDMI proposal. It can be done on any HDMI, you just have to repackage the raw into 4:X:X:X pixel schemes, or mono, and have equipment that extracts or displays it at the other end. The cable doesn't know what data it carries, so it can be done without the official standard. Axiom canwea group did it from this advice. You didn't even have to finely match Bayer pixels to normal pixel sub values, you can divide up the bit stream and package it into where there is space, on a bit by bit bases. HDMI is a number of large pipes, and a lesser one they pass ethernet over. I forget if they changed that now. But seriously, thurderbolt x or other pci-e based technologies is where the industry could have gone. So, it would be useful if somebody made cameras miniature infrastructure and recorders which did that. An optical thunderbolt cable will go a long way, and optical cable science has recently had such a giant leap in data capacity, I can't even remember the figure, but even older technology was in multiple Terabit/s territory. I am eyeing an optical technology over 100gb/s to use on a product myself.

BM, please change industry infrastructure to thunderbolt and optical. Our lives will be much easier, and if you are the only.one selling a complete infrastructure package using it, guess who gets the sales. Wiring long distance optical cables into studios and broadcast has to be cheaper and simpler than standard cabling.

There's a big difference between updating a camera and bringing its firmware up to the level of the latest version of the product.

Stewart Fairweather wrote:

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

There were questions about Raw over HDMI discussed elsewhere, with it not being something HDMI is currently capable of.
However (and this is a vague recollection), isn't there something about Networking ability in HDMI?
Surely that would allow enough data to shift from camera to recorder to carry the Raw imagery.

Everyone says that, but in the end HDMI is just a digital signal. You can tell that signal to be any data stream that the cable has enough bandwidth to carry. In theory, it should be easier for hybrid cameras to send out raw over HDMI since no in-body processing is required. You couldn’t plug the camera into a tv and see the image, but we’re taking about going to a recorder, not straight into a tv.

Has anybody got any frames of the different recording modes filmed back to back, in order to judge the quality difference between the modes debayered please?

Some people are claiming 12:1 is very good, but I would like to compare how good compared to 3:1 and between. Q0 and Q5, which is likely what I would want to use.

Wayne Steven wrote:Has anybody got any frames of the different recording modes filmed back to back, in order to judge the quality difference between the modes debayered please?

Some people are claiming 12:1 is very good, but I would like to compare how good compared to 3:1 and between. Q0 and Q5, which is likely what I would want to use.

These are not mine - courtesy Nate Porter on the Blackmagic Forums:

I just did some quick tests. I haven't examined the footage yet but I did record a ton of different codec types in front of a green screen. Sorry they are short clips, but I didn't have much time to do it. Also this is by no means a great green screen test, but hopefully it is sufficient for learning about the codec and what it can handle under better circumstances.

File types I recorded
BRAW 3:1
BRAW 5:1
BRAW 8:1
BRAW 12:1
BRAW Q0
BRAW Q5
DNG 3:1
DNG 4:1
DNG Lossless
Prores 422 HQ
Prores 444
Prores XQ

Here is a link to the google drive folder https://drive.google.com/drive/folde...PY?usp=sharing

I'd love to know what information you can gather from these samples.

michaeldhead wrote:

Wayne Steven wrote:Has anybody got any frames of the different recording modes filmed back to back, in order to judge the quality difference between the modes debayered please?

Some people are claiming 12:1 is very good, but I would like to compare how good compared to 3:1 and between. Q0 and Q5, which is likely what I would want to use.

These are not mine - courtesy Nate Porter on the Blackmagic Forums:

I just did some quick tests. I haven't examined the footage yet but I did record a ton of different codec types in front of a green screen. Sorry they are short clips, but I didn't have much time to do it. Also this is by no means a great green screen test, but hopefully it is sufficient for learning about the codec and what it can handle under better circumstances.

File types I recorded
BRAW 3:1
BRAW 5:1
BRAW 8:1
BRAW 12:1
BRAW Q0
BRAW Q5
DNG 3:1
DNG 4:1
DNG Lossless
Prores 422 HQ
Prores 444
Prores XQ

Here is a link to the google drive folder https://drive.google.com/drive/folde...PY?usp=sharing

I'd love to know what information you can gather from these samples.

Just putting this here, since that link above doesn't seem to work.
https://drive.google.com/drive/folders/1MH2xLzaHsxILQpwlB5jt2gDYI8H-n7PY?usp=sharing

Nate Porter wrote:
Just putting this here, since that link above doesn't seem to work.
https://drive.google.com/drive/folders/1MH2xLzaHsxILQpwlB5jt2gDYI8H-n7PY?usp=sharing

Thank You!

Gene Kochanowsky wrote:There is a difference between updating and bringing the software up to the level of the current product.

It's not a good business model if you make money by selling cameras.

It's also not always feasible, since newer cameras have newer hardware... which in many cases includes more powerful processors and FPGAs.

AdrianSierkowski wrote:Hell, most low-budget productions I've been on have all been RED since in LA, basically renting a Red of some kind is cheaper than basically every other camera on the market-- including black magic. So low budget has been working on raw for a long time-- and ironically, higher budgeted productions have been some form of pro-res.

That's one of the ironies I ran into. Using an 8K Red actually SAVED our production last year money on storage. Yes, saved. Because 8K Redcode is around the same size as 4K ProRes HQ, which means it's significantly smaller than 4K ProRes 444.

Sony's Peter Crithary cited that as one of the advantages in using high end cameras; if we'd shot that in cDNG on a 4.6K, we'd have gotten comparable quality with the fringe benefit of preventing our editor from mangling as many of my compositions as he did with his excessive reframing... but we'd have required 2-3x as many hard disks for all of that data. And a lot more offloading time.

Sony's CineAlta line has had a clip based compressed raw coded for a while also, though Red's is more efficient.

Braw makes that advantage available to a LOT more low budget productions. It's a win for BMD customers whether it's a game changer or not. If it gets adopted by Atomos and/or Convergent Design, then it would become huge... and I'm betting that they won't want to be left behind when the indie world starts embracing it.

As Grant stated in the video most have watched, Blackmagic RAW is currently available for the URSA Mini Pro in beta release and also planned to be made available for the Pocket Cinema Camera 4K down the line. Once those are implemented we will look at the possibility of rolling Blackmagic RAW to other Blackmagic Cameras. Any updates would be released on the support page of our website.

Tony thanks for coming on and trying to clear this up. I'm still a little confused
Grant actually says in the video "That's going to be all Ursa Mini Cameras eventually" (yay!)
Which is very different to "we will look at the possibility of rolling Blackmagic RAW to other Blackmagic Cameras." (meh... but still better than NO)

Did he miss-speak?