Click here to go to the first RED TEAM post in this thread.   Thread: Apple + RED

Reply to Thread
Page 10 of 10 FirstFirst ... 678910
Results 91 to 97 of 97
  1. #91  
    RED has a number of different patents, but two of the key ones are Patent No. 9,245,314 (https://patents.google.com/patent/US9245314B2/en) which covers a camera recording RAW using lossy compression and Patent No. 9,230,299 (https://patents.google.com/patent/US9230299B2/en) which covers a camera recording lossless compressed RAW using Huffman encoding.

    Patents usually include several sections, including Background, Summary of Inventions, Diagrams, and Claims. The most important section of any patent is the Claims section; that is the section that actually describes what is protected by the patent. The other sections (like the background, summary, etc.) are really just to provide context for the Claims, the Claims are what matter in determining what a patent actually covers.

    So in the case of the RED patents, the mention of possible compression ratios like 6:1, 12:1, etc. are generally included as examples in the Background or Summary sections. The Claims section does not mention specific compression ratios at all, and as a result, Patent No. 9,245,314 covers any form of lossy compressed RAW recording in-camera, regardless of the compression ratio used. The patent is pretty broad from that standpoint.

    The lossless compressed RAW patent (No. 9,230,299) also does not mention compression ratios in the Claims section, but it does mention a specific lossless compression technique (Huffman encoding). So this makes the scope of the lossless compressed RAW patent a little narrower than the lossy compressed RAW patent. Huffman encoding is one of the simpler and more popular lossless compression techniques and is the one used for lossless compression in the original DNG 1.0 specification. But it's certainly not the only viable approach. The original lossless JPEG standard included arithmetic encoding as an alternative to Huffman encoding and JPEG-LS (a later lossless JPEG standard) used the LOCO-I algorithm (based on Golomb coding). JPEG-LS delivers slightly better compression ratios for image data than Huffman encoding, but with faster compression times than arithmetic encoding. PNG images use yet another lossless compression approach, which is based on the Lempel-Ziv algorithm (specifically DEFLATE) which is also used in the compression of ZIP files. Version 1.4 of the DNG specification also added support for ZIP-based compression of RAW files.

    In theory, I believe that any of these non-Huffman based lossless compression approaches could be used without infringing on RED's lossless compressed patent No. 9,230,299 (or at least the part of it that deals with compression anyway). Note that many of the image-specific lossless compression techniques were intended more for RGB image data so it's possible they would perform differently on RAW image data. The DEFLATE algorithm used in ZIP was designed as a more general purpose lossless compression technique, but it tends to be a bit less efficient on image data than some of the other approaches.

    The downside of any of form of lossless compression, is that it tends to be somewhat limited in terms of its compression ratio. While the actual ratio can vary based on the content being compressed, for most image data, lossless compression tends to be in the range of 1.5:1 to 3:1. Since the compression ratio is not constant, this also means that there isn't really a strong guarantee on the maximum data rate with lossless compression (although it can't exceed the uncompressed rate). In some cases, lossless compression may not reduce the file size at all (as anyone that has put a ZIP file inside of another ZIP file can attest to). With real world image data though it's pretty rare to encounter this kind of uncompressible edge case.

    From a video recording perspective using lossless compression means that file sizes may vary somewhat, and that faster guaranteed write speeds are needed on the recording medium to handle this. With lossy compression, it is easier to hit specific compression ratio targets and constrain the data rate into a particular range (so that you can determine how fast the storage media needs to be, and how many minutes of video will fit in a given amount of storage space). But obviously with lossy compression you do run the risk of adding compression artifacts, which is impossible with lossless compression.

    I don't think I have come across any definitive technical description of Canon's Cinema RAW Light format, but given that it has compression ratios up to 5:1 it doesn't seem possible that this is a truly lossless format (as that would be significantly better than the best lossless compression techniques currently known for image data). Additionally the data rate for Cinema RAW Light stays constant (1 Gbps) over a wide range of different frame rates (24 to 60 fps) and color depths (10-bit/12-bit) which means that Canon varies the compression ratio depending on what is being recorded (from a low of about 2.4:1 for 24 fps video up to 5:1 for 60 fps footage). Setting specific compression ratio targets like this generally isn't possible with lossless codecs.
    Reply With Quote  
     

  2. #92  
    Senior Member Bob Gundu's Avatar
    Join Date
    Mar 2011
    Location
    Toronto, ON Canada
    Posts
    9,856
    I believe Reds patent also states “internal recording” which means other companies have gotten around the patent by using an external recorder.
    ___________________________

    VFX, Cinematographer, Photographer
    10 frame handles
    Vimeo
    Instagram
    Reply With Quote  
     

  3. #93  
    Senior Member
    Join Date
    Jun 2017
    Posts
    1,662
    Quote Originally Posted by Dave Del Vecchio View Post
    I don't think I have come across any definitive technical description of Canon's Cinema RAW Light format, but given that it has compression ratios up to 5:1 it doesn't seem possible that this is a truly lossless format (as that would be significantly better than the best lossless compression techniques currently known for image data). Additionally the data rate for Cinema RAW Light stays constant (1 Gbps) over a wide range of different frame rates (24 to 60 fps) and color depths (10-bit/12-bit) which means that Canon varies the compression ratio depending on what is being recorded (from a low of about 2.4:1 for 24 fps video up to 5:1 for 60 fps footage). Setting specific compression ratio targets like this generally isn't possible with lossless codecs.
    REDCodeRAW, Canon RAW Lite and ProResRAW are not lossless. All commen raw format's (except X-OCN) are logged from a bit depth to a lower bit depth hence not lossless.
    Who determines what visually lossless is (some old fart with bad eye sight working at the patent office or a pixel peeper working at a movie studio with all the equimpment in the world to help him/her).
    Reply With Quote  
     

  4. #94  
    Senior Member Terry VerHaar's Avatar
    Join Date
    Sep 2009
    Location
    Marin County, CA
    Posts
    6,987
    Quote Originally Posted by Dave Del Vecchio View Post
    RED has a number of different patents, but two of the key ones are Patent No. 9,245,314 (https://patents.google.com/patent/US9245314B2/en) which covers a camera recording RAW using lossy compression and Patent No. 9,230,299 (https://patents.google.com/patent/US9230299B2/en) which covers a camera recording lossless compressed RAW using Huffman encoding.

    Patents usually include several sections, including Background, Summary of Inventions, Diagrams, and Claims. The most important section of any patent is the Claims section; that is the section that actually describes what is protected by the patent. The other sections (like the background, summary, etc.) are really just to provide context for the Claims, the Claims are what matter in determining what a patent actually covers.

    So in the case of the RED patents, the mention of possible compression ratios like 6:1, 12:1, etc. are generally included as examples in the Background or Summary sections. The Claims section does not mention specific compression ratios at all, and as a result, Patent No. 9,245,314 covers any form of lossy compressed RAW recording in-camera, regardless of the compression ratio used. The patent is pretty broad from that standpoint.

    The lossless compressed RAW patent (No. 9,230,299) also does not mention compression ratios in the Claims section, but it does mention a specific lossless compression technique (Huffman encoding). So this makes the scope of the lossless compressed RAW patent a little narrower than the lossy compressed RAW patent. Huffman encoding is one of the simpler and more popular lossless compression techniques and is the one used for lossless compression in the original DNG 1.0 specification. But it's certainly not the only viable approach. The original lossless JPEG standard included arithmetic encoding as an alternative to Huffman encoding and JPEG-LS (a later lossless JPEG standard) used the LOCO-I algorithm (based on Golomb coding). JPEG-LS delivers slightly better compression ratios for image data than Huffman encoding, but with faster compression times than arithmetic encoding. PNG images use yet another lossless compression approach, which is based on the Lempel-Ziv algorithm (specifically DEFLATE) which is also used in the compression of ZIP files. Version 1.4 of the DNG specification also added support for ZIP-based compression of RAW files.

    In theory, I believe that any of these non-Huffman based lossless compression approaches could be used without infringing on RED's lossless compressed patent No. 9,230,299 (or at least the part of it that deals with compression anyway). Note that many of the image-specific lossless compression techniques were intended more for RGB image data so it's possible they would perform differently on RAW image data. The DEFLATE algorithm used in ZIP was designed as a more general purpose lossless compression technique, but it tends to be a bit less efficient on image data than some of the other approaches.

    The downside of any of form of lossless compression, is that it tends to be somewhat limited in terms of its compression ratio. While the actual ratio can vary based on the content being compressed, for most image data, lossless compression tends to be in the range of 1.5:1 to 3:1. Since the compression ratio is not constant, this also means that there isn't really a strong guarantee on the maximum data rate with lossless compression (although it can't exceed the uncompressed rate). In some cases, lossless compression may not reduce the file size at all (as anyone that has put a ZIP file inside of another ZIP file can attest to). With real world image data though it's pretty rare to encounter this kind of uncompressible edge case.

    From a video recording perspective using lossless compression means that file sizes may vary somewhat, and that faster guaranteed write speeds are needed on the recording medium to handle this. With lossy compression, it is easier to hit specific compression ratio targets and constrain the data rate into a particular range (so that you can determine how fast the storage media needs to be, and how many minutes of video will fit in a given amount of storage space). But obviously with lossy compression you do run the risk of adding compression artifacts, which is impossible with lossless compression.

    I don't think I have come across any definitive technical description of Canon's Cinema RAW Light format, but given that it has compression ratios up to 5:1 it doesn't seem possible that this is a truly lossless format (as that would be significantly better than the best lossless compression techniques currently known for image data). Additionally the data rate for Cinema RAW Light stays constant (1 Gbps) over a wide range of different frame rates (24 to 60 fps) and color depths (10-bit/12-bit) which means that Canon varies the compression ratio depending on what is being recorded (from a low of about 2.4:1 for 24 fps video up to 5:1 for 60 fps footage). Setting specific compression ratio targets like this generally isn't possible with lossless codecs.
    Thanks so much for chiming in with the very helpful and informative commentary. It's the first time in this thread that I have a sense someone does actually understand this topic!
    Scarlet Dragon
    Scarlet-W
    Reply With Quote  
     

  5. #95  
    Senior Member
    Join Date
    Apr 2008
    Location
    New York City
    Posts
    244
    Can't wait for OS X Redcine-X to get Metal acceleration.
    Reply With Quote  
     

  6. #96  
    Junior Member
    Join Date
    Oct 2016
    Location
    France
    Posts
    2
    Quote Originally Posted by Antony Newman View Post
    I wonder if this means the Apple accelerate framework will be optimised for R3D playback on all Apple devices?
    Would be really great to have better R3D playback on older Mac (thinking trashcan, maybe even last gen 5.1 MacPro with a graphic card that can supports Metal)

    Quote Originally Posted by Jarred Land View Post
    RED integration with Apple’s METAL framework for realtime R3D playback is coming along well and the work that the two teams are doing together is exceeding expectations. We are very excited for the new Mac Pro and the new XDR pro display and the power they bring to the entire RED workflow.
    Quote Originally Posted by Jarred Land View Post
    Not yet :)
    Thumbs up to the RED & Apple team for making R3D workflow on Mac better !
    Joey Lacroix - Foundation Pictures
    Epic-W Helium 8K S35 #283
    Reply With Quote  
     

  7. #97  
    Senior Member
    Join Date
    Jan 2012
    Location
    Portland, OR
    Posts
    121
    Right...should we be reading that previous gen Apple computers with sufficient GPU power and Metal support will see R3D performance increases along with the newest MacPro?
    Last edited by Andy Maser; 11-19-2019 at 04:10 PM.
    andymaser.com
    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