Komodo REDCODE RAW Explained

[Jon Dishler]

I'd expect the encoder on the DSMC2 cameras is purpose built ASIC for DWT RedCode, so not able to author DCT RedCode. Even if I'm wrong and it's a FPGA, the second issue would be max quality of a DCT bitstream at 300MB/s, which I understand to be the write speed limit of the mini-RedMags. In a theoretical world I see the allure of an all DCT based ecosystem, but as a practical matter I don't think that's going to happen.

An efficient, client side heavy codec was exactly what we needed to get the digital cinema train out of the station. Now that writing to compact, commodity media in camera at >500MB/s is viable - proposed flavors of CF Express potentially quite a bit more - lower compression ratios and less complex codecs can be employed. Thanks to the ever dropping cost of storage, the bigger data footprint is no longer a killer. Before long we'll forget what wavelets even are... ;-)

Cheers - #19

Can DCT be used with all video editors or only Redcine-X at this time, is the file still an R3D? If the compression is different how do programs like FCP X handle this?

 

[Bastien Tribalat]

Can DCT be used with all video editors or only Redcine-X at this time, is the file still an R3D? If the compression is different how do programs like FCP X handle this?

It works flawlessly in Premiere and Resolve. (I don't have FCPX so I can't tell you)

 

[Robert Hofmeyr]

It works flawlessly in Premiere and Resolve. (I don't have FCPX so I can't tell you)

Working in FCPX with latest Red apple workflow software.

 

[John Brawley]

Can DCT be used with all video editors

DCT compression is the basis of ProRes, ProRes RAW, Blackmagic RAW, and going back further, Mini DV / DVCPRO and DVCAM.

JB

 

[Bastien Tribalat]

Working in FCPX with latest Red apple workflow software.

Good to know ��

 

[Peter Choi]

Thank you Phil and happy birthday. An inspiration and amazing resource for us all.

 

[Todd G. Peterson]

Cosine encoding, chunkier though easier to encode and much easier to decode. Cons, limited compression ratio range and certainly not doing 22:1 to get cinema grade images. But you will have some reasonable range to expand recording times. And the benefit, and I mentioned it early on when I was looking at Komodo 6K footage, I was able to turn my GPU acceleration off and get realtime 6K REDCODE HQ playback. That will allow more modest hardware to be used, speed up encoding and decoding, and on the camera side opens up the world to smaller and less power hungry professional tools.

Thank you Phil for this interesting discussion of how Redcode has changed with Komodo. I was wondering why the compression ratios were limited and the data rates were comparatively high. This answers that.

DCT Redcode seems to reduce encode/decode compute requirements at the cost of higher file sizes (and fewer compression ratio options) as compared to DWT, which may be a key factor in making the Komodo possible (very small/low cost), and maybe will result in cheaper and/or more powerful DSMC3 brains.

There are two issues that I currently see with changing to DCT, however. First, is the media cost. Helium 6K 24fps FF at 8:1 is 91 MB/s, whereas the Komodo at the same settings, but using MQ is 237 MB/s (Jarred said MQ is visually similar to 8:1 on DSMC2). That's 2.6x the data. If I were to shoot 1200 minutes of footage (as I plan in my next few projects) on Helium at 6K 8:1 I would need about 6.4TB of storage. If I did the same with Komodo, I would need almost 17TB. That's a significant cost in media and transfer times that will add up over time. Following Moore's Law, it will take more than 2 years for 17TB of storage to be the same cost as 6.4TB today.

The second issue is that I don't see the lower compute benefit of decoding with Recode DCT while editing and coloring. Maybe it makes a big difference playing back within a Red brain, but there doesn't seem to be much benefit on a computer in my testing. I tested 6K 24fps FF at 8:1 from my Epic-W and your Komodo 6K FF clip (the one with the chip chart) on a Ryzen 3900X 12-core computer with 32GB RAM and an RTX 2070 8GB GPU. I used Resolve 16.2.4 Studio (latest version with Komodo support) set to GPU accelerate debayer and decompression. In the edit panel with a 4K timeline, my CPU only uses 5% on both clips. The GPU load is 40% for the Komodo clip and 50% for the Helium clip. Throwing on a couple of color correction nodes and some temporal NR in the color panel only adds about 5% more to the GPU load for both. Maybe there's something I'm missing, but I don't see a significant reduction in GPU load with Komodo footage. I would have expected it to be much more lightweight like other DCT codecs.

 

