Thread: Oops! BRAW isnt Raw Its a YCbCr codec

Page 2 of 15 FirstFirst 123412 ... LastLast
Results 11 to 20 of 148
  1. #11  
    Senior Member
    Join Date
    Jun 2012
    Posts
    168
    I'm looking at some other test footage. I don't know who shot it but it has a color chart, a mannequin bust with a red shirt, a laptop, and a TV playing chroma noise and I can't see the same ringing. Porter's footage appears to be lit brighter so maybe that has to do it and this footage doesn't have any areas with nearly as much contrast between red and green.

    Also what are the advantages, compression-wise or otherwise, of converting it to YCbCr? Edit: Actually now that I think about it I guess it would make two of the channels lower contrast and thus easier to compress.
    Last edited by Myownfriend; 09-20-2018 at 12:45 PM.
    Reply With Quote  
     

  2. #12  
    Junior Member
    Join Date
    Jan 2016
    Posts
    25
    Quote Originally Posted by Myownfriend View Post
    I'm looking at some other test footage. I don't know who shot it but it has a color chart, a mannequin bust with a red shirt, a laptop, and a TV playing chroma noise and I can't see the same ringing. Porter's footage appears to be lit brighter so maybe that has to do it and this footage doesn't have any areas with nearly as much contrast between red and green.

    Also what are the advantages, compression-wise or otherwise, of converting it to YCbCr? Edit: Actually now that I think about it I guess it would make two of the channels lower contrast and thus easier to compress.
    I think the main advantage is that you can easily reduce the resolution or compress the Cb and Cr channel without a big visual loss. That's the idea behind 422 and 420. I think most compressed codecs are YCbCr for this reason. It's interesting that CDNG 3:1 does still seem to be RGB. I guess CDNG only allows RGB and that switching to YCbCr with BRAW may have made some of these big improvements in compression possible for BMD.

    Maybe BRAW only switches to YCbCr after a specific compression ratio, say up to 5:1 it's RGB and then 8:1 and more is YCbCr.
    Last edited by weui; 09-20-2018 at 03:24 PM.
    Reply With Quote  
     

  3. #13  
    Senior Member
    Join Date
    Jun 2013
    Posts
    310
    Interesting. So would this recommendation hold for just green/blue screen FX work, or any situation where you'd need to key (like wanting to key an actor so you could place text "behind" them and the plate, for example)?
    Reply With Quote  
     

  4. #14  
    Senior Member
    Join Date
    Oct 2016
    Location
    Berlin
    Posts
    245
    Would be interesting to test:
    braw 3:1
    braw 5:1
    braw 8:1
    braw 12:1
    Reply With Quote  
     

  5. #15  
    Senior Member
    Join Date
    Sep 2012
    Posts
    159
    Quote Originally Posted by S_Berger View Post
    Would be interesting to test:
    braw 3:1
    braw 5:1
    braw 8:1
    braw 12:1
    Same result for all ratios. I only showed a few to keep the size of the post manageable.
    You can download the original clips and see for yourself.

    https://drive.google.com/drive/folde...jt2gDYI8H-n7PY
    Last edited by Ralph B; 09-20-2018 at 05:07 PM.
    Reply With Quote  
     

  6. #16  
    Senior Member
    Join Date
    Sep 2012
    Posts
    159
    Quote Originally Posted by TravisA View Post
    Interesting. So would this recommendation hold for just green/blue screen FX work, or any situation where you'd need to key (like wanting to key an actor so you could place text "behind" them and the plate, for example)?
    Not sure what other "situation" you're referring to.
    Reply With Quote  
     

  7. #17  
    Senior Member
    Join Date
    Jun 2012
    Posts
    168
    Quote Originally Posted by weui View Post
    Maybe BRAW only switches to YCbCr after a specific compression ratio, say up to 5:1 it's RGB and then 8:1 and more is YCbCr.
    Nah, the same ringing is present in 3:1 BRAW footage.

    In general I feel like it's more efficient to compress offsets between channels since the values between channels rarely vary by the full range, especially in a log image, and would decrease as they move towards pure black and pure white. What I don't get is why this requires a color space conversion considering it seems like it's more than possible to store RGB values like that. You would just have to store the greens of each bayer quartet as the actual values and the red and blue as offsets of each of the greens.

    Here's an example. I sampled 3 random skin tone, highlight, and shadow pixels in Photoshop and made bayer quartets out of a them with a second green that's just made to be similar to the first. This example is from an 8-bit image just to keep numbers smaller.

    First with direct RGB values
    RGB.png

    Here's what it would look like with offsets.

    offsets.png

    Now it might not seem super advantageous to compression until you look at just the chroma values alone

    comparison.png

    With the direct chroma values, they range from 5-8 bits of precision which is the kind of contrast in values you would expect between three mid-tone, shadow, and highlight pixels. But by just storing offsets, the values are in a much tighter range of just 0-6 bits and will have longer runs.

    But back to the topic at hand, the ringing almost feels like it's too thick to be from color space conversion especially since there's no chromo sub-sampling.
    Reply With Quote  
     

  8. #18  
    Member
    Join Date
    Nov 2014
    Location
    www.gigaboots.com
    Posts
    78
    So looking through those files myself, I see it too. The fine-grained sensor noise disappears. The chroma contrast problems look like some chroma subsampling issue. I'm kinda furious that BMD pulled the same bullshit trick that Apple did. This may be a great codec to film in but it's not RAW and that's what they said it was.
    My Gaming YouTube Channel: http://www.youtube.com/gigab00ts
    Reply With Quote  
     

  9. #19  
    Senior Member
    Join Date
    Aug 2014
    Posts
    2,105
    I hope they continue to keep CinemaDNG RAW on all their current and future cameras if this is the case.
    Reply With Quote  
     

  10. #20  
    Senior Member
    Join Date
    Mar 2015
    Location
    USA N. CA
    Posts
    3,140
    No surprises here, zbM has already stated this is BRAW, and part of the image processing, demosaicing was done in-camera to start the debayering of the image, so at rhe time of recording, the original RAW info has had some processing done to it before compression, and is thus no longer a true unprocessed RAW file. You can not have your cske and eat it too!
    Cheers
    Reply With Quote  
     

Similar Threads

  1. Braw pixel binning
    By polaroid22 in forum General Discussion
    Replies: 7
    Last Post: 09-19-2018, 02:27 AM
  2. The right codec
    By david evans in forum DaVinci Resolve
    Replies: 29
    Last Post: 05-08-2016, 05:25 AM
  3. Codec help!
    By Sherm in forum General Discussion
    Replies: 4
    Last Post: 08-03-2013, 11:59 AM
  4. Oops! Delete please.
    By Andrew in forum General Discussion
    Replies: 3
    Last Post: 11-29-2012, 03:05 AM
  5. 10 bit 4:4:4 DNxHD codec for BMC
    By andrew cheng in forum BMCuser News & Info
    Replies: 105
    Last Post: 06-19-2012, 05:07 AM
Bookmarks
Bookmarks
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •