Is BRAW really RAW?

Each of them can do it themselves, they don't really need BM for this. It's financial and strategic decision to give RAW out of camera. There are no technical difficulties- nothing more than in case of other (already debayered) formats, like ProRes etc. One RAW format would simplify things, but I I doubt it will ever happen.

And yet the cinema cameras priced between $8K and $10K don't have internal raw recording, and most of them are on board with ProResRaw.

Yes, because it's business/strategic decision, not technical one.

The question is whether or not BMD will be willing to share the specs for encoding to other camera manufacturers...

BMD doesn't even share the general technical information about the codec, I think sharing encoder to other manufacturers is wishful thinking at best in current stage. Let BMD produce a whitepaper first about this new "open standard". All the current official info has been saying the same things in different wording without actually saying anything. Partial demosaic means absolutely nothing in itself and it is the only thing they have actually said besides having CBR and VBR modes that has even mild technical hint in it.

Yep, lots of pr talk without any real info about this so called "open standard"

Hendrik and Mark.

I want to ask your opinion if the following link might be what is causing these issues at 3:1, and if it still exists at finale uncompressed render:

viewtopic.php?f=2&t=79208&p=443059#p442982

Thanks.

Hendrik and Mark.

I want to ask your opinion if the following link might be what is causing these issues at 3:1, and if it still exists at finale uncompressed render:

viewtopic.php?f=2&t=79208&p=443059#p442982

Thanks.

I made my pixel peeping in Nuke using braw sdk and reader plugin I wrote, to my best knowledge it is full quality image that I got from decoder.

Did you render out a frame uncompressed or from the live view Hendrik?

P.S. I've just been watching a review of the Red Hydrogen phone, as many doubts I have about the pocket, I am glad I am here instead. No wonder they didn't release camera details in it.

BM has already stated that they are not sharing the encoding side of BRaw, so you are only going to find it on a few BM cameras, as the new codec is very much, camera specific, which each camera typemhaving its own recording code.
Cheers

Did you render out a frame uncompressed or from the live view Hendrik?

There is no "live view" in Nuke in the way you are probably thinking (like Resolve viewer vs rendered footage), so writing anything out will make no difference. Float array of image data is copied from SDK returned pointer to Nuke scanline arrays. SDK allows decoding in half, quarter and eighth resolution, which all provide data in respected size. I haven't found any other lower-quality decoding option or way which might interfere with the data, so I'm pretty sure decoding at full resolution is the "master" image.

I sort of am referring to BRaw as a black box system, likely doing the display for Nuke. So, you never would see the authentic image till finished, and never know for certain. Nevermind.

I sort of am referring to BRaw as a black box system, likely doing the display for Nuke. So, you never would see the authentic image till finished, and never know for certain. Nevermind.

I'm not sure what you mean by by authentic image? Braw is not doing anything for Nuke, I am, in my code. Decoder has no mechanisms for displaying anything anywhere, it only handles image data. Braw decoder part ends with giving me a pointer to an array of floats (either interleaved RGBRGB... or planar RRR...GGG...BBB... format). I memcpy these floats from there and what comes next has no relation whatdoever to braw sdk, so image is "finished" at exactly that moment when decoder calls a specific callback (ProcessComplete) and provides the memory pointer. If I were to write a binary data writer plugin to examine braw frames, this same data would be dumped to file, so there is no difference between view and render, except that for view, float data has to be converted to 8 bit representation for 8bit screen, which you must do anyway because no display "eats" float data. Nuke renders viewport using OpenGL and unlike Resolve, imaging path is pretty clearly documented. I might even go as far as render image directly in OpenGL myself, as an overlay on Nuke viewer.

In Resolve, braw implementation might be a black box up until image lands on screen, but for Nuke the black box is only the decoder, not what comes next.

