Is BRAW 444, 422...?

In addition to pleasing and satisfying is all well and good but... I also would like to include VFX/Post in this discussion.

I started in this world with VFX and animation. I remember the days we pulled great keys from tape cameras (betacams) which HD and 422 were like 8K and 444 today. I've pulled great keys from 8bit h264 from first generation video DSLRs.

I can assure you the worries in this thread are mostly "numbers on the paper" importance. Not "end result" problems. At least not if you know what you are doing and then we get into that silly discussion of these new guys wanting the gear to do everything for them.

The only thing it would make sense is headroom for a good push up in color grading. But again, we alrealy have plenty since first BMD cameras.

now im feeling old! haha -- - these young whippersnappers... camera tests..... bah.... i'm like Facepalm... GET OFFF my SETTT I croak! (get off my lawn voice)

now im feeling old! haha -- - these young whippersnappers... camera tests..... bah.... i'm like Facepalm... GET OFFF my SETTT I croak! (get off my lawn voice)

Young padawans

A GRBG bayer pattern of size 3840x2160 can be used to create an image of 3840x2160 with three R,G,B channels but it does require some kind of extrapolation step, and if the algorithm isn't super smart we could end up with a picture a bit blurry. Probably enough to say "this looks a sharp 1920x1080 picture".

All BAYER CMOS cameras must do this though. That’s the case with every single camera out there.

We’re using the WRONG terminology to describe this issue.

There’s a MASSIVE difference between 422 and 444 if you’re colour grading and especially if you’re doing keys.

That’s not accurately describing what the difference is here though and on top of that you’re using the wrong terminology.

Let’s talk about the differences but at least use the right words.

JB

If you're angry about terminology please create a new word or tell me which one to use.

In all case, it remains true that "4:2:2" could be interpreted as "chroma channels have twice less vertical and horizontal resolution compared to the luminance channel" and this likely the case for .BRAW. Now, maybe it wouldn't be possible (or not practical) to get something better out of the camera/sensor anyway so that's not a big issue

I’m not angry.

But you’re using the wrong words.

I mean you seem to be someone that is a software developer. Why is it that a Cinematographer knows this is wrong but the post / app developer person wants to keep using the wrong terms ?

What’s wrong with

Partially Demosaiced ?

Or just YUV ?

Unless you know otherwise, which is why I asked you why you’re using these incorrect terms ?

JB

I don't want to keep using that term, there's just not a better alternative until we solve this issue and BRAW is fully reversed engineered. This wouldn't be a question if BRAW specs were truly opened.

YUV theoretically stores as much data as RGB (it could even be argued it stores more according to the situation) so it's not the right term to use in this discussion. Partially demosaiced is too vague for us to infer what amount of information about the chroma is left out using .BRAW versus others RAW formats.

422 is a good term to say to express there is twice as less information vertically and horizontally in chroma compared to luminance.

I could be as pedantic : "You are using the wrong terminology, as what's inside BRAW is YCoCg not YUV" but that wouldn't lead us anywhere.

I don't want to keep using that term, there's just not a better alternative until we solve this issue and BRAW is fully reversed engineered. This wouldn't be a question if BRAW specs were truly opened.

Like RED do with their SDK ? It’s not going to happen I don’t think. They want to protect this IP....

YUV theoretically stores as much data as RGB (it could even be argued it stores more according to the situation) so it's not the right term to use in this discussion. Partially demosaiced is too vague for us to infer what amount of information about the chroma is left out using .BRAW versus others RAW formats.

But there’s also other things that happen within the Blackmagic RAW process. Like sensor profiling...that’s unique to BRAW. So it’s hard to compare like for like....

422 is a good term to say to express there is twice as less information vertically and horizontally in chroma compared to luminance.

Why do you come to this conclusion ? Where do you get this information from ? How do you make this conclusion ?

I could be as pedantic : "You are using the wrong terminology, as what's inside BRAW is YCoCg not YUV" but that wouldn't lead us anywhere.

I’m not familiar with what that term is ? Would like to explain your case for making this the “right” term in your view ?

JB

Antoine, I dont mean to disrespect you or whatever experience you might have but I think it is unwise to try to correct someone so experienced and so close to Braw development as JB. The discussion is not going anywhere fruitful.

