Click here to go to the first RED TEAM post in this thread.   Thread: Komodo REDCODE RAW Explained

Reply to Thread
Page 3 of 8 FirstFirst 1234567 ... LastLast
Results 21 to 30 of 74
  1. #21  
    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.
    Reply With Quote  
     

  2. #22  
    Senior Member Blair S. Paulsen's Avatar
    Join Date
    Dec 2006
    Location
    San Diego, CA
    Posts
    5,388
    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
    Reply With Quote  
     

  3. #23  
    Senior Member
    Join Date
    Jan 2015
    Posts
    380
    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.)
    Reply With Quote  
     

  4. #24  
    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!
    Formerly known as "nutman"
    ||| RED ONE #1333 ||| Epic-X #1003 |||
    ||| RED Hydrogen Houdini #0034 Titanium #1014 |||
    H4Vuser
    Reply With Quote  
     

  5. #25  
    Senior Member Robert Hofmeyr's Avatar
    Join Date
    Sep 2009
    Location
    South Africa
    Posts
    906
    Quote Originally Posted by Jarred Land View Post
    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 :)
    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.
    Reply With Quote  
     

  6. #26  
    Quote Originally Posted by M Harvey View Post
    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.)
    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.)
    Scarlet-X #2034 "Bea"
    Reply With Quote  
     

  7.   Click here to go to the next RED TEAM post in this thread.
  #27  
    Happy Birthday Phil!!!
    www.red.com - 8k Digital Cinema Camera
    Science enables stories. Stories drive science
    IPP2, Image Processing, Colour Science and Demosaic Algorithms
    Reply With Quote  
     

  8. #28  
    Senior Member
    Join Date
    Jan 2015
    Posts
    380
    Quote Originally Posted by Christian Jadot View Post
    it is as compressed as it needs to be to get those extra frames.
    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...)
    Reply With Quote  
     

  9. #29  
    Senior Member
    Join Date
    Apr 2007
    Location
    NJ
    Posts
    709
    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
    If you love comic books please support the GoFundMe for
    Hy Eisman: A Life in Comics documentary


    www.britim-media.com
    IMDB
    Reply With Quote  
     

  10. #30  
    Member
    Join Date
    Oct 2011
    Location
    Sweden
    Posts
    33
    Quote Originally Posted by Jarred Land View Post
    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 :)
    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.
    Reply With Quote  
     

Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts