Gamma-aware, dithered colorspace conversion and resizing

[DTL]

Some idea about less destructive conversion from linear RGB 4:4:4 typically in the main resampler path back to storage YUV 4:2:0 and decoding back to display linear 4:4:4 RGB.

It still not 100% compatible with recommended workflow of ITU recs like BT.601 and other because it recommend to low-pass and downsample CbCr (UV) data from R'G'B' data. This example uses for UV generation separated RGB linear path with half size of the RGB linear source. And UV is generated from downsampled RGB in linear form. Also backward upsampling of UV before final convertion to RGB output linear performed in linear form.
The most debatable point of this method is how to restore the best Y' data array in the space of UV data size of 4:2:0 color format at receiver's side. Because it is skipped at 4:2:0 dowconvertor stage and not delivered in final output 4:2:0 data array. Currently is it 2x downsampling of Y' data array from input 4:2:0 with SinPowResize method in its input form (without linearing, or other magic).


LoadPlugin("RawSourcePlus.dll")
LoadPlugin("ResampleMT.dll")
LoadPlugin("HDRTools.dll")

RawSourcePlus("out16.raw", 288,288, "Y16")

ConvertToRGB64(matrix="PC.709")

RGBAdjust(r=0.01,g=0.01) # make saturated color, comment out for no color

AddBorders(10,10,10,10,color=$101010)

# here current is 4:4:4 linear conditioned RGB source

rgb_lin_d2=SinPowResizeMT(width/2, height/2, p=2.9)

ConvertLinearRGBtoYUV(Color=4)
yuv_d2=ConvertLinearRGBtoYUV(rgb_lin_d2,Color=4)

yuv_old=ConvertToYUV420()

yuv420_new=CombinePlanes(yuv_old, yuv_d2, yuv_d2, planes="YUV", source_planes="YUV", pixel_type="YUV420P16")

#create receiver Y'/2 for backward dematrix
rsv_Ydash_div2=SinPowResizeMT(yuv420_new.ConvertToY(), yuv420_new.width/2, yuv420_new.height/2, p=2.9) # test or select Y'/2 resampler engine !

rsv_YUV_new_Y=CombinePlanes(rsv_Ydash_div2, yuv420_new, yuv420_new, planes="YUV", source_planes="YUV", pixel_type="YUV444P16")

rsv_RGB_linear_d2=ConvertYUVtoLinearRGB(rsv_YUV_new_Y,Color=4)

rsv_RGB_linear_x2=SincLin2ResizeMT(rsv_RGB_linear_d2,rsv_RGB_linear_d2.width*2, rsv_RGB_linear_d2.height*2, taps=16)

rsv_YUV_x2=ConvertLinearRGBtoYUV(rsv_RGB_linear_x2,Color=4)

rsv_return=CombinePlanes(yuv_old, rsv_YUV_x2, rsv_YUV_x2, planes="YUV", source_planes="YUV", pixel_type="YUV444P16")

ConvertYUVtoLinearRGB(rsv_return,Color=4)
#ConvertYUVtoLinearRGB(yuv420_new,Color=4)
#ConvertYUVtoLinearRGB(yuv_old,Color=4)

SincLin2ResizeMT(width*2, height*2, taps=32)

ConvertBits(8)


The source test pattern is hyperbolic zoneplate generated by https://github.com/DTL2020/hpzp tool with arguments hpzp.exe 268 20 0.02.

If processing no-color data (RGBAdjust(r=0.01,g=0.01) commented out) all ways return Y-only processed image without distortions. But if processing high-saturated colors with low Y-values like saturated blue there is the difference:

Standard Avisynth+ conversion from YUV 4:4:4 to 4:2:0 and playback to linear RGB:
https://i5.imageban.ru/out/2021/08/23/c2ebd5364c01bac0e8776bc250592bf1.png

Linear UV path method:
https://i3.imageban.ru/out/2021/08/23/2eace952fed3cb10d60045d6c4d333f2.png

Standard 4:2:0 to 4:4:4 decoding of linearly prepared UV:
https://i5.imageban.ru/out/2021/08/23/528673b7a5a8d60de42b8ddcc157ac93.png

[FranceBB]

