2011/8/25 Uoti Urpala <[email protected]> > > Not necessarily. If you upscale like that, smooth > > gradiants will not be perfectly smooth, anymore. > Gradients are perfectly smooth for a 8->16 conversion like > that. You seem to be assuming the special case of a 8->10 > conversion done by shifting out the lowest bits of the 16-bit > value again.
You're right. I was talking about converting 8bit up to less than 16bit. If you go to 16bit and stay there, gradients will stay smooth with byte duplication. However, swscale currently doesn't maintain smooth gradients if you go e.g. from 8bit to 10bit, because the 16bit -> 10bit reduction (after byte duplication) is done without dithering. > > Furthermore, the chroma channel needs to be scaled > > with signed math, to make sure that 8bit 128 gets properly > > scaled to 10bit 512. If you use (1), though, signed math > > is not necessary. > By "signed math" I assume you mean something like > C*(x-128)+512 instead of what you wrote in (2)/(3) (at > least that would be the most correct way - implementing > it does not actually require using signed arithmetic though). > But note that different chroma ranges actually have different > _shapes_ in the sense that the "neutral point" is a different > portion of the range away from the absolute middle of the > range (it's always +0.5 absolute units off from the middle, > but that's a smaller portion of the range for larger ranges). > No value of C in the above will produce exactly the full > dynamic range from 0 to 1023: if you make C large enough > to produce 1023 at the top end then the bottom will be > below 0 already. Not sure if I fully understood what you mean, but I'm pretty sure you're right. In any case, whatever swscale does, it needs to make sure that 8bit 128 is upscaled to 512. AFAIK, the current swscale code upscales that to 514 instead. Best regards, Mathias.
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
