On Mon, Oct 27, 2014 at 10:02:25AM +0100, Nicolas George wrote: > Le sextidi 6 brumaire, an CCXXIII, arwa arif a écrit : > > I have done all the changes except rgb to yuv conversion. I will most > > probably do it by tonight. > > > + /*Convert RGB to Y'UV*/ > > + int y = r * .299000 + g * .587000 + b * .114000; > > + int u = r * -.168736 + g * -.331264 + b * .500000; > > + int v = r * .500000 + g * -.418688 + b * -.081312; > > + > > + /*Add HQx filters threshold & return*/ > > + return (y*48) + (u*7) + (v*6); > > A bit of maths would greatly help simplifying the code here. I am too lazy > to make the computations myself, so according to PARI/GP, just copy-pasting > your formulas (and trimming useless zeros from the output to make it more > readable): > > ? y = r * .299000 + g * .587000 + b * .114000; > ? u = r * -.168736 + g * -.331264 + b * .500000; > ? v = r * .500000 + g * -.418688 + b * -.081312; > ? (y*48) + (u*7) + (v*6) > %4 = 16.170848*r + (23.345024*g + 8.484128*b) > > Since your numbers are all integers in the [-255;+255] range and your > computations are made on 32-bits integers, scaling everything by a factor K > would work for K between roughly 256 and 170000. Using 65536 seems like a > good choice: > > return (1059773 * r + 1529939 * g + 556016 * b) >> 16; > > Of course, in this kind of case, a comment must be added to explain where > the numbers come from. >
The specs says it's the same algorithm as HQx, the code just needs to be refactored, the integer convertion is already written there. [...] -- Clément B.
pgpC2vKXplT5Q.pgp
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
