Denoising diminishes braw and prores detail

Did you know that 90% of the work on Alexa in Germany is shot in ProRes? Got this first hand from the biggest rental service. Just to put things in perspective.

And probably the vast majority of US TV has been 12 bit ProRes 444 too.

Certainly most of my shows in the past years have been.

JB

First option: Choosing between Prores and cDNG is hard. I always have to weigh the need to shoot RAW. I prefer RAW, but Prores is often used. Because its good enough(mostly), faster, and economic. (Prores also suffer detail loss compare to cDNG)

Second option: Choosing between Prores or BRAW is easy. Its Prores, ONLY when the customer requires it. Meaning, I shoot RAW(BRAW) most of the time.

Did you know that 90% of the work on Alexa in Germany is shot in ProRes? Got this first hand from the biggest rental service. Just to put things in perspective.

Good info, I did not know this. And it’s a valid point from the perspective I you believe am saying Prores is not good enough. Ironically it strengthens my belief about BRAW. Prores is 100% a Professional format used by many. Also FX work. It’s a good format. That’s not my point though.

You should also add to the equation that the alexa can shoot at higher quality Prores options.
The p4k can’t. That’s a mistake by many. They shot (Game of thrones) mostly on prores, but not HQ 422. With BRAW you have a savant that is somewhere between 422 and 444 at 12bit. Hence my choice and others. RAW formats are often slow and expensive, but they are flexible. BRAW is cheap, fast and flexible. I know professional photographers that shoot JPG with they’re professional camera because it’s faster and they believe it deliver good enough IQ. Speed matters. Hence I use BRAW like many others.

Absolutely, I take BRAW over ProRes as long as the client doesn't want the footage right away.
My point was, that ProRes is good enough even for demanding clients and ProRes isn't lossless, even at the highest profile.

What’s the practical difference between BRAW and ProRes 12bit 444? I’d suggest they are very similar and certainly closer than BRAW and what most people consider to be ‘RAW’ which is unprocessed RGB sensor data. Like I have said numerous times I think BM should have called BRAW ‘BRES’ and then these discussions would be largely irrelevant.

Excellent post above Fabian. I didn't want to quote it, since it was quite large. I think it pretty much sums up the reality of a $1200 camera, which pretty much gives you the world, and then asking for it to do a ton more. Even as someone that works on documentaries or non-fiction programs, you should still consider your shots and get the best shot every time and not rely on cropping in to save yourself.

Uli's post is very telling as well. There is a lot of great work out there shot in ProRes as JB confirmed. If you know what you're shooting and have to crop-in, then use ProRes.

I admit there is not much of a difference between BRAW and ProRes 444 XQ in log.
But: BRAW is smaller at the same quality level and the Pocket doesn't offer ProRes 444 XQ anyway.

Absolutely, I take BRAW over ProRes as long as the client doesn't want the footage right away.
My point was, that ProRes is good enough even for demanding clients and ProRes isn't lossless, even at the highest profile.

Uli, is that mostly TV production.

I certainly thought BM could have had a more Braw like ProRes with look set in Meta data, making a quality quick handoff that you can flex in post if you need too. You wouldn't have to shoot raw normally. Mind you, I also would like a vertical colour filtering sensor like foveon does with ProRes 4:4:4 too). Unfortunately the Sony vertical se sir is not anywhere near good enough. So we aren't going see it in a pocket that way soon.

What’s the practical difference between BRAW and ProRes 12bit 444? I’d suggest they are very similar and certainly closer than BRAW and what most people consider to be ‘RAW’ which is unprocessed RGB sensor data. Like I have said numerous times I think BM should have called BRAW ‘BRES’ and then these discussions would be largely irrelevant.

Thats a good question. Hopefully some at BM can give a good answer to that. Still there is quite alot MB saved using BRAW Q0 compared to Prores XQ. Maybe Prores Raw should also be thrown into the mix, it also record at variable bitrate similar to Q0 and Q5.

Uli, is that mostly TV production.

I certainly thought BM could have had a more Braw like ProRes with look set in Meta data, making a quality quick handoff that you can flex in post if you need too. You wouldn't have to shoot raw normally. Mind you, I also would like a vertical colour filtering sensor like foveon does with ProRes 4:4:4 too). Unfortunately the Sony vertical se sir is not anywhere near good enough. So we aren't going see it in a pocket that way soon.

Yes. The Alexa is used a lot in TV production, movies are only a small part overall.

Well, there is the sidecar and you can convert quickly, but some clients want the footage and nothing else.

