пн, 9 сент. 2024 г., 23:19 Andrew Randrianasulu <randrianas...@gmail.com>:
> > > пн, 9 сент. 2024 г., 23:04 Andrew Randrianasulu <randrianas...@gmail.com>: > >> >> >> пн, 9 сент. 2024 г., 18:06 Andrew Randrianasulu <randrianas...@gmail.com >> >: >> >>> Looking at libswscale/swscale.c (due to >>> https://trac.ffmpeg.org/ticket/11182#comment:5) I do not understand >>> how it works :) >>> >>> why shits to 11 and to 12 ? >>> >>> // FIXME all pal and rgb srcFormats could do this conversion as well >>> // FIXME all scalers more complex than bilinear could do half of this >>> transform >>> static void chrRangeToJpeg_c(int16_t *dstU, int16_t *dstV, int width) >>> { >>> int i; >>> for (i = 0; i < width; i++) { >>> dstU[i] = (FFMIN(dstU[i], 30775) * 4663 - 9289992) >> 12; // -264 >>> dstV[i] = (FFMIN(dstV[i], 30775) * 4663 - 9289992) >> 12; // -264 >>> } >>> } >>> >>> static void chrRangeFromJpeg_c(int16_t *dstU, int16_t *dstV, int width) >>> { >>> int i; >>> for (i = 0; i < width; i++) { >>> dstU[i] = (dstU[i] * 1799 + 4081085) >> 11; // 1469 >>> dstV[i] = (dstV[i] * 1799 + 4081085) >> 11; // 1469 >>> } >>> } >>> >>> === >>> can anyone knowledgeable write/add some more comments in code ? please >>> :) >>> >> >> >> it seems that same code (under slightly different name) was living in >> swscale_template.c since at least 2009 ... >> >> >> >> https://git.ffmpeg.org/gitweb/ffmpeg.git/blobdiff/c1977fbbd7d1e7825010e301fa236e910b760aab..bae76dc3eb6e5cd07f5881092d375ddc0270f693:/libswscale/swscale_template.c >> > > > and it was commited in 2008: > > > https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/6bc0c7928a386d5cf99c198ec1b795aff6bf7656 > > Fix jpeg yuv. > > author Michael Niedermayer <michae...@gmx.at> > Mon, 8 Sep 2008 15:36:38 +0300 (12:36 +0000) > committer Michael Niedermayer <michae...@gmx.at> > Mon, 8 Sep 2008 15:36:38 +0300 (12:36 +0000) > commit 6bc0c7928a386d5cf99c198ec1b795aff6bf7656 > tree a90c126c5d92e65bfe4ad9dac24473eaae8464ed tree > parent f7b1d72f45c97f3fc57632a0a23d01cee51c4a4e commit | diff > > Fix jpeg yuv. > Fixes issue504. > > Originally committed as revision 27547 to svn:// > svn.mplayerhq.hu/mplayer/trunk/libswscale > > hm, but this does not make it less opaque for me ;) > so, libwebp source code comments hint that it was 16:16 fixed point representation for yuv-rgb matrix coefficients https://github.com/leapmotion/FreeImage/blob/master/Source/LibWebP/src/dsp/yuv.h ==== // This JPEG-YUV colorspace, only for comparison! // These are also 16bit precision coefficients from Rec.601, but with full // [0..255] output range. static WEBP_INLINE int VP8RGBToY(int r, int g, int b, int rounding) { const int luma = 19595 * r + 38470 * g + 7471 * b; return (luma + rounding) >> YUV_FIX; // no need to clip } static WEBP_INLINE int VP8RGBToU(int r, int g, int b, int rounding) { const int u = -11058 * r - 21710 * g + 32768 * b; return VP8ClipUV(u, rounding); } static WEBP_INLINE int VP8RGBToV(int r, int g, int b, int rounding) { const int v = 32768 * r - 27439 * g - 5329 * b; return VP8ClipUV(v, rounding); } === and same file includes 14bit constants for arm cpus ... amazing, just need to know how to convert fp64 to fixedpoint .... https://embeddedartistry.com/blog/2018/07/12/simple-fixed-point-conversion-in-c/ it uses round() from libc (?) also on vogons https://www.vogons.org/viewtopic.php?t=100401 but ffmpeg's function probably uses some matrix math because color converter is fused with scaler? also I found few routines in libquicktime and mjpegtools. > I guess it was working for all those years .. mostly? > > >> >> _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