So, changes don't go back through BRaw to encode the replacement frame in the BRaw file, it dumps a frame compressed into whatever format during editing (doesn't seem efficient)? I would have thought they keep the data in BRaw and apply changes through that, unless it is transcoded to a new file. Therefore the version viewed doesn't have to be the same. I thought you could edit and grade BRaw directly?

So, changes don't go back through BRaw to encode the replacement frame in the BRaw file, it dumps a frame compressed into whatever format during editing (doesn't seem efficient)? I would have thought they keep the data in BRaw and apply changes through that, unless it is transcoded to a new file. Therefore the version viewed doesn't have to be the same. I thought you could edit and grade BRaw directly?

Wut? Editing (image processing in software) does not work on compressed files, it is converted from what decoder gives to whatever is the actual working format of software. It might be 8bpc (what AE defaults to), 16bpc ints, half or full floats etc. For Nuke working format it is 32bit floats so I can dump data directly from decoder to Nuke frame buffers. It is also possible to request 8 and 16bit data from decoder. There is no going back to decoder anywhere, once you get the frame you are done. Raw development (processing) is done inside decoder, settings (like gamma mode, exposure, iso etc) are fed into decoder when requesting decoded frame and decoder outputs frame data, thats it. You can't keep data "in decoder" and edit braw directly, because, well, you want to modify it, display it etc.

After reading some stuff from other forums, it seems that there is a misconception floating around that braw sdk somehow handles the whole imaging chain from decoding to screen, which supposedly makes it so fast. This is not what it does, and is technically practically impossible to do. Whichever application is using the sdk, to actually do something (including processing, viewing, encoding, anything actually) with image, it must be pulled from decoder, as data array, at which part the involvement of decoder in processing braw file ends.

Sorry for the delay Hendrik, was too tired to get into it the other night.

But, so no saving back to BRaw format, or chopping and changing BRaw files? Seems a bit of a let down.

But, so no saving back to BRaw format, or chopping and changing BRaw files? Seems a bit of a let down.

You can chop (trim) braw as it is intra-frame format, SDK provides methods for this. But chopping is simply saving a bunch of frames to another braw file, without decoding, nothing more. You can't save (encode) anything to braw or change the file content (except chopping). It is possible to trim so that current development settings are written to new file, overriding original metadata. From SDK docs:
"At this time, the user can run the ‘trim’ operation which will bake the sidecar changes into
a newly created .braw file saved to disk."

To keep changed development settings with braw, sidecar file can also be used. SDK has for example method for generating new sidecar file from current settings. This allows some additional flexibility without fiddling too much with original files and users can choose whether to manage sidecar files or bake development to new braw files with trim operation. Keep in mind though that this baking only changes the metadata, not image content in braw file. And this metadata is then used in decoder for processing the image before handing it over.

But, so no saving back to BRaw format, or chopping and changing BRaw files? Seems a bit of a let down.

Why would anyone expect an NLE or compositor to EXPORT braw? That's completely nonsense.

Of COURSE the SDK just decodes frames; what would be the point otherwise? If the SDK handled the entire imaging pipeline, it would be useless.

Braw seems to be intended as a capture/editing format, not a delivery format and I think that it's going to be an amazing capture format.

Thst is my take also Michael. BRaw is not a final deliverable format, unsless you just hand over the BRaw original files to the client to process and edit.
Cheers

Hendrik, thanks, sounds like what I was expecting.

But, so no saving back to BRaw format, or chopping and changing BRaw files? Seems a bit of a let down.

Why would anyone expect an NLE or compositor to EXPORT braw? That's completely nonsense.

Of COURSE the SDK just decodes frames; what would be the point otherwise? If the SDK handled the entire imaging pipeline, it would be useless.

Nonsense. What's the point of using as an intermediate codec like cineform and for the software to work in that format. Seems some people have mislead me elsewhere.

Nonsense. What's the point of using as an intermediate codec like cineform and for the software to work in that format. Seems some people have mislead me elsewhere.

You can't really use cineform raw as an intermediate codec either. Cineform doesn't allow encoding already debayered image into its raw format.