Regarding Foveon:
it looks like even Sigma gave up on it for moving images, their new Sigma fp has a Bayer sensor.

They patented a moving image sensor maybe 2017, and was working on this with there phone sensors. Unfortunately their new foveon design for the fuller frame L-Mount, didn't work out yet.

OK, so I did some further tests with the city shots I did - to find out a way to improve the perceived sharpness and detail.
Because of the forum image upload restriction to <1 MB per image, I did an HD center crop of the 4K DCI source. This allowed me to use as little JPG compression as possible.

CAC = Chromatic Aberration Correction
SNR = Faster Spatial Noise Reduction of chroma only, set to 50 (this gets rid of most of the colored moire)
SRxX = Superresolution at xX

This is our BRAW Q0 source image. Just my LBK-Lut applied and in the RAW tab ISO set to 100.

BRAW Q0 as is.jpg (920.34 KiB) Viewed 14362 times

BRAW Q0 but with CAC and SNR

BRAW Q0 as is - CAC - SNR.jpg (745.35 KiB) Viewed 14362 times

CDNG with Sharpness = 10 + CAC + SNR

CDNG uncompressed Sh10 - CAC - SNR Chroma 50.jpg (910.1 KiB) Viewed 14362 times

Next I experimented with the clip attributes set to super resolution:

BRAW Q0 with SR x2 / sharpen = medium / noise = low; with CAC and SNR

BRAW Q0 Super Resolution 2x Sharp Med Noise low - CAC - SNR.jpg (842.66 KiB) Viewed 14361 times

BRAW Q0 with SR x4 / sharpen = high / noise = low; with CAC and SNR
This clip is upscaled to 16k and then downscaled back to 4k - very GPU intense

BRAW Q0 Super Resolution 4x Sharp High Noise low - CAC - SNR.jpg (843.87 KiB) Viewed 14361 times

And then back to normal, without super resolution, but post sharpen:

BRAW Q0 with CAC and SNR; with post sharpen Strength = 2.5 / Fine Detail Size = 0.01 / Fine Detail = 2.0

BRAW Q0 as is + Sharpen SA2.5 FDS 0.01 FD2 - CAC - SNR.jpg (841.91 KiB) Viewed 14360 times

And now to the most interesting result. While I was center cropping the images in Photoshop, I got the idea to play around with its sharpen filters on the default BRAW Q0 + CAC + SNR still.
What you see here is the result of using
> Filter > Sharpen > Reduce Camera Shake

and then

> Edit > Fade

to 75% Luminance

BRAW Q0 with Photoshop's "Reduce Camera Shake" filter applied

BRAW Q0 as is - CAC - SNR + PS Camera Shake Reduction Filter.jpg (737.09 KiB) Viewed 14354 times

Because there was no camera shake, but a blur through the debayer process, the PS filter was able to get back all the detail in the image.

And finally all samples as PNG in 4K DCI to download:
https://we.tl/t-5LGkTLIso3

It also includes the Resolve .drx files and the Photoshop settings .dbw (workspace) and .knl (shake trail kernel) for the Camera Shake Reduction filter.

Very interesting, Robert. Nice work!
Steve

Good test Robert, and interesting results.

After pixel piping those images I would say that the SRx2 “BRAW Q0 with SR x2 / sharpen = medium / noise = low; with CAC and SNR” show the best result when it comes to ratio work process(efficiency)/final IQ. It also overall show a calm image that contains a lot of fine detail but doesn’t seem over sharpened that introduce haloes.

The last photoshop image introduces some strange artifacts (striping) and seem to even add false detail, which I’m guessing will be a problem when shown in motion. I’m guessing the mosquito noise problem in this case which we have seen from other sensors (pixels dancing around with no home address).

The post sharpen image seem to introduce tiny halo effects, but may be the best option regarding efficiency and render time. Probably the best solution overall IMO.

And now to the most interesting result. While I was center cropping the images in Photoshop, I got the idea to play around with its sharpen filters on the default BRAW Q0 + CAC + SNR still.
What you see here is the result of using
> Filter > Sharpen > Reduce Camera Shake

and then

> Edit > Fade

to 75% Luminance

BRAW Q0 as is - CAC - SNR + PS Camera Shake Reduction Filter.jpg

Because there was no camera shake, but a blur through the debayer process, the PS filter was able to get back all the detail in the image.

And finally all samples as PNG in 4K DCI to download:
https://we.tl/t-5LGkTLIso3

