rick.lang wrote:Ellory, one of the people posting in that thread mentions it could still be RGB values with the offsets for a red and blue rather than the full red and blue values. That seems to make more sense than saying it’s Y’CrCb. After all DaVinci Resolve Colour Managed works in RGB space, no? I did notice that glow or ring but I’ve seen that before with green screens; just thought that it was normal but it sounds like it’s problematic.
I'm actually the one who posted that but I was really just kind of thinking out loud and showing my work lol
After thinking about it more, I realized why someone would go with Y'CbCr instead of Green with Red and Blue as offsets and it's because it's more consistent. With my idea, it would work fine a good portion of the time but it's too reliant on green which creates some major pitfalls if there's no green or if someone thing all green. Basically, in both situations the red and blue channels would not only require a bunch of precision but they would actually each need 13-bits instead of 12 in order to get enough contrast with the green channel. In other words a lot of the pixels in a picture of, for example, a magenta flower with leaves would be larger to store than if it was straight RGB values though, like I said in the original post, the desaturated, low-contrast nature of log footage would curb that issue quite a bit.
Your post made me think of something though. It does feel weird that a company that has a NLE known for it's color correction would make a camera and codec that requires going from RGB to Y'CbCr back to RGB and that made me think about what's happening at the sensor level and how the partial debayering fits into all this.
You see I'm trying to think about how to convert Bayer data into Y'CbCr data but the conversion from RGB to Y'CbCr requires combining data from all three RGB channels to Y, Cr, and Cb but since each bayer pixel only has one channel, it would require demosaicing. However, if it just held demosaiced data in the file then what part of the demosaicing work would be left for the decoder to do? The only other thing I could thinkin of is that they would demosaic just to convert to Y'CbCr and then discard pixels in each channel so you essentially have Y'CbCr version of the bayer pattern which would then be re-demosiaced (too many prefixes) by the decoder. That just sounds dumb though.
Previously I had theorized that the partial debayering happening in-camera was actually them doing all the gradient direction analysis on the image in-camera and then saving it as directional map in the file so that the decoder can take those values and complete the interpolation process software-side.
However after I've converted the CDNGs from that test into several different codecs and I do not see that issue in the ones that are RGB but every time I use one that's Y'CbCr, there's that artifacting. So it seems it is in fact Y'CbCr and maybe that extremely dumb sounding re-debayering idea is real.
Hendrik Proosa wrote:Wavelet case should be very easy to test though, compress CDNG file to Cineform raw and see what it looks like.
That was actually one of the codecs I converted it to and I saw the same ringing show up. For what it's worth, that ringing is actually present in the original CDNG file but to a much more subtle degree.
You can see it here.