you said that going for instance from 4:2:0 to Linear RGB and then back to 4:2:0 will affect the quality and this is true as we have an intermediate step to a non linear conversion for chroma as we're expanding it to 4:4:4 and then reducing it to 4:2:0 again.
This is correct.
However this is only 'cause when we apply such a conversion we're literally upscaling the chroma and it doesn't matter which resizing kernel / resampler we're gonna use (PoinResize / Nearest Neighborh, Bilinear, Bicubic, Lanczos, Spline etc) we're always gonna have a problem cause when we upscale the chroma we're gonna introduce blur and when we downscale it we're not gonna get rid of it, therefore going from yv12 to RGB and back to yv12 is not lossless.

So far so good, in the sense that we've been aware of this for ages and we haven't discovered anything new.

The question though is about what you're trying to do: I mean, theoretically speaking, wouldn't it be as easy as inverting the kernel used to upscale?

Let me rephrase: I'm pretty sure you're familiar with filters like DeBilinearResizeMT(), DeBicubicResizeMT() etc from Jean Philippe, right?
Those assume that a user knows the original dimensions of a source and the kernel used to upscale it and feeds the filter with them so that it's possible to perform not just a simple downscale using another silly interpolation, but rather inverting the kernel to get back exactly what the source was.
Now, with this in mind, wouldn't applying a resampling to go to 4:4:4 and RGB and then invert it solve the problem?

[DTL]

When we go from 4:2:0 OETFed to linear RGB 4:4:4 for resizing we can not use reversed-kernel aporoach to get undistorted 4:2:0 back. Because after RGB resize the samples are different in values and number. After resize the RGB array should be treated as fresh image source and the resizer output must provide RGB linear array free of aliasing and gibbs ringing to the encoder to 4:2:0.
The example of workflow in the provided script shows the possibility to have less aliasing distortions with typical distribution and storage format 4:2:0 and high enough saturated images. I not tested many available 'linear-light-resizers' yet if they also provide the way of process color-difference data in linear form. For example as I see ResampleHQ need RGB in gamma-corrected from as only available RGB input and I not sure if built-in Avisynth gamma adjust functions can simulate required gamma correction with enough precision.
Also the typical YUV-RGBlinear subsampled conversions for speed may use only one scaler and one matrix and one OETF/EOTF engine. And the provided example with linear UV process reqiure 2 matrices and 2 OETF and one scaler for encoder and 2 scalers and 3 matrices and 3 OETF/EOTF for decoder so it may not be very in common use in old days of slow hardware.

[DTL]

I made drawings of structural schematics of 2 different approaches for RGB to YUV 4:2:0 encoding and decoding:
Linear UV:
https://i7.imageban.ru/out/2021/08/23/edf9acfcf1214f73028372e89b8d16a3.jpg

And 'classic' with spectrum-limiting and downsampling in OETFed domain:
https://i1.imageban.ru/out/2021/08/23/a92995b8a07c04314bba9649a06dea87.jpg

" therefore going from yv12 to RGB and back to yv12 is not lossless."

If we do not scale Y plane (actual image) the conversion from 4:2:0 to 4:4:4 and back may be virtually lossles. But the downscaler in 4:4:4 to 4:2:0 must be hinted about spectral state of input 4:4:4 - do it full band (UV or RB) components (for example initial 4:4:4 full-band source) or half band (4:4:4 upconverted from 4:2:0).
Currently build-in Avisynth+ Convert() can get the chromaresample parameter but as I see can not get required arguments for kernel's adjustments and available kernels are only built-in.
For virtually lossless 4:2:0->4:4:4->4:2:0 (same size of Y planes and UV planes) we need sinc ideal LPF in scaler for both color planes in upsampler and downsampler.
For initial (production) 4:4:4->4:2:0 (really band-reduction operaion for UV) we need special spectrum shaping LPF for anti-gibbs processing like Gauss/SinPow/UserDefined and other kernels. It is not clear defined in ITU Recs but was published in separated ITU publications.
Also as I see the point of close to ideal LPF in chroma subsampled channels in ITU Recs - it helps to eliminate additional out of band components produced with scaling in non-linear domain. But if we prepare UV in linear domain it is not needed.

