Blackmagic Forum

Wayne Steven wrote:That's not the issue, but about certain people's constant bad attitude on others, may I add you to the list for trying to subvert away from what really is going on?? I'm trying to bring things back to the topic by reminding these people of their rubbish and to stop it. They come along and do this stuff too much, we would have had a nice conversation by now and possibly finished, but certain people get their negative ego boost by busting into such conversations and poisoning them, thinking they are little black nights on horses. I got news, the black might isn't the hero.

Okay, I’ll try this one more time. English isn’t my first language but I think I have a decent command of the language. Still, most of the time I have no idea what you’re saying— that would be okay, except I’m forced to swipe incessantly past your incoherent, hyperbolic, posts about your many inventions and would-be patents so I can read actual contributions from other members.

You’re deflecting, again. We’re all happy to have a conversation but this is a technical forum and if you’re not prepared to back it up with anything other than vapid statements— with actual first-hand examples— please consider enjoying the discussion as a spectator.

So, back on topic. Are you prepared to share any examples here, from personal experience, that can further this discussion and move us forward? Otherwise, kindly put me in whatever list you wish. This forum is an invaluable resource and a privilege, but your smoke-filled contributions are fogging up my view and I’m happy to exercise the use of the ignore function, as apparently others have done.

Kindly,

Fabian

The second node in your node-setup is a LUT.
Does the problem persist if the second node is disabled? Other than that the screencrabs you shared are jpg's which are of little to no use for us to look at. In the lower left corner of the RAW tab you find a command ‘Export Frame’ that’s the one to use if you need help.

Yes one thing to remember with nodes in davinci resolve is that changes is done in series where the nodes before effects the nodes after. So if you crush the blacks in the first node, and try bringing back shadow details in the last...well that’s not a good idea. Same if you add grain in the first and sharpen in the last. You also sharpen the grain.

John Brawley wrote:

Dmitry Shijan wrote: there is also Chroma Noise Reduction that produces halo (color glow) effect around edges of solid colored objects.

Is it that or is this the result of RGB-->YUV transforms ?

JB

John, RGB444 to YUV444 transforms can be be done reversible (or bijective):
https://stackoverflow.com/questions/105 ... sformation
It just requires more bits for precision, which should not be a problem with Resolve, which does use floating point precision anyway.


In the comparison I made between BRAW and DNG I also made short clips with those miniatures and exported those to Cineform YUV422. While the clip originating from DNG showed no halos, the clip from BRAW showed halos - like it was the case in the source footage.
viewtopic.php?f=2&t=91802

The halos look exactly like - as Dimitry wrote - when you are gauss blurring the color channels for noise reduction. I think this is the main point for BMD to tackle for improvement. A better denoising algorithm would improve image detail compared to the current algorithm.

Robert, when you say colour channels, do you mean I respect of Bayer which includes luminance detail, or is respect of colour channels separated from luminance?

Fabián Aguirre wrote:...I’m happy to exercise the use of the ignore function, as apparently others have done.

Kindly,

Fabian

Fabian, that’s about all that can be done. DNFTT.

The “signal-to-noise” ratio of the forum does take a hit.

Your English is excellent, btw.

Steve

Yes, and you are apparently both part of the noise being complained about (by myself). We were just off you guys, give it a break? Back to regular programming that those people didn't like.

Tell us more on topic stuff Robert, or others?

Actually how do I block somebody? I'm so respectful of disrespectful people's continued existence, I actually don't use block and can't seem to find it? But as Fabian is lieing and exaggerating add nauseum, and can't apparently read very clear intelligent language (according to himself, some pro) the quality of his work is not worth reading anymore. Being so debased as to agree with his irrelevant comments is also not worth air. I know pomposity when it disagrees with me (usually) .


Anyway as you were saying Robert?

levisdavis wrote:Yes, there was no getting through to anyone on the US number. Was told specifically that a supervisor would call back. That never happened: even when this division was confronted with the notion that their product needs help and is being mis-sold to the general public. "Can't even open the front door to show them the outside world."