It also includes the Resolve .drx files and the Photoshop settings .dbw (workspace) and .knl (shake trail kernel) for the Camera Shake Reduction filter.

Shh..Shh Robert! Don't let them know, they didn't believe me missing detail could be restored, ant-shake routines should work similarly to my older proposals. Thanks for going the next level, you are probably starting to educate BM now.

Ok, I keep silent because I want patent, but we are progressing in a generally right direction. Most of what technical engineers would say is BS, and unfortunately we get people repeating the second hand though move to third hand reporting, and from there Chinese whispering game. I thought through this stuff a very long ago, I think through solving a lot of connected stuff. So, I get isolated famous people acting foolishly at me, and not realising what they are saying (famous/renowned does not mean smart or so renown worthy. Generally famous with fans who don't know better, rather then being ingenious productive thinkers, they are "doers" of lower grade work). The true resolution, even through most olpf, IS the sensor pixel pad size. A simple but ultimately truer statement. There are traces of the original sensor pad wide value in the recorded pixel. Here resolution is the width or minimal recording area, rather than line changes. So, techniques can be employed to detect that thought the anti aliasing haze (noise). But that is low quality resolution. Using calculations on the spread around each pixel you can further refine the pixel value of each, then the left over values are that of the other pixels, including the missing primaries, but the shifted placements of pixels detecting various colours around, lets you work out the missing primaries spread around. But this means, profiling the sensor, the spread of an olpf is normally weaker the further out the light is spread, meaning the remaining value is like an ND filter, giving you range shifted values of different colours for the same pixel which further give you range shifted values. How many stops, how far can you go, is up in the air, but if you can go the whole way at TV production quality. You then also have missing value outstside the pad's fill factor to work out missing detail there. But BM doesn't have olpf, so information is lost but stronger. The blur does not contain this and can't restore this. I've been passing out here, so have forgotten what I was going to say about this. I have techniques behind this I don't want to say, but one thing I wanted to mention, was pixel shifting, such that a different colour filter colour passes over it each frame, so In three frames red green and blue would be sampled. Debayering for each frame reveals the normal image, but correct value for the color exposed on the pixel in the frame. This should produce a little undulating effect, and visually averaging of colour, which might be sufficient in itself as an improvement, but working out which pixels have no movement/change you can use the colours, say RGB, to color correct each pixel with the primaries for it, and the same features which have moved to align the pixels to color correct them, and calculating the effect of change or movement, colour correct that per pixel. The human visual system takes time to evaluate new information, making accuracy in new information or changes/movement a lesser issue, once a detail feature settles and us sampled properly, the same can be reused. So, putting everything together, you have good improvements, but with a variable quality component. But, going another step, using half shift you can calculate a multi colour value for the pixel from averages on the pixel areas against surrounding values, and get 8k from 4k. See real simple.

Oyvind, the reason pixels maybe dancing around, there is a certain amount of noise naturaly produced by the the movement of photos of light band there extreme sparseness in space. There is surprisingly little amount of light in space, it is so overwhelming empty, that pixels have a hard time crossing each other's paths. I did the calculation for some sort of light collection project. So, now you have photons that can hit boundaries and interfere with other pixels. It means that the light coming from parts of the scene is even more sparse, and coming off sparse areas under the pixel, revealing variable detail under it both equals crawling noise. Next, you use large lens which concentrate and funnels light down to that pixel. Now photons are not so sparsely spaced, and have more opportunity' to push each other around and photons going to other pixels, mire crawl. So, the smaller the pixel or the larger the lens compared to the pixel, the worse the issue could be. Which ironically means that the small lens on phones probably helps them with these effects. This might mean that you need really big pixels to generally make the effect below 8 bits, much bigger than what you use professionally, or extremely small aperture which means very little depth of field. So, a large format sensor of 25cm plus with a low aperture lens, like used for arial photography to give sharp images of the ground below. The affect should become lower. Me, I would funnel the light towards the pixel pad centre away from surrounding pixels, and certain other things. Just realised a potential hiccup with my sensor design, well not everything is so great, hmm just thought of a way to calculate that error out.

Thanks Rob for going to the trouble of providing these images.

I haven't downloaded your files, but it sounds like you found adding sharpness back into a BRAW shot got you to the same subjective detail level as DNG ? Any thoughts about noise or "muddyness" ?

One other thought for Jack to try is to do the same shot of his FEET without the Speedbooster.

Jack can you try that ? Again to take another potential optical Faux pas out of the mix. Shooting with a prime would be better too.

JB

Since ProRes is in the title of the post, and some discussion about wanting DNG 3:1 I thought I could include my blind test link in this thread. It is not BRAW, but CDNG 3:1 vs ProRes ahem 422 LT on the URSA 4.6k mini with a real person then exported as DNX HD 444 12 Bit with the same minor adjusts to the log clips, saturation and contrast.

I was really testing how well I can pull focus off the monitor, with my new SLR Magic 50mm APO, and getting a sense of the color cast, I did put a Hoya IR filter over the lens which I think dulls the color in strange way. I put the two clips in the timeline one after the other then zoomed in on both. So it is wide, crop, wide, crop.

I didn’t exactly get accurate focus on the face and hand as I went back and forth but you are still seeing aliasing and moire in both to some degree in hair and the shirt which would make both a little too sharp. I would otherwise have added a pro mist.

https://we.tl/t-hmvggI6ifj?src=dnl

I haven't downloaded your files, but it sounds like you found adding sharpness back into a BRAW shot got you to the same subjective detail level as DNG ? Any thoughts about noise or "muddyness" ?

I think we can come pretty close to the subjective detail level of DNG. No muddiness for me to be seen here. It's also great that we can fight the less severe type of color moire in the camera (be it DNG or BRAW).

Good test Robert, and interesting results.

After pixel piping those images I would say that the SRx2 “BRAW Q0 with SR x2 / sharpen = medium / noise = low; with CAC and SNR” show the best result when it comes to ratio work process(efficiency)/final IQ. It also overall show a calm image that contains a lot of fine detail but doesn’t seem over sharpened that introduce haloes.

The last photoshop image introduces some strange artifacts (striping) and seem to even add false detail, which I’m guessing will be a problem when shown in motion. I’m guessing the mosquito noise problem in this case which we have seen from other sensors (pixels dancing around with no home address).

The post sharpen image seem to introduce tiny halo effects, but may be the best option regarding efficiency and render time. Probably the best solution overall IMO.

The PS filter shows artifacts of the de-blur algorithm - the mosquito noise itself has already been in the BRAW file, but very dimmed and now got amplified.

But there is an artifact suppression built into the PS filter. I have now created a new version in Photoshop.

• create a duplicate of the base layer
• apply the filter with 25% artifact suppression and 1% smoothing
• create a duplicate of the duplicate layer with the applied filter
• set first duplicate layer to layer mode "brighter color" and opacity to 50% and the second to "darker color" and opacity to 66%

New version of the PS filtered sample

BRAW Q0 as is - CAC - SNR + PS Camera Shake Reduction Filter v2.jpg (961.5 KiB) Viewed 14177 times

What I am going to say is obvious, but not too many apparently. The work you are doing here could form the basis for BM to design such into resolve to auto apply on debayer as a base look before grading, where they could also deal with virtually all the artifacts. Braw is not raw, so why not? There are certain basic looks for different styles of work which would be useful to select in camera, aswell as Resolve. It's amazing how companies overlook things. I have often written to google with a description of how to do or lay out something to solve some problem, or improve a product, which they have adopted shortly afterwards, in their own way. it's like the work structure in the internship (what was the name of that movie?). So, even the biggest companies don't think of everything.

Interesting but is it going to be possible to apply these sophisticated and resource intensive filters in a Resolve timeline let alone in-camera during the BRAW codec generation? NLE’s have pretty crude ‘sharpening’ filters compared to stills apps like PS but the processing overhead in a single still image is a non issue whereas on a frame by frame basis in a timeline it’s a critical issue.

Interesting but is it going to be possible to apply these sophisticated and resource intensive filters in a Resolve timeline let alone in-camera during the BRAW codec generation? NLE’s have pretty crude ‘sharpening’ filters compared to stills apps like PS but the processing overhead in a single still image is a non issue whereas on a frame by frame basis in a timeline it’s a critical issue.

Years ago I've used the camera shake remove filter to salvage an interview I shot in a hurry with a slightly out of focus subject. Took a long time to batch process the image sequence in PS, but the result was good enough to save the day. But nothing I'd like to do on a daily basis for lots of footage.

But here this is a different case. We are not trying to undo a lens blur or motion blur by using an estimated deconvolution matrix with a huge amount of operations
See page 8 of this presentation: https://graphics.stanford.edu/courses/c ... 3apr09.pdf

But: We should know the exact convolution matrix BMD has used in its BRAW encoding. I think from the BRAW patent paper it's only a 5x5 matrix. So theoretically BMD should be able to create a deconvolution filter matrix for Resolve to dial back the blur and that should be as fast as any blur or sharpen filter. Probably it also need some kind of artifact suppression to not introduce the problems back they tried to hide by the blur. Suppression of mosquito noise and some anti-aliasing. I think those are the harder part.

The PS filter shows artifacts of the de-blur algorithm - the mosquito noise itself has already been in the BRAW file, but very dimmed and now got amplified.

But there is an artifact suppression built into the PS filter. I have now created a new version in Photoshop.

• create a duplicate of the base layer
• apply the filter with 25% artifact suppression and 1% smoothing
• create a duplicate of the duplicate layer with the applied filter
• set first duplicate layer to layer mode "brighter color" and opacity to 50% and the second to "darker color" and opacity to 66%

Thanks for the update Robert. I Agree that there is mosquito noise present in the BRAW footage without any of these enhancements. It’s especially noticeable with Q5 in some static scenes where the codec drops down to higher compression rate.

I took the liberty to crop in on some of your results. The last PS version is better concerned to contrast and depth IMO. But it still suffer a streaking issue that resemble of an old 4:2:0 or 4:1:1 compression. My guess is that PS is just enhance something that is already there, but not in a big degree. The other pictures with super sampling and added sharpness in DR do not suffer from this issue. Its noticeable on many places in the image.

But to be clear.. this is NOT noticeable unless cropping in extensively. So it maybe not a big issue.

Here is the last PS version. The first suffer from the same issue:

BRAW Q0 PS version 2

Q0_PS.jpg (66.96 KiB) Viewed 14101 times

Here is the one that is only sharpened in DR:

BRAW Q0 sharpened in DR

Q0_sharp.jpg (55.82 KiB) Viewed 14101 times

Decoding raw and extract real picture is not ever a linear science, but sometimes developer should found different way.
I can tell you about Fuji x-trans cmos Raw files.
I bought last year and for the first few week I thought to have a problem with camera, all pictures also Perfect focusing are weak and had a micro blur. Later I discover that Adobe support of this raw is embarrassing, blurred and later sharpened in camera raw default.
I tested captureOne, better result, later I tested a “converter” iridiens x-trans that convert raf Fuji in a more comfortable dng, BUT with the correct interpretation of raw matrix. Picture of my nephew where hair are mushed now are perfectly clear and well sharp (but not oversharpened like Adobe algorithm).
I tell you that be cause I think not ever decoding raw should be the unique way, may be Blackmagic Design developers work better on ask and later we could recover better dectails. I remember that also red update and optimise decoder of red code during time and also first shootings Are optimised later from a better decoding libs.


Inviato dal mio iPhone utilizzando Tapatalk

Interesting but is it going to be possible to apply these sophisticated and resource intensive filters in a Resolve timeline let alone in-camera during the BRAW codec generation? NLE’s have pretty crude ‘sharpening’ filters compared to stills apps like PS but the processing overhead in a single still image is a non issue whereas on a frame by frame basis in a timeline it’s a critical issue.

Years ago I've used the camera shake remove filter to salvage an interview I shot in a hurry with a slightly out of focus subject. Took a long time to batch process the image sequence in PS, but the result was good enough to save the day. But nothing I'd like to do on a daily basis for lots of footage.

But here this is a different case. We are not trying to undo a lens blur or motion blur by using an estimated deconvolution matrix with a huge amount of operations
See page 8 of this presentation: https://graphics.stanford.edu/courses/c ... 3apr09.pdf

But: We should know the exact convolution matrix BMD has used in its BRAW encoding. I think from the BRAW patent paper it's only a 5x5 matrix. So theoretically BMD should be able to create a deconvolution filter matrix for Resolve to dial back the blur and that should be as fast as any blur or sharpen filter. Probably it also need some kind of artifact suppression to not introduce the problems back they tried to hide by the blur. Suppression of mosquito noise and some anti-aliasing. I think those are the harder part.

Yep, it should be able to be done fast in modern machines. Carlo's post is good too. More than one way to cook an egg.

Sometimes people told me that I’m obsessed but...
I should remember to all that old cineform raw (2005 years) had different debayering algorithm that give us speed and or quality, if that allow me to manage two different stream raw 2k from usb2.0 hard disk, and very old dual core cpu, why not today on 4-8k with modern hardware had better debayering? Cineform was the father of all all DI codec, before the prores and hnxhd, and first to encode photo raw to video, redcode, and more on custom raw.
David develop a real-time decoding software that allow to send right kind of info to all software.
Why not hyre him to add another arrow to Blackmagic Design team? In go pro is near to dead end, they stop to develop cf in 2011 and kill the commercial version, active metadata and more.
I’m obsessed? Yes, but only be cause ten years ago I had a better way to manage raw than today ...


Inviato dal mio iPhone utilizzando Tapatalk

Probably a deal with Red. David did the bayer video compression and storage before them. You can reassign a patent, but by the wording of Red's it doesn't look like it, it seems to go over the top of what David did. The whole Bayer video recording in itself, should not be patentable. David made it public the next day, describing it, literally, look what I did.

They crafted a codec fast to compress on a cpu, and made software that processed fast on the CPU (the two are different if you don't craft the data/format efficiently, it doesn't matter if you design the processing software efficiently, it will be slower, you are chasing your tail. In my design, I design the CPU and instruction set and data handling efficiently, and work your way up to format and processing software. The present CPU designs for desktop are at least 10-100 times as inefficient, then you add bad programming and you could be going another 1000x slower (more like 10-100x again in our part of the industry). This isn't as good as it sounds, because a lot of it is massive parallelisation at the same energy envelope or transistor density, but often there are lots of limits of just how many parallel units you can use efficiently. So, you are running a heap of cores at native silicon speeds of say 1 Ghz+ (I haven't looked at what the newer node processes run at, but basically everything not true low power is overdriven) instead of say 5Ghz, so immediately you may require more than 5 low powered cores to keep up, and as they are light weight. It maybe significantly more to compensate. But, the routines have to be able to spread across that many cores, but video processing is very parallelisable. I would just design it to accelerate the few cores used. So, 5ghz again, but using 100+ times plus less energy. I did day lightweight. At these levels, it gets very complex, as you can have millions of lightweight cores for one Intel chip, or NVIDIA for streaming, less so with memory. So for the same transistor count you are up in energy consumption due to more active transistors, and likely concentrated spots. Exciting stuff. Fine balancing acts.

So, I had suggested to David to use GPU processing but he didn't like the idea. At the time the GPU instruction sets and memory handling were very primitive. Though I thought they could help in a collaborative manner with the CPU in sort of batch processing, swapping data in and out on a clunky pipe line. But, now, they could run cineform on the GPU (they run Red's on gpu's). I suspect it wouldn't be any slower than Braw, but maybe a lot more parallelisation than Braw currently uses (if Braw happens to be depending on dedicated jpeg hardware in the GPU. Which means it would run hotter, even a lot hotter). Cineform RAW Bayer licenses cost $10 or $20 per unit I think. I think it's meant to cover you, but don't know. If BM would allow us a FPGA sandbox like I've been asking for, or at least the option to have cineform raw in the driver and activate it by paying the licence to cineform.... Or. Cdng (in the MXF container format for processing, and pay the fee (to Red) some people will be happy. They could even keep the firmware with it seperate and keyed, to get when you pay. I miss cineform, and David.

Cineform wasn't the first such format, but others had problems retaining image accuracy through reuse in post. They did a very good job, the way it's meant to be.

Cineform RAW Bayer licenses cost $10 or $20 per unit I think. I think it's meant to cover you, but don't know.

i payed 999$ for original license, it's not a problem 10-20$ to come back to that times

Camera license or desktop Carlo?

Stuff, there is a lot more processing in Bayer to get over these sort of things compared to three chip.

I have a proposal to do 3-5 chip + I'm sitting on for years in a cheap fashion. There is an issue though. Home made prisms are another issue.

We concentrate on Bayer too much, it's a poor method out shone by 4:4:4 foveon, which give a visually comparable image at a lot less resolution, hence why the techniques talked about here enhance Bayer so much. If only BM had 4:4:4 sensor like that, but modern and capable like the Sonys.

Camera license or desktop Carlo?

Cineform studio pro license, with 3d metadata etc, in 2010 i worked on 3d stereoscopic shooting for a facility and this codec give me ability to edit stereo alignment, adjustment, color correction and more, realtime where other solutions lack of most of that feature, also not realtime...

https://web.archive.org/web/20120309040 ... ofessional

at today, dead

Camera license or desktop Carlo?

Cineform studio pro license, with 3d metadata etc, in 2010 i worked on 3d stereoscopic shooting for a facility and this codec give me ability to edit stereo alignment, adjustment, color correction and more, realtime where other solutions lack of most of that feature, also not realtime...

https://web.archive.org/web/20120309040 ... ofessional

at today, dead

I think it's long been discussed but cineform has a different pay scale to a manufacturer hoping to use their product in a camera than what individual end users pay.

Cineform is dead. Long dead. Tied up in wanting to make money. At the time remember too that GoPro had bought them and it was anticipated that GoPro might be thinking of going into a more high end camera. Why else would they buy cineform ?

And why would a company new to cameras want to pay another competing camera company money for their codec ?

And let's look at what would have happened. Would Blackmagic be in a better position today if they'd had cineform in their codec suite ? I don't think so. But they would have been paying a substantial amount of cash out to others for IP.

Cineform exists really now as REDCODE. (Redcode is arguably based on cineform)

But It's all RED. They aren't sharing and they aggressively chase down any that go near their IP.

That's why you have BRAW.

That's why you have ProRes RAW. (but not in a camera yet, and if they ever do then it means Apple are paying RED)

JB

EDIT from Dave Newman at Cineform. People always quote the costs without understanding that making HARDWARE encoders (aka a camera) means something different do doing it on your computer.

You still have to PAY per unit.

"from For 4:2:2 and 4:4:4 in camera encoding we are completely patent free, so hardware vendors are welcome to build CineForm compliant encoding and decoding of all formats except for RAW. The direct using of the CineForm-SDK software, the Apache 2.0 license grants patent rights including RAW for those software products. However for hardware implementations CineForm RAW the licensing would be for SMPTE VC5 which grants RAW patent for custom implementations...."

That also means you're basically doing REDCODE but you won't be allowed to use any more efficient compression ratios. So even if you pay cineform and have it in camera, I'm 99% sure you wouldn't be able to do better than 5:1 compression in camera.

What's the point of getting cineform when you can't get more than 5:1 compression ? That makes future higher resolution sensors very hard to deal with.

So.

1. Pay more to get cineform in-camera.
2. Can't go below 5:1 compression.

Why's this a good thing again ?

The $10 or $20 licensed is probably the Red patent license. Has anybody bought one of those from cineform to check out the paper work? Unless this is some special developers licensing, I don't think the commercial stuff will be more expensive in bulk, and Red is certainly licensing.

Braw could certainly use cineform wavelet normal free of charge as far as I know, and get maybe double the quality at 12:1-5:1.

We assumed GOPRO was going pro, and Cineform had planned to do hardware. Maybe there was talk. But, it went nowhere, maybe before the time the second much faster version of the red codec came out.

Anyway, there are competition and second party source provisions in patent law (I forget how many countries). So, it isn't as easy as tieing everything up in patents, it seems, if you are licensing. Which countries can it be challenged. Going around the different countries and turning over the patents there, or forcing some pro competition licensing, would make big headaches, enough to bring people to the table, particular if it affects availability of their own products. Somebody could buy patents the other side violates, and use it to stop the manufacture and sales of products. This is similar to how some companies fight patent claims, looking for violation of their own patents. This may have been part of the resolution of the Red vs Sony case. Apple wouldn't really have much of those sort of patents to use. They could come out and find Red pulling out compression and other side patents while trying to negotiate and decide it's not worth upsetting Red or done other tactic. A real shame.

Carlo, I meant the Bayer licenses of the cineform codec.

i quote cineform not to have it on camera body, but to remember that could be possible to do with braw codec, i would like to see upgrade/future support of post/decoding raw data

if this was possible over ten years ago with old hardware we can hope it from braw and new hardware.

- ability to encode braw from different raw format (if i had sdk to read raw x, i can manage and encode to more performance storage codec like braw)
- ability to recompress braw from q0 (shooting safe) to q5/8:1 in a safe computer enviroment but keeping original raw (avoid other DI choise and at same time choise is safe be cause i shoot at best and archive at better combination storage/quality that i need)
- ability to decode (also not in realtime) braw with better interpolation of bayer data to have sharper, fine small dectails (not only matrix 2x 4x 8x of matrix scaling but quality interpolation of bayer data).

i not ask this for free, like i told previous, i payed years ago 1000$ to have a workflow that allow me to work fine with raw in 2010, i'm ready to pay to have features plus from braw. An utility, a converter, a plugin for resolve, choose you the name to do that.

think to working environment where i shoot q0, i prepare a daily with embedded lut, export braw 12:1, sent to editor, work fine, can manage or update metadata of sidecar then later arrive complete Q0 shooting to export or do post. Keep raw ability, smaller space.
Actually is doable with prores Alexa, with lut embedded but not burned, you can recompress on smaller prores proxy even with lut embedded not burned and workflow is light but complete.

What stops you from having the same LUT in your camera and in Resolve and to burn it in by exporting?
Such files are really small.
BTW, Kyno would be using a .cube file with the same name as the clip automatically for display and transcoding. It's a pity they don't recognize the BRAW sidecars, but their integration for BM hard- and software is still young.

What stops you from having the same LUT in your camera and in Resolve and to burn it in by exporting?
Such files are really small.
BTW, Kyno would be using a .cube file with the same name as the clip automatically for display and transcoding. It's a pity they don't recognize the BRAW sidecars, but their integration for BM hard- and software is still young.

I think to external people that could see daily without use resolve.
Today you can just embedded lut in braw and in prores without burn it (another feature from cineform of 2005, that I loved, not destructive active metadata that QuickTime container can have and use that few software hardware use along time).
I think to people that is editor only and are so mentally closed to not want to know anything about lut color etc, but ask raw to edit, I know too much people like this.


Inviato dal mio iPhone utilizzando Tapatalk

You could record Q0 and have it transcoded to Q0, or any other, variable compression, using more advanced routines on the desktop (this Is a reality in compression that in camera is usually not more compressed than desktop). The 5:1 variable desktop might retain as much visual quality and 3:1, or 12:1 be like 5:1. Good for archiving. But seriously, if cineform core routine could be available to use in Braw, that would be good, and for 24;1 to be similar to 12:1, which I know people would like.

I think to external people that could see daily without use resolve.

That would be a use case for Kyno then. It even runs on lesser machines and older OS.

(No, I'm not affiliated with them other than doing a review for "Digital Production".)

Please Blackmagic,
can we finally get an update?

Either improve BRAW quality, which means to give us an option to bypass all unecessary sharpening and noise reduction at least or add ProRes RAW support in Davinci Resolve, which doesn't have any obvious processing issues.

Getting annoyed each time I have to deal with ProRes Raw, dealing with it since there's no direct DR support and seeing how much better the IQ actually is when working with it.

With BRAW I have to add lots of processing such as Gaussian Blur with an Edge Detection Alpha input, to mask out the strong halos around edges and add sharpening with the smallest radius possible, to make the image look more textured and no, it still won't look as good as it could be.

No such issues with actual RAW.


Everyone who's still in denial, please watch the following video:

I actually have a similar complaint. I shot on the Pocket 6k in ProRes and BRAW and the image quality was quite similar in detail and texture.

I repeated the process with a Lumix S5 and a Video Assist Recorder: Recorded a clip in Braw then Prores. There was a huge lack of detail in BRAW compared to Prores. Enough for me to question my use of the codec.

I actually have a similar complaint. I shot on the Pocket 6k in ProRes and BRAW and the image quality was quite similar in detail and texture.

I repeated the process with a Lumix S5 and a Video Assist Recorder: Recorded a clip in Braw then Prores. There was a huge lack of detail in BRAW compared to Prores. Enough for me to question my use of the codec.

The ProRes on the P6K receives the same processing treatment BRAW does, so there shouldn't be any noticeable difference.

Using other manufacturer's cameras you'll notice a different looking image, which with actual RAW would always be a good thing.

With BRAW on my S1H I actually have exactly the same issue. Even internal 4K All-I 422 footage has more texture than external 6K BRAW, while not showing any nasty sharpening halos either.

Except for the great screen and peaking and also 12bit I really regret going the BMD VA route.

Was tempted with the VA for my S5 as ProRes RAW just created way too much data and in the end just though it's easier to shoot on my P6k if I wanted 6k BRAW.

And for reference, I did a comparison between the Lumix S5 in 5.9K BRAW, vs 4k Prores, vs Pocket 6k in Braw, vs P4K in CDNG.

The P4K in CDNG demolishes the P6K in 6K Braw when it comes to detail. It has a bit of aliasing and moire...but the Panasonic s5 in braw and prores comes close.

The P6K in 6k Raw looks by far the worst. I don't know what BM did here. I did a blind test and showed everyone at the office and the P6K came in last every time.

… The P4K in CDNG demolishes the P6K in 6K Braw when it comes to detail. It has a bit of aliasing and moire...

Thank you for those comparisons. Very interesting results. I don’t have a CDNG capability on my BMPCC4K but I shoot CDNG Lossless on the original URSA Mini 4.6K which has usually given me very good results.

… The P4K in CDNG demolishes the P6K in 6K Braw when it comes to detail. It has a bit of aliasing and moire...

Thank you for those comparisons. Very interesting results.

Where are the "demolishing" comparisons? Are we talking about "cinematically significant" differences or differences of interest only to camera owners?