I will try to ask jpsdr to implement the linear UV scaling approach because it is based on already implemented functions in ResampleMT and HDRTools. In scriting form it make more non-needed calculations and in compiled binary functions may be significally faster.

[FranceBB]

Thanks for the clarification and the paper drawn schematics, they made your point much more clear.

Currently build-in Avisynth+ Convert() can get the chromaresample parameter but as I see can not get required arguments for kernel's adjustments and available kernels are only built-in.

Yep, only the built in kernels are supported and with no additional parameters, so that is actually limiting.
On the other hand, I think around 5% of the Doom9 population is actually even bothering to specify the kernel, but anyway I'm in favor of a full args support in the default built-in conversion, to be fair.


I will try to ask jpsdr to implement the linear UV scaling approach because it is based on already implemented functions in ResampleMT and HDRTools.

Nice. If he has time and he wants to, why not.

[DTL]

Well - at many real footages the difference may be very small. So currently make as a functions:


LoadPlugin("plugins_JPSDR.dll")
function YUV420P16ToLinearRGB_linUV(clip c, int ColorSystem)
{
Ydash_div2=SinPowResizeMT(c.ConvertToY(), c.width/2, c.height/2, p=2.7) # test or select Y'/2 resampler engine !
YUV_new_Y444=CombinePlanes(Ydash_div2, c, c, planes="YUV", source_planes="YUV", pixel_type="YUV444P16")
RGB_linear_div2=ConvertYUVtoLinearRGB(YUV_new_Y444,Color=ColorSystem)
RGB_linear_half_band=SincLin2ResizeMT(RGB_linear_div2,RGB_linear_div2.width*2, RGB_linear_div2.height*2, taps=8)
YUV_x2=ConvertLinearRGBtoYUV(RGB_linear_half_band,Color=ColorSystem)
to_out=CombinePlanes(c, YUV_x2, YUV_x2, planes="YUV", source_planes="YUV", pixel_type="YUV444P16")

return ConvertYUVtoLinearRGB(to_out,Color=ColorSystem)

}

function YUV422P16ToLinearRGB_linUV(clip c, int ColorSystem)
{
Ydash_div2=SinPowResizeMT(c.ConvertToY(), c.width/2, c.height, p=2.7) # test or select Y'/2 resampler engine !
YUV_new_Y444=CombinePlanes(Ydash_div2, c, c, planes="YUV", source_planes="YUV", pixel_type="YUV444P16")
RGB_linear_div2=ConvertYUVtoLinearRGB(YUV_new_Y444,Color=ColorSystem)
RGB_linear_half_band=SincLin2ResizeMT(RGB_linear_div2,RGB_linear_div2.width*2, RGB_linear_div2.height, taps=8)
YUV_x2=ConvertLinearRGBtoYUV(RGB_linear_half_band,Color=ColorSystem)
to_out=CombinePlanes(c, YUV_x2, YUV_x2, planes="YUV", source_planes="YUV", pixel_type="YUV444P16")

return ConvertYUVtoLinearRGB(to_out,Color=ColorSystem)

}


function LinearRGBToYUV420P16_linUV(clip c, int ColorSystem, bool ColorFullBand)
{
rgb_lin_div2 = ColorFullBand ? SinPowResizeMT(c, c.width/2, c.height/2, p=2.7) : SincLin2ResizeMT(c, c.width/2, c.height/2, taps=8)

yuv_d2=ConvertLinearRGBtoYUV(rgb_lin_div2,Color=ColorSystem)
y = ConvertLinearRGBtoYUV(c,Color=ColorSystem)

return CombinePlanes(y, yuv_d2, yuv_d2, planes="YUV", source_planes="YUV", pixel_type="YUV420P16")
}

function LinearRGBToYUV422P16_linUV(clip c, int ColorSystem, bool ColorFullBand)
{
rgb_lin_div2 = ColorFullBand ? SinPowResizeMT(c, c.width/2, c.height, p=2.7) : SincLin2ResizeMT(c, c.width/2, c.height, taps=8)

yuv_d2=ConvertLinearRGBtoYUV(rgb_lin_div2,Color=ColorSystem)
y = ConvertLinearRGBtoYUV(c,Color=ColorSystem)

return CombinePlanes(y, yuv_d2, yuv_d2, planes="YUV", source_planes="YUV", pixel_type="YUV422P16")
}