The macro-blocking can be seen in footage with clouds. Areas where the texture falls off. Areas where true sensor-noise resides. The macro-blocking / spatial noise becomes as prominent as cloud texture. It could also possibly be related to black-shading? Easiest to reveal when playing back faster than real-time; if you're specifically looking to see how the codec breaks apart.

Respectfully, the GH5 10-bit 4:2:2 150mb/s demonstrates none of these same issues; even when un-questionably graded harder / further than M-B RAW.

Here are a small set of "Grab Stills" directly from Resolve. The bottom right area of the screen is what we're looking at: a macro-blocking texture / black-shading texture.

https://we.tl/t-DvEpm9o2KA

Grab from resolve must be a braw frame, a screen grab not give me infos... also compressed in jpeg that create macro blocking is not a good proof of that problem.
i had also gh5 from july 2017, i had a many of shooting with macroblocking when you up the frame rate, or you have less light, to not talk about 180fps 4:2:0 8bit... where you cannot touch continuos color with red, brown or you see blocking everywhere... but if i keep gh5 today, also if i had bmd cameras is be cause i think it had strong point over weak point.
Anyway at opposite i not found this kind of problems in most of shooting did in the last year first on ump later on pocket4k , but i ever expose correctly, Q0 Q5 quality, i rarely push the color behind his limits.
i'm very interest to see shooting (braw frame or sequence) with this problems to understand in what condition (iso/shutter/compression/etc) happened to avoid to fall in it.

Wayne Steven wrote:Robert, when you say colour channels, do you mean I respect of Bayer which includes luminance detail, or is respect of colour channels separated from luminance?

The latter. It looks like a blur on the color channels separated from the luminance channel.
But when I find some time I will investigate this issue a bit more in depth.

Thanks Robert.

The point of the JPEG file upload is to illustrate 8-bit macro blocking. The same macro blocking is present in the 12-bit.

But, who thinks ahead / forward when we can all complain and do nothing? Anyone? Anyone follow the directions that were posted. I didn't ask that we do. But, it isn't very productive when we can't see eye-to-eye now is it?

Oh, and you're welcome to re-read the post as being an expression for care and concern for others. In the end, we are all sort of in this together; perhaps some day creativity?

If you want a meaningful discussion upload unprocessed BRAW footage here and provide the steps to replicate so others can evaluate what you said you are seeing.

levisdavis wrote:The point of the JPEG file upload is to illustrate 8-bit macro blocking. The same macro blocking is present in the 12-bit.

But, who thinks ahead / forward when we can all complain and do nothing? Anyone? Anyone follow the directions that were posted. I didn't ask that we do. But, it isn't very productive when we can't see eye-to-eye now is it?

Oh, and you're welcome to re-read the post as being an expression for care and concern for others. In the end, we are all sort of in this together; perhaps some day creativity?

JPEG has its on compression and we are not seeing full resolution, so adding those two together equals something that’s not accurate, just upload the BRaw file

Robert Niessner wrote:If you want a meaningful discussion upload unprocessed BRAW footage here and provide the steps to replicate so others can evaluate what you said you are seeing.

I quote Robert, i askwed for a braw sequence or frame to read metadata, to analize the situation to reproduce the situation and avoid it when or whell would happen to me.
i know there isn't the perfection in the world, no camera or codec is perfect, but part of my work is "problem solver", and i often intercept problems finding on forum the problems and analize them to avoid it on set, or on shooting day around the world.
If you cannot upload a single braw frame i cannot find what iso/shutter/iris condition cause to you the problem.
do you think i'm in excess?
ok i tell you a story : in past gh2 h264 at iso 800 had a special flag that in all computer win and mac with installed adobe suite you see a strong rain effects along the shooting, if you decode with stand alone decoder that not read h264 system decoder (a decoder installed from adobe with deblocking setup On) you saw a clean shooting. Under windows you should disable by regedit a special flag and all software could see correctly the shooting. The problem born only at 800 iso, where probably with this gain appear a stange pattern bad readed from deblocking algorithm of Adobe.