Nonsense. What's the point of using as an intermediate codec like cineform and for the software to work in that format. Seems some people have mislead me elsewhere.

The idea of ENCODING to raw is nonsensical other than at capture time. There's no point; it's called "raw" for a reason.

There might at some point be some options for transcoding other raw formats like cDNG to braw, but since braw is partially camera based, I think it's unlikely.

Transcoding is decoding one format and encoding another, so it is a matter of linguistics.

This camera based argument is getting kind of silly, where is the camera when you are decoding braw? All that is needed is contained in braw. I highly doubt there is anything camera related in the decoding step of braw and for encoding, all that must be done is prep data in certain way. You don't need a camera for this. At worst one can do the exact inverse process of decoding and arrive at something that can live in braw format just fine.

Transcoding is decoding one format and encoding another, so it is a matter of linguistics.

That's inaccurate. Transcoding raw to raw is just repackaging data, not decoding it. Going from cDNG to braw might be different due to the intermediate step, but in general, if all you're doing is changing the container and not the data, then you don't need to be able to decode it. That is in fact how a lot of raw image processors were able to convert stills from proprietary formats to cDNG, and why the process is lossles... because they don't decode the images in the process.

Well, theoretically you could export the final edit by streaming the BRAW data into a new single container and have all chosen color settings frame accurately applied into the Sidecar file.

I just don't see the advantage of doing this...

Transcoding is decoding one format and encoding another, so it is a matter of linguistics.

That's inaccurate. Transcoding raw to raw is just repackaging data, not decoding it.

Only if format is uncompressed. If it's compressed it's also taking RAW data, compressing and saving into new container. BM RAW is slightly different as bit more processing is done on RAW signal.
RAW (when you forget how it looks) can be treated as "normal video"- there is nothing special about it, except fact that it's monochromatic and in order to be usable needs to be debayered. Some RAW formats allow for easy access to RAW data, some won't let you do this, eg. RED. You could even have player which shows you RAW without debayering (not sure what for but its very easy to implement).
RAW in most cases also have richer metadata, as it may be needed for accurate debayering process.

Transcoding raw to raw is just repackaging data, not decoding it. Going from cDNG to braw might be different due to the intermediate step, but in general, if all you're doing is changing the container and not the data, then you don't need to be able to decode it.

You are mixing decoding with debayering. You still need to decode the source to get your raw data. You can't just dump cineform raw format binary blob into braw container and call it a day, braw knows nothing about wavelet compression nor the way how data is stored in cineform file. You can call it repackaging if you like, doesn't change the decoding-encoding necessity. Repackaging is possible only when you can dump frame data directly into another container, this is rarely possible.

Nonsense. What's the point of using as an intermediate codec like cineform and for the software to work in that format. Seems some people have mislead me elsewhere.

You can't really use cineform raw as an intermediate codec either. Cineform doesn't allow encoding already debayered image into its raw format.

Thank you for that last reply Hendrik.

Hendrik, I said cineform not cineform raw. However, I take your point, seems they are not as advanced as I presumed. But unless everybody suggests we should all debayer to 4:4:4 uncompressed and work in that with 1GB/s data rates K suggest people stop finding fault and listen up.

Shifting over to BRaw topic, and using it as an intermediate:

1 smaller easier to shift and store datarates.

2. In the old days, when storage was at a premium and slower than today, they even compressed files leading to faster file use of it could be decompressed fast enough. Hence BRaw would be interesting if it resulted in that too.

3. Moving frames doesn't require intra frame compression decode.

4. Changing general color levels is something that can be handed in meta data.

5. Changing localised image data is not only just an inverse Bayer (throw away 2/3rds 4:4:4 values) but can be calculated straight into un-debayerd values, and even Bayer compression. But is likely beyond cineform, red etc, as, as far as I have understood, there AREN'T geniuses on this.

