Gamma-aware, dithered colorspace conversion and resizing

[DTL]

Oh - it looks some hidden feature not clearly typed in old rec.601 standard but being non-significant at time of analog displays in PAL:

https://tech.ebu.ch/docs/techreview/...rec601_bbc.pdf
More satisfactory was the consideration of chrominance filtering which recognized the need for
sharp-cut filters at all conversions except the last one. This allowed the bandwidth needed for
chroma-key and other processing to be retained through the system; however, the inclusion of a
slow roll-off in the composite coder for analogue broadcasts or in the picture monitor for direct
component signals avoided the dreadful chrominance ringing that would otherwise occur.

So for the all production chain except final display YUV->RGB conversion the spectrum-limiting LPF need to be ideal (hard-cut off) and suppression of Gibbs-ringing at time of rec.601 system assumed to be at the end of chain in the Cb Cr (non-linear) data. I.e. 'digital' rec.601 system actually designed to be ended with 'analog' PAL coder with slow roll-off of UV filters inside valid frequencies. And only in this case the chrominance ringing will be fixed (mostly). For 'full-digital' chains it mean there must be 'conditioning' in OETFed domain filter in the display YUV->RGB conversion. It can be in simple form simulated with Blur() at UV channels. Though the exact filter responce looks like not standartized and lost in the past.
For the 'linearUV' functions above it means bool ColorFullBand param need always be 'false' and can be removed. But the final YUV(subsampled)->RGB transform for display or monitoring need to be checked for having non-sharp cut-off LPF at UV channels.

I update the Rec.601-based chroma subsampled system 'classic' drawing with 2 versions of decoder to RGB - the cascadable and 'final display/monitor' :
https://i2.imageban.ru/out/2021/09/1...aaaa704e86.png

And it looks for the tasks of scaling in linear domain the 'monitor'-type decoder must be used to restore RGB in least distorted form as possible.

[kedautinh12]

Last ver ResampleHQ is r385 if anyone care
https://svn.code.sf.net/p/int64/svn/resamplehq/

[DTL]

I made functions for testing:

LoadPlugin("ResampleMT.dll")
Function ConvertRGB24To422(clip c)
{
  yuv444=ConvertToYUV444(c)
  uc=UToY(yuv444)
  vc=VToY(yuv444)
  uc=SincLin2ResizeMT(uc, uc.width/2, uc.height, taps=16)
  vc=SincLin2ResizeMT(vc, vc.width/2, vc.height, taps=16)
  return CombinePlanes(yuv444, uc, vc, planes="YUV", source_planes="YYY", pixel_type="YV16")
}


Function Convert422ToRGB24(clip c)
{
  uc=UToY(c)
  vc=VToY(c)
  uc=SincLin2ResizeMT(uc, src_left=0.5, uc.width*2, uc.height, taps=16)
  vc=SincLin2ResizeMT(vc, src_left=0.5, vc.width*2, vc.height, taps=16)
  yuv444=CombinePlanes(c, uc, vc, planes="YUV", source_planes="YYY", pixel_type="YV24")
  return ConvertToRGB24(yuv444)
}

Function Convert422ToRGB24mon(clip c)
{
  uc=UToY(c)
  vc=VToY(c)
  uc=UserDefined2ResizeMT(uc,src_left=0.001,uc.width, uc.height, b=95, c=-10)
  vc=UserDefined2ResizeMT(vc,src_left=0.001,vc.width, vc.height, b=95, c=-10)
#  uc=UserDefined2ResizeMT(uc,src_left=0.001,uc.width, uc.height, b=80, c=-20)
#  vc=UserDefined2ResizeMT(vc,src_left=0.001,vc.width, vc.height, b=80, c=-20)
  uc=SincLin2ResizeMT(uc, src_left=0.5, uc.width*2, uc.height, taps=16)
  vc=SincLin2ResizeMT(vc, src_left=0.5, vc.width*2, vc.height, taps=16)
  yuv444=CombinePlanes(c, uc, vc, planes="YUV", source_planes="YYY", pixel_type="YV24")
  return ConvertToRGB24(yuv444)
}

Results really shows difference:


The build-in Avisynth functions ConvertToYUV422() and ConvertToRGB24() looks like designed to be 'average' between ringing and sharpness of transients. So when using built-in functions the difference is lower. But using that functions may cause more colour-sharpness degradation if using for mult-stage processing.

In the example above the UserDefined2ResizeMT() with (uc,src_left=0.001,uc.width,) params used to enable filter-processing (convolution with kernel) without actual resizing of UV channels. As filter with slow roll-off.
The adjustments of b and c params allow to adjust of colour-sharpness because exact required filter response looks like non standard-defined.

I not test yet but may be for speed 2 processings

  vc=UserDefined2ResizeMT(vc,src_left=0.001,vc.width, vc.height, b=95, c=-10)
  vc=SincLin2ResizeMT(vc, src_left=0.5, vc.width*2, vc.height, taps=16)

may be made at once like

vc=UserDefined2ResizeMT(vc,src_left=0.5,vc.width*2, vc.height, b=95, c=-10)

But it may possibly degrades quality a bit because of too small actual 'support' size of UserDefined2ResizeMT. Though it require testing.

[Balling]

LOL, @DTL did you get that from my document I left on the other thread? Cool.

P.S. This is insane if you really get 1 color only instead of crazy artifacts.

[DTL]

'instead of crazy artifacts'

As practice shows the current ITU-defined digital moving images colour systems are contain built-in bugs so no linear high-quality conversion from full-band 4:4:4 family members to subsampled 4:2:2 and 4:2:0 possible. The non-linear content-adaptive will give better quality but need to be designed.
Also it looks some normativing work need to put standard on response of antiringing filter of chroma datachannel in display decoder of subsampled family members. It possibly just started the long enough process.

[Svirito]

Originally Posted by kedautinh12

Last ver ResampleHQ is r385 if anyone care
https://svn.code.sf.net/p/int64/svn/resamplehq/

Does anyone have color_avx2.cpp ?

[tormento]

I have tried the x64 version found there

Originally Posted by Selur

there is also a 64bit dll: https://forum.doom9.org/showthread.p...00#post1722300

but it throws me a generic error. Perhaps an AVX2 only version? I need plain or AVX.

Anyone?