[Sabovic Adis]

Thank you Phil for this interesting discussion of how Redcode has changed with Komodo. I was wondering why the compression ratios were limited and the data rates were comparatively high. This answers that.

DCT Redcode seems to reduce encode/decode compute requirements at the cost of higher file sizes (and fewer compression ratio options) as compared to DWT, which may be a key factor in making the Komodo possible (very small/low cost), and maybe will result in cheaper and/or more powerful DSMC3 brains.

There are two issues that I currently see with changing to DCT, however. First, is the media cost. Helium 6K 24fps FF at 8:1 is 91 MB/s, whereas the Komodo at the same settings, but using MQ is 237 MB/s (Jarred said MQ is visually similar to 8:1 on DSMC2). That's 2.6x the data. If I were to shoot 1200 minutes of footage (as I plan in my next few projects) on Helium at 6K 8:1 I would need about 6.4TB of storage. If I did the same with Komodo, I would need almost 17TB. That's a significant cost in media and transfer times that will add up over time. Following Moore's Law, it will take more than 2 years for 17TB of storage to be the same cost as 6.4TB today.

The second issue is that I don't see the lower compute benefit of decoding with Recode DCT while editing and coloring. Maybe it makes a big difference playing back within a Red brain, but there doesn't seem to be much benefit on a computer in my testing. I tested 6K 24fps FF at 8:1 from my Epic-W and your Komodo 6K FF clip (the one with the chip chart) on a Ryzen 3900X 12-core computer with 32GB RAM and an RTX 2070 8GB GPU. I used Resolve 16.2.4 Studio (latest version with Komodo support) set to GPU accelerate debayer and decompression. In the edit panel with a 4K timeline, my CPU only uses 5% on both clips. The GPU load is 40% for the Komodo clip and 50% for the Helium clip. Throwing on a couple of color correction nodes and some temporal NR in the color panel only adds about 5% more to the GPU load for both. Maybe there's something I'm missing, but I don't see a significant reduction in GPU load with Komodo footage. I would have expected it to be much more lightweight like other DCT codecs.

What's the cost difference between Komodo and Helium?

 

[Robert Hofmeyr]

Thank you Phil for this interesting discussion of how Redcode has changed with Komodo. I was wondering why the compression ratios were limited and the data rates were comparatively high. This answers that.

DCT Redcode seems to reduce encode/decode compute requirements at the cost of higher file sizes (and fewer compression ratio options) as compared to DWT, which may be a key factor in making the Komodo possible (very small/low cost), and maybe will result in cheaper and/or more powerful DSMC3 brains.

There are two issues that I currently see with changing to DCT, however. First, is the media cost. Helium 6K 24fps FF at 8:1 is 91 MB/s, whereas the Komodo at the same settings, but using MQ is 237 MB/s (Jarred said MQ is visually similar to 8:1 on DSMC2). That's 2.6x the data. If I were to shoot 1200 minutes of footage (as I plan in my next few projects) on Helium at 6K 8:1 I would need about 6.4TB of storage. If I did the same with Komodo, I would need almost 17TB. That's a significant cost in media and transfer times that will add up over time. Following Moore's Law, it will take more than 2 years for 17TB of storage to be the same cost as 6.4TB today.

The second issue is that I don't see the lower compute benefit of decoding with Recode DCT while editing and coloring. Maybe it makes a big difference playing back within a Red brain, but there doesn't seem to be much benefit on a computer in my testing. I tested 6K 24fps FF at 8:1 from my Epic-W and your Komodo 6K FF clip (the one with the chip chart) on a Ryzen 3900X 12-core computer with 32GB RAM and an RTX 2070 8GB GPU. I used Resolve 16.2.4 Studio (latest version with Komodo support) set to GPU accelerate debayer and decompression. In the edit panel with a 4K timeline, my CPU only uses 5% on both clips. The GPU load is 40% for the Komodo clip and 50% for the Helium clip. Throwing on a couple of color correction nodes and some temporal NR in the color panel only adds about 5% more to the GPU load for both. Maybe there's something I'm missing, but I don't see a significant reduction in GPU load with Komodo footage. I would have expected it to be much more lightweight like other DCT codecs.

