Welcome to our community

Be a part of something great, join today!

Register Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Komodo REDCODE RAW Explained

Happy Birthday, and Enjoy your Pandemic Cake. Turn off all screens and just soak it in. Great Write-up and Explanation of DCT vs DWT.
 
FWIW, no compression scheme is inherently better than another. Some are more efficient, some have more objectionable artifacts when bit starved, some need more client side computational muscle, etc. Good old DV25 was DCT based and, at 25mb/s (essentially 3MB/s) had to decimate color channels just to do 720/24P. At 300MB/s or better, it's a different equation.

BRAW is a hybrid scheme that does a partial demosaic in camera. This reduces the data rate and requires less resources to decode/playback while still providing a RAW file that allows post adjustment of ISO, color temperature and tint. What you lose is the ability to reconstruct the image from the ground up using the capture data set. Does that matter? In most cases, particularly with well shot footy, it's not crucial. In a situation where you really need to dig into the image files and adjust parameters, then the partially "baked" BRAW will be an impediment. It also takes away the potential for using a new algorithm on older footage. Is that important? For some creators and archivists it certainly is. Others...

Cheers - #19
 
Happy Birthday, Phil! Thanks for all you do for the rest of us, hope you get a chance to kick back and enjoy the day.

This is a great post, and I feel like I'm gonna be revisiting it in coming days. From a design perspective, why so little difference between HQ and MQ? If the file size is only about 10% smaller, it makes it feel like the choice between the two is almost arbitrary-- you're only getting very slightly better quality or very slightly better runtime, right? (By comparison, a quick google tells me that HD ProRes 422 is approximately 66% the size-per-time-unit of HD ProRes 422 HQ.) While the difference adds up over time, it's not enough to materially change how you'd approach most jobs (e.g. number of cards, number of off-load drives, budgeting time for off-loads or money for a DIT, etc. etc.)
 
Happy birthday Phil!
Thank you for putting all of that information together in such a fantastic and interesting way!
I’ll have to quote you on the entire thing as I’ve spent hours on end trying to explain the practicalities and complications of REDCODE RAW to the uninitiated.

When this is all over, I owe you a beer!
But for now, enjoy your Pandemic Cake and stay safe!

Jarred, I still have my REDROCKET! Saved my ass more times than I can remember!
 
Jarred Land said:
Love you Phil, well done and thank you. And happy birthday!

Few things to add to your overview, First REDCODE has evolved with every camera generation from REDONE to EPIC to DSMC2 and now Komodo and DSCM3, all of them using different/modified compression foundations. And just like now all these evolutions have been almost invisible to the end user. The actual compression engine that is chosen to go into a camera are more about the media environment and the post production hardware market than they do with what is going on in the camera, as almost all actual compression engines share a similar quality just at different efficiencies. Some work better with super compression at the expense of massive end hardware requirements like various wavelets, some like DCT are fantastic at keeping detail specially as you feed it more bits.

Remember the Red One was recording 40MB/s.. a fraction of what we are at today and to play 4k back in realtime back in those days cost a machine that cost as much as a house. So most people were forced to work in a lower wavelt of resolution or purchase a RED ROCKET which I very publicly hated to force our customers to buy into to get the best experience.

Fast forward to today... We live in a world where storage is fast and cheap and most relatively affordable consumer computers are capable at 8k realtime playback, we get to update REDCODE again to take advantage of the landscape. This is a a forward step, the version of REDCODE inside Komodo wasn't just developed for Komodo, We started developing it may years ago for and will be used in DSMC3 and forward until something better comes along and we upgrade it again.

But make no mistake.. it's still REDCODE. We still are tweaking... the army of stormtroopers that go out in the coming weeks will help with that, so expect a lot of improvements along the way as we march towards the actual release... because remember, Komodo still doesn't actually officially exist yet :)
Click to expand...