Params: ColorSystem = Color for ConvertLinearRGBToYUV and back in HDRTools, ColorFullBand = true for convert full band RGB to YUV subsampled and ColorFullBand = false for half-band color (for example YUV4xx->RGBlinear->YUV4xx). Currently made only for 16bits per component.

[jpsdr]

The linear part aside, there was here a long time ago a big talk about converting, the proper way to respect the chroma placement, summary is :

http://forum.doom9.org/showthread.php?t=170029
http://forum.doom9.org/showpost.php?p=1506374&postcount=385
http://forum.doom9.org/showpost.php?p=1705237&postcount=34

So here is a little recap.

1) When resizing in horizontally subsampled color spaces the standard resizers produce a slight horizontal chroma shift (see this post and following). To overcome this we can do the resize the manual way and apply the necessary shift to the chroma planes (U, and V) via the src_left argument of the resizer.

To prevent the shift when resizing in all horizontally subsampled color spaces (except 4:1:1!) src_left can be calculated as follows.

src_left = 0.25 * (1 - Width_in / Width_out)

Example resize from any horizontally subsampled color space (except 4:1:1!) to 704x576 YV12 (src_left is calculated automatically).

Code:

Y = ConvertToY8().Spline16Resize(704, 576)
U = UToY8().Spline16Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(Last))/Width(Y)))
V = VToY8().Spline16Resize(Width(Y)/2, Height(Y)/2, src_left=0.25*(1-Float(Width(Last))/Width(Y)))
YToUV(U, V, Y)

2) When resizing from a 4:2:0 or 4:2:2 subsampled color space to 4:4:4 (YV24) the shift for U and V is always constant.

src_left = 0.25

3) When resizing from 4:4:4 (YV24) to a horizontally subsampled color space (excluding 4:1:1!) the shift can be calculated as follows:

src_left = -0.50 * Width_in / Width_out

For an example with automatically calculated src_left see colours' post above.

Unless i'm wrong, which is possible because i'm not 100% sure with this case as you trick by downsamling Y, maybe somewhere your scripts miss the necessay adjustments. But the issue is that the Y/C adjustements can't be done on RGB ! So, this is something to think about, i think...
Example 4:2:0 -> 4:4:4 =>
Y=ConvertToY8(video)
U=UtoY8(video).BlackmanResizeMT(Width(Y),Height(Y),src_left=0.25,range=3)
V=VtoY8(video).BlackmanResizeMT(Width(Y),Height(Y),src_left=0.25,range=3)
YtoUV(U,V,Y)
Example 4:4:4 -> 4:2:0 =>
Y=ConvertToY8(video)
U=UtoY8(video).Spline36ResizeMT(Width(Y)/2,Height(Y)/2,src_left=-0.5,range=3)
V=VtoY8(video).Spline36ResizeMT(Width(Y)/2,Height(Y)/2,src_left=-0.5,range=3)
YtoUV(U,V,Y)

[jpsdr]

I think also there is another issue. If the encoder is made the "classic" way, the decoder has to be done the "classic" way too. You'll have wrong result if you decode according the "complex" way something encoded the "classic" way.
So, how do you know how the encoder was ?

[cretindesalpes]

Unless i'm wrong, which is possible because i'm not 100% sure with this case as you trick by downsamling Y, maybe somewhere your scripts miss the necessay adjustments. But the issue is that the Y/C adjustements can't be done on RGB ! So, this is something to think about, i think...
I can confirm that your src_left values are correct.

[DTL]

maybe somewhere your scripts miss the necessay adjustments.


Yes - may be. I still not test it about possible sub-sample chroma shift. It still the very early versions about this idea.


For backward upsampling I currently think it is not needed because half-color-band path upsampling performed in RGB. It may be wrong and require additional testing. May be the half-size Y' downsampling need additional sub-sample alignment.

"If the encoder is made the "classic" way, the decoder has to be done the "classic" way too."

Test results with hyperbolic zoneplate is (Avisynth+ ConvertToYUV420() used with default chromaresample that wiki says bicubic):

https://i7.imageban.ru/out/2021/08/24/debf851bc6f73791ec9f0625b57f8db5.png
https://i5.imageban.ru/out/2021/08/24/ae133c2a7e860e1d77a8d74d8031242e.png
https://i2.imageban.ru/out/2021/08/24/30b36a714770bea59beb3597e503cdd0.png

The use of new method with classic encoder still gives less aliasing in valid 4:2:0 color frequencies band but can not fix out of band aliasing passed via encoder. The power of aliasing in out-of-band frequencies is about the same with classic and new decoder.

"how do you know how the encoder was ?"

It is really very big and hard question for the current digital moving images industry. It still miss lots of required supplementary metadata about spatial properties of the content. It possibly need to go up to the ITU and may be many other standard organisations asking to add new metadata fields in the ISO MPEG (TS) and MP4 and other formats. Because as I see current world is filled with lots of digital content with not equal target renderer and current standards only partially cover the required supplementary metadata. Most of metadata relative to Fourier spectrum of data is missed.

I try to use new method on some TV broadcasting from BBC 2012 olympics and it cause significant ringing at CG content and also in vertical direction of interlaced broadcast video camera data. So it show the use of long sinc kernel resizers is not valid even for part of broadcast content and the H and V Fourier spectrums are not equally processed (conditioned). Even in 2012 broadcast interlaced HD1080 video cameras do not put correct anti-gibbs conditioning in V direction. Though for broadcast TV with CRT displays it looks never was critical.
So in current form of functions with SincLin2 upsamplers it moslty good only for progressive film content without unconditioned CG titling and with equally conditioned H and V directions. For other content may be it required to change upsamplers to something more poor but universal like down to Bicubic.

It is really exist some 'perfect motion pictures world' with rules for classic DSP with sinc-based resamplers and no aliasing and ringing and real much less perfect world of awful mix of image content with partial or no conditioned against gibbs ringing and aliasing present. And it not any marked with required metadata. One reason for the non-perfect ways is because they typically looks sharper at low pixel/sample count.

I tryed to change chromaresampler to sinc in avisynth+ ConvertToYUV420(chromaresample="sinc") and with new method of decoder and with used by HDRtools ConvertYUVToLinearRGB it still passes too many out of band frequencies and cause significant aliasing in out of band for 4:2:0 area: (attempt to ConvertToYUV444(,chromaresample="sinc") before HDRtools ConvertYUVToLinearRGB change almost nothing)

https://i2.imageban.ru/out/2021/08/24/82696d631f8f1fe8c65586693d41f7cc.png
With real low and medium saturated content it much less visible I think.
May be part source of this out of band aliasing is performing 4:2:0 downsampling with non-linear data. It is main point this idea about.
If skipping OETF transform (and backward) and assume out linear data as YUV 4:4:4 (adding Convert(RGB)to YUV444) classic Avisynth+ ConvertTo420 and back to 444 works better:
https://i7.imageban.ru/out/2021/08/24/f405dbf3b3e7fe7cd8d15499418f45a8.png
So performing down/upsampling of UV in non-linear domain is significant source of aliasing distortions (as expected).
OETF/EOTF operations are bitdepth compression/decompression (reversible without significant distortions) but performing spatial down/upscaling in this compressed form cause (irreversible ?) aliasing distortions.

Hyperbolic zoneplate (achromatic at least) is still official test pattern in EBU test patterns set for Tech 3320/3325 (monitors testing). So some hope still exist the digital motion pictures world still not completly falls in darkness. I not sure if color hyperbolic zoneplate will be included in new test patterns of updated Tech 3325 but if yes - it opens this new questions about 4:2:0 encoding and decoding (same for 4:2:2 for H direction only).

[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/trev_304-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/14/340ac9573c8ea5f1c93d14aaaa704e86.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:
https://i7.imageban.ru/out/2021/09/15/5d88cb415c7aa662e18b9b9e08e11a06.png

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]

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

there is also a 64bit dll: https://forum.doom9.org/showthread.php?p=1722300#post1722300

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

Anyone?