All good points Todd. Storage costs are getting cheaper fast, but for smaller budget work like mine the additional storage costs are definitely something that needs to be budgeted for. Jarred did mention that Komodo compression will become more optimised over time, so the data rate will decrease while the quality will remain the same - hopefully we will end up with less than double the data rate for similar quality.

Regarding the computation requirements, I think maybe Red is still optimising the software. I tested Phil's short clip (which looks incredible BTW) in Redcine on my macbook pro and playback is quite a bit slower than my 6K 8:1 Dragon footage (realtime playback of the Dragon footage was possible at quarter res, whereas the Komodo footage could only do realtime at 1/8th res). I was playing both clips back off my internal SSD, so I doubt that read speeds were the bottleneck.

Pretty sure everything is still going to change, so my plan is to wait a bit and see where things end up, both in terms of storage and speed.

 

[Phil Holland]

interesting discussion

Just tackling a few points mentioned while I'm up late. First and foremost, it's day 1 for this new style of transform to be implemented. Real hardware optimization and other things are coming. Resolve shouldn't be considered the test bed as they need to tap into developed SDK that's been fully tested and deployed. Same for any 3rd party software really. There will be a time that's more useful to test, but right now it's early days with REDCODE RAW w/ DCT. More or less you won't see the main benefit right this second, but tomorrow when things get squared up, you'll be doing crazy things.

I don't use AMD processors for a host of reasons, but the first thing you should test is disable all GPU acceleration in REDCINE-X Pro and try playing back both 6K 5:1 and 6K HQ at full debayer just off the CPU. That should tell you a bit about the potential of what's coming.

In reference to your filming Helium at 6K 8:1, bare in mind you are filming at 8:1 which is already a higher compression ratio than what's achievable at the higher data rates your camera offers. You *can* film 6K at 3:1, which would be more in the HQ range. The net effect of what you hoping to achieve is whatever REDCODE RAW LQ data rates end up at (LQ is currently not implemented in Komodo, but it's coming). Knowing what I know about DCT, if I had to guess you'd be looking somewhere between the approximate data rates of 6:1-9:1 depending on RED's target and deployment. I strongly don't think things will evolve to a lower data footprint to 12:1 today, but that's just a hunch. But yeah, for a more apples to apples sort of thing, you'll be doing REDCODE RAW LQ to get to the footprint you're after.

The power behind DSMC2 at the developed hardware, ASIC, and all that is you do have this crazy ability to do things like higher REDCODE RAW compression levels, but at the same time I've been an advocate of really not reaching beyond 12:1. I'm not just making that recommendation because I picked a number out of the sky. I'm making that suggestion after rigorous QC as well as projected and high resolution finish image quality tests.


Modern codecs are getting absolutely fascinating as well as the wants, needs, and desires of the people who purchase these cameras. Somewhere in between Uncompressed RAW, Compressed RAW, and raw that isn't RAW, various methods to use non-linear to linear methods, combined with people who only look at the data footprint and don't think or care about much else will be the answer. The questions will be and always will be is RAW important to you? Is higher bit depth (16, 15, 14, 12, 10) important to you? Do you have issues with using chroma subsampled acquisition over RAW? If not, then do you want 4:4:4, 4:2:2, and *gasp* 4:2:0. Do you want to capture in 10-bit H.265 LOG over say 16-bit REDCODE RAW? This chaotic minutiae extends to the features of the sensor designs, camera features, how things are marketed, etc.

The concern I've had for a bit here is the consumer and entry level market want "RAW", but don't even know what RAW is anymore nor the underlying reasons for all of this. Then the extension from there is they want LOG, which is thankfully a given at this point in however people choose to get there. But a core audience of mass market image makers has drifted into the zone of more of the video mindset, which happened before, we're here again. We just want to roll more footage and buy less tape. In the filmmaking world we didn't exactly have the ability to do extended recording on a 1000' roll of film, so it was a pretty alien concept outside of saving cash on film by shooting to modified 3-perf and even 2-perf movements on what was previously 4-perf S35.

As we reach further towards higher image quality, though compression schemes and things can evolve, there is a point where we're just going to be dealing with chunkier data rates. Nobody thinks about capturing beyond 16-bit for instance much, but there will be a time when that's possible, though I'm certain there will be amazing chatter about how we don't need that if we are only making images for 10 or 12 bit panels. I've fortunately "ascended" a bit beyond those style of conversations over the years. The market is too dynamic to be concerned about what the needs of higher end filmmakers are versus entry level shooters, but we just need to be sort of aware of both far sides of the spectrum. Now there's cross talk and overlap confusing things which will have a negative impact on some parts of the industry and a positive impact mainly on the lowest priced tools available. Which puts into question what higher end tools will look like and be priced like in the future.

Technology is advancing at a rate higher than market adoption at the moment. These next few years are going to be weird in many ways. The faster paced mobile market is sort of the pin point example of how crazy things are. Previously we'd get a processor per generation, then for a bit it was 2 releases, now there's 6. Which is also putting what was 18 month product timelines more squarely into the 3-6 month range. Same for mobile image sensors, with 4 or the 6 latest technologies (that I'm even aware of, just looked up a couple of new ones which can be dev'd, so make that 8) not being available in any device yet.

The only fortunate thing for professional filmmakers is we have a very established global 2K/1080p HD market with 4K/UHD 2160p being the highest growth trend and the emergence of UHD 8K (still not much chatter about DCI 8K, but it will be there at the end of the day) becoming a standard. So in terms of that worry about what you are delivering to, there's your answer on what your "needs" are from your tools. Long distance future, yes there are plans for 16K displays, but consumers will be looking at that transitional gap harder than anything as 90-120" televisions aren't common place in the home. Before we get there we have some new panel tech and likely round three of HDR being deployed. The journey to 4K and 8K were always somewhat obvious still in a community that doesn't fully agree with that, but the less obvious things for me are the world beyond 8K as a delivery medium. Mainly because the general ecosystems aren't even being explored yet outside of 360 video (yes, YouTube supports 16K and has for a very long while).

I diverged a bit off topic, but that's what's going on industry-wise. Professionals still need professional tools. We're in a moderate amount of chaos with some of the lower end stuff being positioned against the higher end gear, so expect those conversations to only get worse with producers who have to deal with that already. But there are far fewer higher end gigs than lower end gigs, which is really what happened in the last 10-15 years. Now there's tools to cater to the entire market as the demand become rather demanding.

Pros for filmmakers, really capable tools at every price point. The IQ/performance/feature gap is in some ways shrinking between higher end tools as well as oddly expanding in some ways.

 

[Antony Newman]

A random thought.

If Wavelet compressions can reduce file size to (finger in the air) half the size of DCT,
and transforming from DCT -> Wavelet halved disk space :

+) Would RED consider adding an 'ARCHIVE' R3D batch function that could transform from DCT -> Wavelet?

(It could half long term storage costs)

AJ

 

[Todd G. Peterson]

A random thought.

If Wavelet compressions can reduce file size to (finger in the air) half the size of DCT,
and transforming from DCT -> Wavelet halved disk space :

+) Would RED consider adding an 'ARCHIVE' R3D batch function that could transform from DCT -> Wavelet?

(It could half long term storage costs)

AJ

This is a great idea AJ!

Yes, storage prices are dropping all the time, but it sure does eat up a lot of my budget. These days I often archive to a H.265 master, but it kills me each time. I want to hold on to the RAW files for as long as possible. DCT is going to make that much harder. If there was a way to transcode DCT->DWT for archival purposes I would eat that up. It doesn't even need to be near realtime. Maybe I would need a beefy GPU, but there are big leaps coming this year in GPU speed and more to come.

 

[Phil Holland]

A random thought.

If Wavelet compressions can reduce file size to (finger in the air) half the size of DCT,
and transforming from DCT -> Wavelet halved disk space :

+) Would RED consider adding an 'ARCHIVE' R3D batch function that could transform from DCT -> Wavelet?

(It could half long term storage costs)

AJ

That would require re-encoding RAW data as well as a generational quality loss, which wouldn't be how that works. You can Trim R3Ds however.

 

[Todd G. Peterson]

That would require re-encoding RAW data as well as a generational quality loss, which wouldn't be how that works. You can Trim R3Ds however.

Most any format that you would use for archive would be lossy so you'll take that hit not matter what unless you keep the original files.