The meaning of this story?
All people complain to a bad shooting, the truth was that is the decoder the problem in the unique situation.
In the last 30 years of my experience in video from analogic to digital is that the problem must be reproducible in different environment to isolate the causes and develop a workaround.
I found problems also in Redcode, CIneform, Prores, H26x , mpgX, Dv-X, and so on, but i not talking about worst are them, i develop the correct workflow to avoid it... please share with us the frame of braw to try to reproduce it.

I posted a link to a thread page with a frame. Don't you guys think it would be quicker and easier to turn on and a record a second of footage changing iso and look at it rather than argue. I don't see much sharing and caring here. And sure, Levi could, but it's been seen before and looked at here, why should he? There are people, who virtually don't matter what you do will load you up, and it is not good enough. It's worth starving them of the gratification of playing with you. I think his simple statement stands as a statement. But Levi, I think at the same time, it would be good of you to show it to them. Sure, it might prove to be a distraction from working life, but they are already wasting your and their own time.

Wayne Steven wrote:I posted a link to a thread page with a frame. Don't you guys think it would be quicker and easier to turn on and a record a second of footage changing iso and look at it rather than argue. I don't see Mich sharing and caring here. And sure, Levi could, but its been seen before and looked at here, why should he. There are people, who virtually don't matter what you do will load you up, and IRS bit good enough. I think his simple statement stands as a statement. But Levi, I think at the same time, it would be good of you to show it to them. Sure, it might prove to be a distraction from working life, but they are already wasting your and their working lives.

Aha. So it makes more sense to you that he wastes time writing long postings lamenting about an issue than to just upload a source footage for all to examin. Yeah, who's wasting working lives here?
Why should we try to replicate with our cameras in a different scenario when we know exactly nothing about his shooting scenario. He made the claim, he carries the burden of providing the sample for replication. I am tired of this avoidance tactic.

No, it makes more sense to ignore people who can't look at a frame of footage on their own computers to see what's there. But have to insist on rehashing what has been examined before. Yeah, it will be this little thing, then that, that, that, don't matter it's big. Bit rude and a real hassle. Why help those argumentative people reinforce this attitude. Sure certain people you help without much; issue, and more so the first time. But when they exoect you to spend half an hour to hours of your time locating old threads, we have been in, and they are not unwell, why don't they do it themselves. I know I'm coming down hard, but I've had them asking me to put in serious time for them to amuse themselves in order to get a chance to likely criticise what you find anyway. I'm sick of the mental mentality. It's just negative dismissive people acting like they actually know over the top against people who have seen the evidence. I might ask you to scientifically prove that gravity exists and how it works, but we already know it exists, so we don't have to discuss that when somebody mentions gravity, do we. However, I can't find the name above here, is offering a valuable service here, to find out of it is a codec display problem. So, its worth have a look at Levi.

Wayne Steven wrote:No, it makes more sense to ignore people who can't look at a frame of footage on their own computers to see what's there. But have to insist on rehashing what has been examined before. Yeah, it will be this little thing, then that, that, that, don't matter it's big. Bit rude and a real hassle. Why help those argumentative people reinforce this attitude. Sure certain people you help without much; issue, and more so the first time. But when they exoect you to spend half an hour to hours of your time locating old threads, we have been in, and they are not unwell, why don't they do it themselves. I know I'm coming down hard, but I've had them asking me to put in serious time for them to amuse themselves in order to get a chance to likely criticise what you find anyway. I'm sick of the mental mentality. It's just negative dismissive people acting like they actually know over the top against people who have seen the evidence. I might ask you to scientifically prove that gravity exists and how it works, but we already know it exists, so we don't have to discuss that when somebody mentions gravity, do we. However, I can't find the name above here, is offering a valuable service here, to find out of it is a codec display problem. So, its worth have a look at Levi.