Thanks Jarred. I was concerned that Komodo redcode was a compromise as a result of lower computing power. If it's what you are using for DSMC3, then I am not worried at all.
 
M Harvey said:
Happy Birthday, Phil! Thanks for all you do for the rest of us, hope you get a chance to kick back and enjoy the day.

This is a great post, and I feel like I'm gonna be revisiting it in coming days. From a design perspective, why so little difference between HQ and MQ? If the file size is only about 10% smaller, it makes it feel like the choice between the two is almost arbitrary-- you're only getting very slightly better quality or very slightly better runtime, right? (By comparison, a quick google tells me that HD ProRes 422 is approximately 66% the size-per-time-unit of HD ProRes 422 HQ.) While the difference adds up over time, it's not enough to materially change how you'd approach most jobs (e.g. number of cards, number of off-load drives, budgeting time for off-loads or money for a DIT, etc. etc.)
Click to expand...

From my understanding, doing any kind of higher frame rate you need MQ. So it is as compressed as it needs to be to get those extra frames. (But my understanding is very limited and I am trying to figure it out.)
 
Happy Birthday Phil!!!
 
Christian Jadot said:
it is as compressed as it needs to be to get those extra frames.
Click to expand...

That makes a lot of sense, Christian-- thanks. (I still might like another medium option-- the midpoint of quality trade-off to record time--, but maybe that's exactly what LQ will be like...)
 
Have to admit, the data rate has been a growing concern for me as this would be a considerably larger data footprint than I'm used to but I'm glad to see RED (through Jarred no less) is directly acknowledging the issue and exploring ways to deal with it.

Happy Birthday Phil and thank you for the informed input.

I already knew Phil is knowledgable by reading his various posts over the years but after listening to his interview with Scott Balkum
I have considerably more respect for his knowledge and experience. He's definitely a very BIG asset to REDusers and the greater filmmaking community.

This interview is worth the time as it's packed with a lot of great info.


Hope to hear great news on the data rate front as Komodo gets finalized.

Brian Timmons
BRITIM/MEDIA
 
Jarred Land said:
This is a a forward step, the version of REDCODE inside Komodo wasn't just developed for Komodo, We started developing it may years ago for and will be used in DSMC3 and forward until something better comes along and we upgrade it again.
But make no mistake.. it's still REDCODE. We still are tweaking... the army of stormtroopers that go out in the coming weeks will help with that, so expect a lot of improvements along the way as we march towards the actual release... because remember, Komodo still doesn't actually officially exist yet :)
Click to expand...

Jarred, would you please consider adding a CQ (Constant Quality) options to the new REDCODE version? That would actually (at least in theory) be even easier on the hardware/power consumption because no need for complex adaptive quantization, just a static quantization table. It would really be the perfect compression mode without compromise. Maximum quality but still keep the data rate low when possible. The same way all still codecs (like JPEG) usually works. Blackmagic RAW support this with the Q0 and Q5 modes.
 
M Harvey said:
From a design perspective, why so little difference between HQ and MQ? If the file size is only about 10% smaller, it makes it feel like the choice between the two is almost arbitrary--
Click to expand...

That's just what it is now ( in beta form ) , MQ data rate is quality based ( from a design perspective ) and not data footprint based, which means MQ we target a visual quality of what would compare to 7:1 or 8:1 in Redcode on a DSMC2 camera. As we tune things and improve the compression, the visual quality will stay the same but the actual MB/s should go down. Nothing really novel about that, it is how we have done it since the start. We will always, like we have in the past, pick higher data rate for better quality even if it is just temporary.
 
HAPPY BIRTHDAY PHIL and thanks so much for all the amazing knowledge, experience, and perspective you are dropping on us!

Just watched your livestream with Scott from May and didn't know that you did all the mesmerizing apple screensavers! I always tried to guess what framerate this was shot on and how fast the helis flew. It's like almost frozen, especially the Hong Kong one. :D
 
