Announcement

Collapse
No announcement yet.

Oops! BRAW isnt Raw Its a YCbCr codec

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    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.

    Comment


    • #17
      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.

      Comment


      • #18
        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

        Comment


        • #19
          I hope they continue to keep CinemaDNG RAW on all their current and future cameras if this is the case.

          Comment


          • #20
            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

            Comment


            • #21
              Yea Denny, but that doesn't really necessitate a colorspace swivel to cause visual aberrations like this, so your aloof tone just makes you seem like you're unaware of the how unexpected this sort of thing was.
              My Gaming YouTube Channel: http://www.youtube.com/gigab00ts

              Comment


              • #22
                Originally posted by weui View Post
                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.
                YUV encoding was developed to reduce analog broadcast color bandwidth to fit within the same allotted 6MHz channel space as monochorme TV broadcasts. It takes about half the bandwidth of RGB. So even without subsampling it is more efficient.
                It is amazing to consider how far compressed digital codecs have developed since then. The RF broadcast signal has not changed significantly since NTSC was standardized. Yet in that same 6MHz channel space still running the same 3.5MHz line clock as NTSC analog broadcasts most stations now transmit a 1080i or 720p HD channel AND two standard def 720x480 channels or the equivalent in data services. Now with HEVC we can do 4k in the same space.
                Last edited by razz16mm; 09-20-2018, 11:20 PM.

                Comment


                • #23
                  Having shot and worked with BRAW since quite a while now, it highly doubt that it is Y’CbCr.

                  Wouldn't make any sense also.

                  One of the big advantages of a undebayered image is, that it is only black and white, so the data rate is way lower than a debayered image.
                  If you want to make a low data rate codec, why would you throw that advantage out of the window, and than counter it with loss of image information by even more compression? So you would ether raise the data rate with Y’CbCr (compared to a undebayered image), or asking for compression losses/artifacts.

                  That's nothing BM would develop as a new flagship codec, it's totally against their DNA as I know it.
                  Also we already have that since years, it's called ProRes and DNX - why make an other one?

                  I guess (out on a limb), gradient prediction, and denoising is done in camera (denoising is probably a necessary step to get efficient compression),
                  but the actual debayering (interpolation) is still done in Resolve.

                  And yes, I can see the ringing, but that could also be the compression, when they use a wavelet algorythm - I remember seeing that with Cineform raw almost a decade ago.
                  Last edited by Frank Glencairn; 09-21-2018, 01:51 AM.
                  Blog: http://frankglencairn.wordpress.com/

                  Comment


                  • #24
                    ^That makes a lot of sense. In any case, the bottom line is that you can get some color fringing artifacts when shooting BRAW that will be avoided when shooting cDNG. I think I'll use BRAW 6:1 most of the time, BRAW 12:1 for whenever I want to save storage space, and cDNG for green screen.
                    My YouTube channel

                    Comment


                    • #25
                      Even if it is wavelet-based compression causing it, the problems are showing up in the lossless q0 version. This is definitely doing something weird and degenerative to image quality.
                      My Gaming YouTube Channel: http://www.youtube.com/gigab00ts

                      Comment


                      • #26
                        Originally posted by Frank Glencairn View Post
                        I guess (out on a limb), gradient prediction, and denoising is done in camera (denoising is probably a necessary step to get efficient compression),
                        but the actual debayering (interpolation) is still done in Resolve.
                        That's exactly where I'm leaning towards when it comes to how the de-bayering process is split.

                        For what it's worth, after converting the CDNG's from that test to several different codecs, all the RGB ones produced no ringing while the Y'CbCr ones did. I don't know what other things, if any, are common between those codecs though.

                        Also there is a slight ringing in the CDNGs as well but it's very subtle by comparison.

                        Comment


                        • #27
                          If these are both supposed to be lossless then why is one quite obviously markedly worse than the other? It obviously has less detail and more imaging errors.

                          CDNG.JPGq0.JPG

                          Say what you will, but this isn't RAW. It's clearly doing some colorspace swivel or subsampling to cause this.
                          My Gaming YouTube Channel: http://www.youtube.com/gigab00ts

                          Comment


                          • #28
                            Would be nice to have some sort of BRAW whitepaper with some details.

                            Comment


                            • #29
                              Originally posted by Danji View Post
                              If these are both supposed to be lossless then why is one quite obviously markedly worse than the other? It obviously has less detail and more imaging errors.
                              Nobody ever said BRAW was lossless. Everybody knew it was lossy.

                              Comment


                              • #30
                                Originally posted by Myownfriend View Post
                                Nobody ever said BRAW was lossless. Everybody knew it was lossy.
                                Doesn't sound very raw to me, at that point.
                                My Gaming YouTube Channel: http://www.youtube.com/gigab00ts

                                Comment

                                Working...
                                X