As for re-encoding, even though Redcode is lossy, I would think you could still reconstruct the bayer data fairly well given the low compression ratio of DCT. Maybe not. Would be interesting though.

 

[Phil Holland]

Most any format that you would use for archive would be lossy so you'll take that hit not matter what unless you keep the original files.

As for re-encoding, even though Redcode is lossy, I would think you could still reconstruct the bayer data fairly well given the low compression ratio of DCT. Maybe not. Would be interesting though.

It's not a maybe not. It's a not. RAW still means something to the professional space and will for a long, long time to come. There's actually industries who are mandated to only film in RAW formats (think forensics and military usage). In the RED world, this is your digital negative.

Much like a roll of film, you can splice it (trim), but that's it.

It may not seem like it from some perspectives, but this is actually a feature and a thing you want. There's many ways to export things at lower data rates if that is your core workflow. It's just not going to be RAW outside of trim workflow.

Traditionally when editorial goes through the archival process, even on films shot on film, once the selects are made and final cut is figured out, extra takes are discarded (usually destroyed actually) and the negative is archived. Then there's the project Master Deliverable. Most seems to archive the Master Deliverable to ProRes 4444 or whatever, feature world is still 16-bit uncompressed image sequences on the highest data footprint. Some productions keep alternate cuts and things like that as well, what I lovingly call tier 2 and possible tier 3 footage on larger shoots, but it's rare for a film with over 3 million feet to archive every single reel, though probably becoming more common lately.

My personal workflow with digital, I archive every single frame of raw material. Because it seems that inevitably I need to dig up stuff, even stuff I shot in the early 2000s. But that's not for everybody.

 

[M Harvey]

the consumer and entry level market want "RAW"

I don't want to derail the thread, since I'm here to learn about Komodo and the new R3D-- and frankly, the stuff I never understood about Red's wavelet-based R3D! But I just wanted to highlight this, because I've found it a very confusing trend. Virtually any time a new camera is announced or footage is posted, you see comment sections flooded with complaints that the given camera doesn't shoot "raw."

Why is it that so many people now feel that they need the capability to record raw in camera? (Or that they're entitled to it, for that matter. The attitude is part of what's notable.)