6. Even if you take a frame, decode it for display and modification, what's a real issue with storing it back, rather than decode every frame to 4:4:4 display and recompress for storage.

7. If it's good enough for complex inter formats why not intra.

Thankfully, with the change in my cancer treatment, I can remember what I was talking about rather than just feel it vaguely in the back ground. So, yes, there is good use of BRaw as a editing grading and delivery format. If one puts in the effort to figure out how it might be useful.

Hendrik, I said cineform not cineform raw.

Cineform as a YCbCr or RGB codec is just as any other, why do we need another intermediate codec to do the same thing again with no clear benefits? Only thing braw currently brings to table is fast decoding of supposed raw data, and it is still unclear how raw that raw actually is.

What you are currently advocating is working in bayer pattern data, which probably does not fly for anything other than single-pixel color operations. Spatial operations will be in trouble, including any kind of simple sharpens, blurs, transforms etc. Imagine a simple situation for example: you have two images that you want to blend together, and one is offset by one pixel to left. Photosite data does not align anymore, so how do you imagine doing a merge on raw data in this situation?

I think you are missing the part where you need RGB data for each and every pixel because otherwise you can't really do much meaningful stuff with that image. So yes, we are all working at this 1GB+/s data rate. Resolve does its math on floats, so UHD stream at 24fps is 24 * 3840 * 2160 * 4 (bytes per channel) * 4 (channels, incl alpha) =~ 3GB/s. You don't have to pull data from disk at this rate because storage formats are converted to floats in GPU but internally, all the processing is moving data at massive rate.

For view only, yes, it is be possible to do debayer as a view process (which is what all these braw and red etc players are basically doing), leaving data in its bayer pattern form, but for anything else you need to debayer. And then throwing off 2/3 of data after processing will produce massive degratation which eliminates any real use as an intermediate format. For delivery, why not, but there are already better delivery formats with lower data rates so it achieves nothing. And if you leave the raw part out, you basically get a new flavor of Prores, DNx and so on, which all use DCT encoding just like braw (from the looks of cuda kernel code BMD uses Loeffler algorithm for fast DCT/IDCT calculations). What benefit does braw give in such case? Open and free encoder would probably be the only edge it could have.

I am having another turn. But I was talking about pulling from the disk, the actual data manipulations flies should be a lot lot higher than 3GB/s.

But there is clear advantage. Size, speed.

Each pixel tends to hold data on two or more primaries, which can be calculated, and even debayering to 4:4:4 does that. But there are ways to get closer to real data. Arri colour science was doing this many years back. So, you can do operations on the imperfect Bayer data. In such cases you can complete a full frame data do a calculation, and extract a Bayer pattern from it, and be.hioefully back where you started plus some adjustments. Disk speed is the issue, and localised adjustments, or restorations adjustments and rebayering not only would likely provide duce less datarate but also less calculations then the conventional method. When you you design something completely new these are the sorts of things you talk about.

You miss the point about the 2/3rds data, that is invented/reconstructed data that can be again during debayering, you get 0% degregation if you do it right, just debayer again. The when issue is to make the correct adjustments and for them to carry through the rebayering into the next debayer. The missing adjustments being filled in by the debayer. The 4:4:4 data is not needed, except at delivery. Once we get to 16k, will we need to debayer at all, as our eyes will be doing it from a correct distance.

I advocated a version of this for cineform raw around 14 years ago, to use as a high quality free to air tv channel (to reduce the amount of channels by using two) based on my older compression theory work in the 1990's. I remember my freind, the top engineer, got into an indignit argument with me because I called the bluff on one of the naive principle laws of compression. Of course, he was wrong, again, but couldn't see it, but time did.

But yes, you can have h265, but you can have much higher quality this way, particularly using inter compression. But this is old work.

Does anybody know how redray codec works? We were told things, but nobody ever followed up with what was happening. Those people would have read my public discussions (which, likely like their world's best codec, wasn't the real good stuff I was looking at). Hence why I'm annoyed at the waste with certain parties accross the industry).