I have already spent 2 full days making an assessment of BRAW vs CDNG with a lot of samples to download for everyone and wrote done my conclusions in great lengths here:
viewtopic.php?f=2&t=91802

If Levi isn't able to do that himself, I won't take his "findings" seriously as long as he doesn't provide his source footage. If you are not able to understand why this is necessary, then to me it seems you have zero knowledge of how a minimum scientific approach to an issue has to be undertaken.

And a "pro" tip for you: there is a feature in your browser called bookmarks for those links you can't find so you don't have to search again for them all the time for hours. BTW, this forum itself does have this feature too.

I just saw that while looking for the link I had before. So was aiming to "pick" through that ("zero" knowledge indeed). But I appreciate your effort Robert.

Now, it has been seen/tested discussed before. So, I don't really need to see it again (as with science, you move on to test something new). And if you read down the end of my post, you see me asking Levi to post some samples again. SL you ate licking on the wrong fellow. But, what does science really have to do with not accepting previous known results. If you want to retest them, go ahead. That's how science does work.

Now, in your spirit of unfairness, I could have 10k-20k of bookmarks again. Doing directory structures and handmade tagging and sorting and preference coding (yes I to DL that) is somewhat difficult. So, even if I do have a link, of no real significance, as you come see and go, not expecting to come back, it might be lost in the ether, but maybe somebody else has it, the one with my red rug. Anyway, I am searching through my browser history for the page, but unfortunately my request to them to preserve a record of every time a page was visited, seems to have gotten implemented. So, I have heaps of duplicates of the same forum pages to wade through. They could have made alternative sorting views to avoid the separate views and list the full name (previous suggestion) but I can't do all the thinking for them. I'm not getting important stuff finished, but now wasting hours looking for links. Grrr. With everything happening, I can't afford the waste of time.

I think you might have wanted stills from my little camera. I have managed to fetch it. After 15+ years of life, the internal battery is cooked. I managed to read one card, but that is for a PDA, and the other card went missing yesterday. Still looking. The photos from back then were harsh sunlit photos which show what it could do. I might have to take some lighter photos instead (if it works, the contacts have corroded).

I don't want to interrupt another emotional and very informative discussion and i really don't remember where is located that discussion and original BRAW samples with macroblocking but as i remember that BRAW sample with sky was overexposed a lot. So blue channel sky gradient was near 100% clipped (say hello to ETTR noise in shadows paranoia) and probably this caused macroblocking because not enough bits for BRAW noise reduction in some areas. Other users on that thread share near similar samples but not so overexposed, and they can not replicate that macroblocking problem.

Dmitry Shijan wrote:I don't want to interrupt another emotional and very informative discussion and i really don't remember where is located that discussion and original BRAW samples with macroblocking but as i remember that BRAW sample with sky was overexposed a lot. So blue channel sky gradient was near 100% clipped (say hello to ETTR noise in shadows paranoia) and probably this caused macroblocking because not enough bits for BRAW noise reduction in some areas. Other users on that thread share near similar samples but not so overexposed, and they can not replicate that macroblocking problem.

It was this discussion:
viewtopic.php?f=2&t=93737

and there I supplied my own additional test shots which showed no signs of macroblocking.

The wedding preparation was an original one, plus I posted a link to some test charts which had an additional close up image full of macroblocking. I'm curious I'
If it isn't macroblocking, but just bad player software (no I don't consider fiddling with options/systems a Quality solution). I remember an advanced ambarella based pocket can. I was filming swallows darting about at a finish line, and also tracking them. I looked at the footage on the viewfinder, and it was just flashing black squares. I thought I had pushed it too hard, but when I got it back to the computer the birds were rendered as perfect little black shapes, like my modeling image break down proposal had proposed (because the swallows are moving too fast to be recognised in detail, all the detail and shading was sacrificed leaving only a dark outlined shape). I was delighted. But the camera screen playback left a lot to be desired. Note, not operator fault, system fault.