Jarred Land said:
As we tune things and improve the compression, the visual quality will stay the same but the actual MB/s should go down. Nothing really novel about that, it is how we have done it since the start.
Click to expand...

Thanks for clarifying. And that's great news!
 
Thanks Phil and Jarred for those very awesome informations.
Makes a lot of sense. I hope LQ will offer a more manageable data footprint for me but anyways, that's great.
 
Thanks for the detailed clarification. It felt indeed strange that the info was kind of out but obviously talked around - which is maybe just because the usual communication is so open & clear about the rest of the camera. It was just this contrast in communication I guess.

But thanks for the detailed clarification!

For me, a data rate based HQ and a quality based MQ setting already make sense on their own. LQ for when it really doesn't matter that much..
 
Andreas Eymannsberger said:
Thanks for the detailed clarification. It felt indeed strange that the info was kind of out but obviously talked around - which is maybe just because the usual communication is so open & clear about the rest of the camera. It was just this contrast in communication I guess.

But thanks for the detailed clarification!

For me, a data rate based HQ and a quality based MQ setting already make sense on their own. LQ for when it really doesn't matter that much..
Click to expand...

Camera still isn't officially out remember there is no spec officially released... and LQ we still havn't landed on where we want it to be. Not really talked about because it really isn't that big of a deal. And yes, your breakdown is exactly the right mindset.
 
With Komodo, and DSMC3 to come, we'll have DCT - discrete cosine based RedCode instead of the wavelet based (JP2K) version going back to R1.

The most notable trade off being file size vs decoding complexity. Assuming the final IQ is similar, then the issue is data footprint vs computer resources. With storage devices and I/O getting better and cheaper, RED sees greater utility in a DCT based topology that allows real time playback/output on modest hardware.

Are we just trading the cost of beefy GPUs in hot rod systems for bigger RAIDs? To some degree, we are. That said, especially assuming storage costs continue to drop, it would seem to be a better tack. For example. In most cases, the cost of the computer hardware is a capital expense paid off over time by you and/or the post house. Storage, OTOH, is typically something you can invoice per project to the client.

There's also the user experience. If your computer can't playback DWT based R3Ds smoothly, or requires 1/4 res or less to do so, it's a bummer. Yes, a 4TB SSD will cost more than a 1TB SSD, but, since you're saving on the processing hardware, total cost might actually be lower. It also means that collaborators who don't have shredder computers will still be able to work with the R3Ds natively instead of requiring a transcoded RGB or proxy file.

What I'm curious to see is how producers/post vendors respond. The usual refrain is fear of large data footprints and their attendant costs. Then there's the pushback on higher resolutions than required for the primary deliverables - why deal with 4K/6K/8K/12K for a 1080/2K master? Most RedUsers understand the power of oversampling/supersampling - particularly with CFA tech like Bayer - but for producers on the hunt for any way to shave costs...

Cheers - #19
 
With a different process to data wrangling between DSMC2 (now the dominant form) and Komodo/DSMC3, might it be possible or make sense to come out with a new version of firmware for DSMC2 that incorporates DCT recording as an option? This might be helpful in a mixed environment with DSMC2/Komodo/DSMC3 cameras all being able to be decoded with the same ease in post? Otherwise, the benefits of this in Komodo when used with several DSMC2 cams will be marginal until there is a complete switchover to DSMC3, which is going to be awhile. For those recording in DSMC2 at low compression, the hit to media will be modest, but perhaps this is not possible with the existing architecture?

And one more question: Phil says at the beginning of this thread, "And not to get too spicy, but yes, Apple has chosen a DCT scheme for their ProRes RAW". -- Could this mean that with this new compression method that this might be more easily implemented by the Apple Mac Pro's Afterburner card, which is optimized for ProRes RAW?" That would be sweet!
 
Last edited:
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
 
Excellent info and summary, Phil! And happy birthday! Even though I'm over a day late...
 
You must log in or register to reply here.
Back
Top