My working ideas, though:
-Consumer assumptions are perhaps shaped by analogy to the relationship between raw and jpg on still cameras, where the benefits of raw are clear and the drawbacks are comparative minimal.
-the idea that raw is "pro," and anything else is therefore "amateur." (And perhaps ignorance of the fact that we've all seen plenty of stuff in theaters and on TV shot in prores, x-ocn, and other non-raw formats.)
-past experience with software-based "crippling" of camera capabilities perhaps suggests that a $2500 camera would shoot much better footage-- if only the greedy manufacturer weren't protecting their $50k camera. (This argument is a pet peeve of mine, though I get why it bothers people.)
-along similar lines, the availability of Blackmagic cameras that shoot cinema dng from $1k perhaps suggests that all the other manufacturers are holding back.

Ok, apologies-- the mention in Phil's comments got me going on the theme, but possible this is better saved for a separate discussion.

 

[Todd G. Peterson]

It's not a maybe not. It's a not. RAW still means something to the professional space and will for a long, long time to come. There's actually industries who are mandated to only film in RAW formats (think forensics and military usage). In the RED world, this is your digital negative.

...

My personal workflow with digital, I archive every single frame of raw material. Because it seems that inevitably I need to dig up stuff, even stuff I shot in the early 2000s. But that's not for everybody.

I also tend to keep most of my RAW footage. Footage is very expensive to create, but not too expensive to keep. For masters it depends on the project. For commercial and narrative work, Prores 444 or DNx 444 is common. Web projects might only be H.264/H.265. For higher budget work (mainly narrative), I've been archiving a master as 16-bit DPX, but at 1.2GB/s (71GB/min) for 4K DCI I try to use it judiciously.

Maybe I'm missing something, and I'm no expert on matrix math and transforms, but it seems to me if you had low compression ratio DCT of raw Bayer data, many of the detail coefficients would be close to zero and thus have little to know picture information (i.e., decompressed RAW would be perceptually lossless). The decompressed (now uncompressed) RAW Bayer data could be DWT transformed lossly. Because you have done all of this before demosiac and any processing, it's still raw sensor data. There would be generational loss, but error correction could help with that, as could other methods. At the cost of a small amount of data loss, you could reduce the storage size 2-3x while still being RAW.

 

[Steve Sherrick]

I don't want to derail the thread, since I'm here to learn about Komodo and the new R3D-- and frankly, the stuff I never understood about Red's wavelet-based R3D! But I just wanted to highlight this, because I've found it a very confusing trend. Virtually any time a new camera is announced or footage is posted, you see comment sections flooded with complaints that the given camera doesn't shoot "raw."

Why is it that so many people now feel that they need the capability to record raw in camera? (Or that they're entitled to it, for that matter. The attitude is part of what's notable.)

My working ideas, though:
-Consumer assumptions are perhaps shaped by analogy to the relationship between raw and jpg on still cameras, where the benefits of raw are clear and the drawbacks are comparative minimal.
-the idea that raw is "pro," and anything else is therefore "amateur." (And perhaps ignorance of the fact that we've all seen plenty of stuff in theaters and on TV shot in prores, x-ocn, and other non-raw formats.)
-past experience with software-based "crippling" of camera capabilities perhaps suggests that a $2500 camera would shoot much better footage-- if only the greedy manufacturer weren't protecting their $50k camera. (This argument is a pet peeve of mine, though I get why it bothers people.)
-along similar lines, the availability of Blackmagic cameras that shoot cinema dng from $1k perhaps suggests that all the other manufacturers are holding back.

Ok, apologies-- the mention in Phil's comments got me going on the theme, but possible this is better saved for a separate discussion.

RAW does not = pro. It's simply one way of capturing an image. But it has many advantages for sure and perhaps some disadvantages as well. Understanding project's needs usually helps identify what acquisition format is needed.

As for Blackmagic, I still have their OG Pocket Cinema Camera. Fascinating little device, especially the capability of shooting RAW on a $1K camera. But not without its limitations, some of which can be showstoppers for some people. For example, with no OLPF and using very sharp lenses, you can run into severe problems with moire and aliasing. So, you need to add a 3rd party OLPF if you want to use those lenses. Battery life is abysmal so if you need to run for long periods of time, you need a 3rd party battery solution. The screen is unusable outside and barely useable inside. The camera mic and audio circuitry in general is very bad. It's a S16ish size sensor, so you need a speed booster if you want to change the crop factor. Yet, with all of those limitations, it can shoot remarkably good 1080P RAW video and I love pairing mine with vintage lenses such as Nikon ai-s and Pentax Takumars. They take the edge off the image and run into fewer problems with moire. Color science and DR are not too bad for a $1K camera but will get beaten out rather easily by an Alexa and a RED, so again really comes down to what you want to do with it. I enjoy it now for shooting abstract stuff, love what I get with Macro lenses ( I own 2 really great M42 macros) and the small size just makes it fun to play around with. Just don't handhold it unless you are a big fan of micro jitters.

So, the new crop of Blackmagic cameras are priced right for a segment of the market that needs access to affordable digital cinema cameras that have quality that approaches the top names in the business (Arri, RED, Sony). But there will be tradeoffs. Some of those are not showstoppers for many people, for others they are. And that's where you can see the price gaps. Blackmagic has definitely gained some ground with reliability. For a while, there were manufacturing issues. I feel like there are less of those on the newer cameras. And that's not to say that I haven't seen an Alexa fail or a RED go down, they all have their moments, but in general build quality tends to favor the higher end companies. Things like heat management, quality of internal components, etc. are often just better when you get up into the higher price ranges. But that doesn't mean these lower end cameras can't capture a great image. Put in the right hands, they are capturing beautiful imagery.

I think Komodo has the potential here to close that gap a bit by entering the sub $10K market. An internal RAW camera that checks off a lot of boxes for this price point once again illustrates that there's a camera out there for everyone and every project. From the filmmakers getting started picking up a used $400 OG BMPCC those now dipping their feet in the RED water with the Komodo all the way up to the Monstros and Alexa LF. Almost every base seems covered.

 

[Phil Holland]

theme

I'm truly not sure why everything happened the way it did, but it likely has something to do with the growing camera market, production costs, and that dynamic industry thing I keep mentioning.

RAW represents a digital negative. This has appeal to filmmakers, particularly filmmakers who have worked on film. The additional benefit along the way is as things like color science, image processing, and various other under the hood technologies is that RAW exists and benefits from that in a non-destructive manner.

To that point, the non-destructive workflow is highly appealing.

The Pro versus Amateur perspective is sort of a non-starter. The shear volume of productions who just use ProRes workflows allude to that not being of the highest priority. Which has opened the door for things like BRAW to exist in it's current state even. All good, there's more than one workflow for sure.

There are still many advantages to a RAW format and for those that tap into that or need it, well, that's the goodness. I am still in that camp. I use ProRes often for delivery, but nothing I've shot in the last decade professionally wasn't RAW of some sort. RED, Arri, Sony, etc. Even the film stuff was fully uncompressed RGB in Cineon Log, but that's far from many's workflows these days. My experience is not going to reflect everybody's. I consulted on some fast turnaround stuff that was highly focused on high quality mobile workflows for instance, hardcore ENG, they needed the workflow, but not me to do the work. They have 50 staff for that. Desired ProRes 422 HQ, they got it, really didn't want H.265 for keying and other reasons. Lots of different needs out there.

Software crippling is an issue, mainly on lower priced cameras and also mainly because they offer higher end cameras that do more of the job at a higher price. There really hasn't been much of that in the professional space mainly because the world would set on fire if you were/are spending $$,$$$ and some enterprising lad figured out there was more under the hood. And in the world of ARRI you are happy to pay for software features as licenses and they are up front about that, don't think that lands well in less expensive cameras and honestly don't know how much of that mindset will be there in the future. In the RED world the closest issue was being able to monitor a larger 5K image (via look around) on Scarlet at one point, but when attempting to record that image there wasn't the hardware in the camera itself to support that both in memory and processing power. People griped, mostly people who don't know how cameras (and probably cars) work. Most recently, today, The Sony A7IIIs raises an eyebrow by not having DCI 4K in there as the camera can support that, I'd expect a rather quick firmware update on this front unless they are truly boxing folks out or perhaps the target audience doesn't care about DCI in 2020 as most of the world is 16:9. Hopefully they don't charge for that. Don't think they can or it's going to be somewhat magical lantern lit journey ahead.

I speak to many who don't understand why system X, Y, or Z costs more or less than system A, B, and C. Many who have or have not used equipment on either side of that equation. Most haven't used or tested many of the cameras until they stumble across one on a job or similar. Most people honestly don't dig deep into these imaging systems unless they truly need to. I get asked about issues about cameras from every manufacturer weekly when people hit certain walls. Bailed a few productions out on VFX or color work related fixes because their $25K shoot didn't have a budget for $25K worth of post or whatever. It's interesting to see all of the ugly in there along the way. Gives me a clear idea of sort of what each manufacturer needs to work on at the end of the day.

For many, the cookies just need to be made. Doesn't matter what's in them, what type they are, how good they are, what shape they are, or what the ingredients are. Some people just need cookies at any price. Others get rather particular about the cookies they use, perhaps the brand has been around a while, perhaps they deliver a shocking amount of flavor in a tiny package, perhaps there's a knowledge going into a cookie that the flavor will be there and you can rely on that, etc.

Oddly I don't think I've had a cookie this year, but you get the idea.

 

[Blair S. Paulsen]

Please , somebody send the man a cookie ;-)

To echo Phil, I also see a major disconnect between the folks looking to get the most out of a particular camera system/file type - you know, people like us who post on a camera tech forum - and those just wanting the shortest path to a professional level image. As Mike Most has noted over the years, even the big timers are typically focused on cost and turnaround times, so it's not just a low vs high end issue. I'd also note that many of my clients want mind blowing images (I do a lot of spot work) as cheaply as they can manage. No surprise there, but all too often they don't fully grasp what impact various choices will make on the final product.

IAC, this thread is about codecs in the professional space and the value of a RAW data set. RED's move to DCT with it's larger file sizes is likely to be interpreted rather differently depending on your pre-existing inclination. At it's most basic, you have the pushback against larger data footprints. The whole issue of easier decoding/playback may often be viewed as "somebody else's problem". The nuances of codec performance are gobbledygook to most folks - but they'd rather not admit that for obvious reasons...

Cheers - #19