In that thread above there is mention of finding jpeg in braw headers. At 3:1, in this day and age of better jpeg compression, it is like what is it doing there at the actual 4.5:1 the encoded video should represent. But at Q0, it is a better compression ratio, so makes you wonder.

Ambarella produce SOCs that perform h264/h265 compression - so macro blocking is an absolute possibility.

Wayne Steven wrote:
In that thread above there is mention of finding jpeg in braw headers. At 3:1, in this day and age of better jpeg compression, it is like what is it doing there at the actual 4.5:1 the encoded video should represent. But at Q0, it is a better compression ratio, so makes you wonder.

I assume you meant to say DCT rather than jpeg?

As soon as I realised BRAW was not 'RAW' I exposed it with more caution when using ETTR.

John Griffin wrote:As soon as I realised BRAW was not 'RAW' I exposed it with more caution when using ETTR.

Or shoot Q0 (or 3:1)

Andy Coulthurst wrote:

Wayne Steven wrote:
In that thread above there is mention of finding jpeg in braw headers. At 3:1, in this day and age of better jpeg compression, it is like what is it doing there at the actual 4.5:1 the encoded video should represent. But at Q0, it is a better compression ratio, so makes you wonder.

I assume you meant to say DCT rather than jpeg?

No, I meant they found it using jpeg references in it's internal files. Cdng and a number of others just use jpeg repurposed to the data. People are saying it is component video, which inflates file sizes maybe not as much as I think, as the original raw has less data.

Andy Coulthurst wrote:Ambarella produce SOCs that perform h264/h265 compression - so macro blocking is an absolute possibility.

Yes, except they fuzz it out now. But I meant the playback on camera showed extra bad blockiness which were not there when played back normally. The problem now, is your computer systems have deblocking technology. So, not seeing blocks on s computer doesn't necessarily mean there was none there in the recording.

Is there a way to guarantee to turn off all display enhancements to the industry not from genuine modification of the software?

MishaEngel wrote:

John Griffin wrote:As soon as I realised BRAW was not 'RAW' I exposed it with more caution when using ETTR.

Or shoot Q0 (or 3:1)

I was. Read the thread as even CDNG had issues.

OK Robert. I found a easy way to find the threads, but after maybe 12 hours of effort, I can't find the threads on JPEG, macro blocking, the original banknote and the scene with the fine net and other textures which blur out etc. It's like they suddenly don't exist. A bit strange. Maybe they were linked images which don't come up or have been removed at source. However, I determined the wedding like one with macro blocking, is probably the braw demo with the Asian women.

Anyway where's my $12,000 for looking up this stuff rather than the people who really want to know pulling up some complex footage etc, and looking for it?

Ulysses Paiva wrote:So far BRAW has been stellar to me. Maybe you guys can be more detailed giving samples and more info on your issues.
Up until now we are only getting claims supported by nothing.

+1

I am sure nobody will tell the difference when watching something shot on either BRAW, ProRes, cDNG and so on. Unless you stay 30min at 600% zoom on a still frame while knowing what the footage is shot on.

Did the test at normal fov, and did. The issue is sometimes it's going let you down. Uncompressed, me what Braw gets, you could do more with.

I'm wondering if one of the differences in Braw, apart from looking less focused (cdng applies some sharpening as standard though) is that braw gives a different contrast by more latitude use.

Would the following be considered correct or incorrect, Thankyou

BRAW isn't actually RAW at all, users have found it compresses into YUV and creates artifacts when doing things like green screen as a result

It might be a bit more nuanced than that, so I'll let it to the guys who examined that to answer. We hope it at least preserves the bayer pixel values in the encoding, but we can't manually extract that.

if micro-block is an issue it's will be mention hear. Since It did not I believe it's no big deal.

https://www.cinema5d.com/z-cam-zraw-vs- ... -lab-test/

this is BMPCC6K test impresive -4 recover.

https://www.cinema5d.com/blackmagic-poc ... tter-more/

visalapol wrote:if micro-block is an issue it's will be mention hear. Since It did not I believe it's no big deal.

https://www.cinema5d.com/z-cam-zraw-vs- ... -lab-test/

this is BMPCC6K test impresive -4 recover.

https://www.cinema5d.com/blackmagic-poc ... tter-more/

That test is not very comprehensive as it doesn't include over exposure or tests of single primary colours ( i.e blue) where I saw the issue with my camera in the previous thread.

CougerJoe wrote:Would the following be considered correct or incorrect, Thankyou

BRAW isn't actually RAW at all, users have found it compresses into YUV and creates artifacts when doing things like green screen as a result

We are still waiting for BM to respond.....
From what I have seen I would say it's a 12bit YUV 4.4.4 (or 4.2.2?) lossy compression codec with maybe some partial debayering (whatever that means in practice) and some inbuilt NR. I.e its a very good and flexible codec but nowhere near what most people would call 'RAW' esp if they are from a stills background where this means full bit depth RGB data straight from the A/D converter with no in-camera processing apart from maybe some lossy or lossless compression.

Agreed. RAW is used as a marketing term, that is working great for now. Even the term "lossless compression" has been taken hostage, as some talk about "visually lossless" without ever giving any real definition of what it means (hint : it means "don't push exposure too much").

Anyway, there was no better alternative to call the codec and people love it

Robert Niessner wrote:
John, RGB444 to YUV444 transforms can be be done reversible (or bijective):
https://stackoverflow.com/questions/105 ... sformation
It just requires more bits for precision, which should not be a problem with Resolve, which does use floating point precision anyway.

Well that's the point of the YCoCg color space compared to YUV, along with easier operations. So RGB444_8bpc and YCoCg444_8bpc are bijective, but not YUV444_8bpc or RGB444_10bpc <-> YUV444_10bpc

antoine wrote:Agreed. RAW is used as a marketing term, that is working great for now. Even the term "lossless compression" has been taken hostage, as some talk about "visually lossless" without ever giving any real definition of what it means (hint : it means "don't push exposure too much").

Anyway, there was no better alternative to call the codec and people love it

A better name would have been BRES and people would still love it but without the confusion and expectation that the term RAW has.

BRAW patent is here, it may help.
https://patentimages.storage.googleapis ... 7775A1.pdf

Oh no, it can't be the braw patent, it says encoded format is YCbCr420

If anyone wants to see that braw is using DCT with macroblocks, load up luma-chroma shader in my braw player and crank viewer exposure and gamma for chroma channels. Macroblocks aren't usually visible in RGB image, but they are there. They don't have any significant practical impact though, which most of this argument seems to circle around.

You have to actually read the patent - not just post an image and misinterpret what it shows.
From the PDF:
FIG . 3 is a flowchart illustrating an overview of an exemplary method

So that flowchart is not showing how BRAW works - it shows how it is done in normal cameras with strongly compressed files.

The claims are the most important part but even interpreting them can be complicated. It looks like claims 1, 15 and 19 are the independent claims. The ones that follow each of these look to be dependent. But I'm no expert.

Steve

The abstract states the “chrominance image can have a lower resolution than that of the luminance image” and that’s what is boils down to. It’s not entirely different than the information we can derive from processing the traditional bayer pattern where the two green photosites influence the luminosity and blue and red influence the final colour.


Sent from my iPhone using Tapatalk

It's true, raw is not only Bayer either. Lossy Bayer is not raw either. Everything is getting conflated by marketing.

If braw can reproduce Bayer values then it is a sort of Bayer. If it can do that true lossless then its Raw. If it can do that close, then it's near raw, which is cool.

I think I know what Braw might mean Bayer Raw. We need a near Bayer raw mode.

Thanks for posting the patent paper. It don’t give away the exact process with BRAW at any camera, but we can see what it can do.

What I find especially interesting is that it mentions the possibility to compress in both discrete cosine or wavelet transform. Redcode use wavelet transform but do all/(most) demosaicing in the computer/hardware later on. The only true benefit Redcode has, by doing so, is that a future encoder software update can deliver an altered image from the source material. BRAW has already done most of this process in camera and that footage can’t be altered in the same degree later on. But the true benefit by doing in camera processing, is speed in post. Which I find even more valuable. You get reconstructed RGB imagery and luma. So white balance and dynamic range should be intact. Question is if the reconstruction hold up... Do we get a image that is true to the source? We can argue about that, and I see the community split on that subject. But there is no doubt Blackmagic can change the way they use containers(like YCbCr420). They leave room for that in the paper IMO.

Based on this paper I would go as far and say that BRAW is just as much RAW as Redcode. Different instruments, same music. Point is, none of them are technical RAW but act like it.

Red code can't be so fantastic then. But wavelet has a lot of benefits. Built in scaling, better efficiency, and in case of ones like cineform (and redcode 2), a degree of simplicity and actual speed which gets hidfen by lack of hardware support. I would think the red patent probably stops some cheap Bayer wavelet hardware support. Gpu cards etc, have built in support for dct video, so BM can take advantage of that. A very small amount of wavelet video hardware support would likely do the same, something that might reduce gaming performance by less than 1fps from being there. So extremely worth including. You notice Red has been in with Nvidia to support redcode gp-gpu processing. I imagine hardware support is coming, maybe even a GPU based Red camera, which would drive their costs down even more. These are the sort of advanced thinking some in the crowd at Red would be contributing to it's success. So, I would advocate to BM to think about my processing on sensor suggestion. They are making chips already, if you can roll another chip into it at the same time, you can drastically reduce costs, or at least move to a cheaper GPU, or arm chipset. If only it wasn't so expensive to do custom silicon asci. I can get chip design software for free that runs in a handful of k's on a 386, but the prototyping is $50k+ a time on a several week/month cycle, which means potentially millions and years to get done. I was just thinking about the business dynamic of Jack Tramiel of Commodore then Atari. He bought a silicon chip manufacture etc, and ran things real lean, just to under cut everybody on value and led the world. Real bullsy guy from a typewriter repair shop. If only Jack, Allan Sugar and Sir Clive Sinclair (and a few others, like Bushell) were in the same company, but my plans to reboot the home computer industry many years back bit the dust. I contemplated I could beat Jack by using a third world micro processor cheap, which would undercut even him. I then realised, if I used even a older local (at the time) fabrication plant using an on chip efficient distributed processing model, they would compete on performance and be maybe similar price. But doing that third world, I could undercut them. The sorts of designs I'm used to start around 1000 transistors single cycle execution, even multiple execution per memory cycle, with graphics, sound, simple interfaces less than 2000 transistors maybe possible on something out competing the 6502 vastly at slower speed. Adding a little extra to do my intelligent vector and compressed tiled/sprite scheme, you could have all that in a competitively sized package (but you need at least two memory banks and some final interface circuitry). All in the transistor count of single competing processor, and in parallel arrays in an x86 size. But these are modern thinking in hindsight, some even beyond.

So, yes you can do things differently and skin the cat.

The BRAW file is 6GB. ( Don't have space to post the file; unless someone might be able to assist. )

It's Constant Quality Q5 recorded to a Samsung T5 1TB USB C SSD drive.

Spoken with a few people about this and the best way to describe it is to say that there is a layer of macro compression that is strong enough to create a layer of compression on top of the image. The 6GB file is a long, single-take recording. The area of concern is where a scene's texture simply disappears/dissolves. At that point, the "macro-blocking" appears and is a movement / texture all into itself that is placed on top of the image. That's why I'm thinking firmware / compression as a means for creating a solution or simply a line of dialogue to bring up for others.

( Yes, I have sold the BMPCC4K. Yes the BRAW file(s) can be made available. If it's worth our time, maybe there is a location that I might upload the large file too? )

Levi, you can use https://www.filemail.com
The free version lets you upload up to 50GB once a day.
Just select "send as link" and after the upload finished copy/paste the link here.

For faster uploads you can install their desktop app:
https://www.filemail.com/apps

The company is from Norway.