Antoine, I dont mean to disrespect you or whatever experience you might have but I think it is unwise to try to correct someone so experienced and so close to Braw development as JB. The discussion is not going anywhere fruitful.

https://en.wikipedia.org/wiki/Argument_from_authority


It's really not about who's right or who's wrong. I don't care, I continue to participate in this topic because I really think something useful for everyone could come up. Let's not fall into the internet forums trap thinking everyone is defending at all costs its own view. I am ready to change my view if given the facts.

I am not correcting JB, he is the one correcting us for using YUV 4:2:2 and 4:4:4 while I think they are useful analogies.

To continue with Cinematographer vs. software developer comparison, the developer will tell you "you'll loose 10% accuracy using this technique versus this other technique" and the cinematographer will tell you "it doesn't matter there are 5x others factors more important at play, I will continue using BRAW it's great". So they are both useful here.

And don't take me wrong, I would love to be able to tell everyone Blackmagic RAW is awesome and provides perfect accuracy, I develop and sell plugins for people like you to use Blackmagic RAW every day . What I can see for now is that BRAW is not "fully RAW". Even if research about BRAW shows it is not "fully RAW" as I expect my opinion so far is that it's still a great tradeoff between RAW formats that need more space and processing power to develop and others formats like H264 that have too much color processing baked in and not well suited for video editing. The most interesting comparison I'm interested in is .BRAW versus ProRes 4444

Like RED do with their SDK ? It’s not going to happen I don’t think. They want to protect this IP....

Fr BRAW I'm sure it will get reversed at some point, providing useful answers for this topic. And yes you're right there are tons of stuff they are doing in between that is very relevant so knowing about the codec isn't the end and I'm not sure anyone will reverse engineer what's happening inside their cameras it's too much work.


In all cases I'm thinking of writing a technical article about if Blackmagic RAW is really RAW / Why it would matter or not etc. So your opinion about BRAW is most welcome here

422 is a good term to say to express there is twice as less information vertically and horizontally in chroma compared to luminance.

Why do you come to this conclusion ? Where do you get this information from ? How do you make this conclusion ?

Do you mean in general or in relation to BRAW ? In general it is very simple, given one frame RGB or YUV 4:4:4, transformed into YUV 4:2:2 you will loose information in a predictable way. Mathematically there exists multiples YUV 4:4:4 frames that maps into the given transformed YUV 4:2:2 frame, so it means guessing the original RGB or YUV 4:4:4 frame requires some third party knowledge about the frame (for example it looks like all the progress around machine learning could be useful here to recover missing information).

Sorry if my vocabulary isn't precise enough, English isn't my mother tongue.

In all cases I'm thinking of writing a technical article about if Blackmagic RAW is really RAW / Why it would matter or not etc. So your opinion about BRAW is most welcome here

I assume you are aware of this:

https://cml.news/g/cml-raw-log-hdr/topi ... 0,25749037

best info you can find so far.

In all cases I'm thinking of writing a technical article about if Blackmagic RAW is really RAW / Why it would matter or not etc. So your opinion about BRAW is most welcome here

I assume you are aware of this:

https://cml.news/g/cml-raw-log-hdr/topi ... 0,25749037

best info you can find so far.

Ahh, Daniel's there, actually a few familiar looking names. Been wanting to find that thread again. There was another thread where they found jpeg mentioned in the
uncovered headers.

Why don't we stick to accuracy box results so every viewer is happy, rather than the opinions of a person here or there?

Ever hear of cumulative errors, like a cluster .... for quality. A little bit of, itys good enough error, here, and there and eventually it gets noticeable and disastrous. Ask any engineer, and if they don't agree, they are likely not good at it.

You think they used to hand rotoscope big features because it doesn't matter when they are on the big theatre screen viewed from front seating? People who do business are thinking about making money from more seats in the house.

John would have very little to do with developments, except in vital feedbacks.

Apart from feedback, non engineering camera operators have contributed next to 0% to modern camera technical developments. It's engineers and other technical people who have made the cameras and even film technology, to make it as seemingless and practical as it is for operators. They are the true heros.