Doing, is not.the same as coming up with stuff worth others doing. But I'm glad to talk to you Hendrik, because you can really talk.

You miss the point about the 2/3rds data, that is invented/reconstructed data that can be again during debayering, you get 0% degregation if you do it right, just debayer again.

Lets say I have a 2x2 photosite image (RGGB) which I debayer to 2x2 pixel image. All pixels will have same channel values, lets say 0.0. Now I change the 0, 0 position pixel value to 1.0 in green channel. I can't really imagine a way to rebayer it to RGGB so that when reconstructed, you again get 2x2 RGB image where every other pixel besides 0, 0 is zero and this pixel has green channel value 1.0 This kind of reconstruction of data from 1/3 of what is left with 0% degradation is not possible, even theoretically. You might get something that is visually similar (when looked from far enough), but you can't achieve value-identical result which 0% degradation means.

Your idea of rebayer-debayer might work (and I doubt it even then) only if data is not modified in a way that causes filtering or local color changes at frequencies higher than X (single pixel modification example). But as I wrote, any spatial operation done on image in processing stage will throw this logic off.

I advocated a version of this for cineform raw around 14 years ago, to use as a high quality free to air tv channel (to reduce the amount of channels by using two)

This is basically rebayering-debayering for final viewing only, meaning delivery codec. Which might actually be a neat idea. But it is not intermediate. I don't know about redray, but thinking about it, if one had a display device that natively worked with color matrix, not full rgb data for every image element, delivering data as color matrix would eliminate redundant information that won't be displayed anyway. And I wouldn't be surprised if with the advent of 8K plus screens, this will become a standard.

Going from 4:4:4 to Bayer to 4:4:4 again, is basically the same as filming the original image to Bayer and debayering (depending on the version of 4:4:4). Unless you think that Bayer is really lousy and doesn't produce good results (I think it is lousy, but in the end the results are ok).

In what you describe, the movement to debayer solves this, even if it is a local debayer/estimation. Think about normal debayer proceadures as just one way to do it, and that there are others. In design it is common to think the standard way is the answer/way. The optimal way is the answer, and it can take a lot of time and effort to find it. You see this in design, and the slow steps with and around the conventional slows progress a fair bit. A lot of people are employed to make progress in bits and pieces around the conventional. Doing things more rationally (not the conventional) can increase the rate of progress by magnitudes. I can't be certain how much, because unconventional progress had to be rational and many people may struggle to have rational unconventional ideas (which indicates that people hold onto the conventional because they are irrational, or find it hard to rationalise properly. Interesting.). But if everybody was properly rational in finding new optimal solutions you could go from babe men to start travel in maybe 1000 years, maybe even 100 if you worked at it. But in reality anything below 500 years in accelerated. If we look at cars to space shuttle and it, that's around 100 years of more technology then we know of in prior history. Now, the basic functionality of car and every needed thing before it is not that much, so another hundred years, except for knowing chemistry and physics etc. So that is what? Could a group of people not out standard models in 10 years, yet a lot of observation in study living g and work went into it. Now, the required population, economic growth and infrastructure comes into it So, hundreds of years. I was going say maybe 200 years as a minimum, but then it came to me it is actually 100. That is mind boggling even to me. How does that work? Say 99.99% of human progress is superfluous to technical progress, the last 4000 years compressed down to less than 1/2 a year (and I thought I might had undershoot with the 99.99%, let's say 99%, that's 40 years, 90% is 400 years) but there is a whole lot of living and living involved, so the 1/2 years worth of work will probably take a lot longer (as you have to also figure things out progressively. But yes, a world full of educated geniuses could figure it out in 1/2 a year. Scarry). So, why haven't we, we (including me) are maybe a bit too incompetent.

Amen! Most of us are only human.


Sent from my iPhone using Tapatalk

You are mixing decoding with debayering. You still need to decode the source to get your raw data.

You should learn to read more carefully.