Quote:
Originally Posted by Dogway
I checked the source code of zimg and Rec.1886 gamma function is listed but I couldn't see it as an option in either documentation:
http://avisynth.nl/index.php/Avsresize
http://www.vapoursynth.com/doc/functions/resize.html
As far as above documentation goes Rec.709 uses Rec.709 gamma, which is identical to Rec.2020 gamma for <12-bits (R-REC-BT.2020-2-201510). This is called Camera Gamma and it's not supposed to be used in authored content in either bitdepth. Rec.1886 gamma (in practice a pure power 2.4 gamma) is recommended as display gamma for Rec.709 (read EBU Tech 3320 v4.1 - 1.5.4). If what you mean is ITU-R BT.2390-2, that's for HDR not HBD. |
Have a look at
https://github.com/sekrit-twc/zimg/issues/111 and
https://github.com/sekrit-twc/zimg/i...ment-471823652
Here transfers -
https://github.com/sekrit-twc/zimg/b...pi/zimg.h#L302
"Rec.1886 gamma (in practice a pure power 2.4 gamma)" - in some cases could be the same as 2.4 gamma but Rec.1886 is not 2.4 gamma.
Quote:
Originally Posted by Dogway
About the shift, do you mean pixel shift? It's subsampling artifacts of upsampling and downsampling. Since ColorSpace() ( and WhitePoint() ) is doing a roundtrip in RC4 I hard coded it to PointResize() with a known fix for PointResize() pixel shift of -1.0. Hope it's fine now.
|
Right, pixel shift.
Quote:
Originally Posted by Dogway
Finally avsresize has an issue where I'm not able to use "fcc" for Matrix coefficients for Rec.601 primaries, as it should. Both PAL and NTSC in YCbCr use the coefficients derived from the FCC primaries. In avsresize these coefficients are not computed but constants with a precision of 3 decimal floats only.
|
What do you mean you're not able to use fcc matrix with 470bg primaries?
"In avsresize these coefficients are not computed but constants with a precision of 3 decimal floats only."
Can you show comparison where there is visual difference?