Gamma-aware, dithered colorspace conversion and resizing

[Boulder]

Does PAL SD use the same coefficients as HD?

[StvG]

Originally Posted by Boulder

Does PAL SD use the same coefficients as HD?

What do you mean?

[Boulder]

Originally Posted by StvG

What do you mean?

Would it be "709:709:709:limited=>rgb:linear:709:full" and vice versa when converting back?

[StvG]

Originally Posted by Boulder

Would it be "709:709:709:limited=>rgb:linear:709:full" and vice versa when converting back?

PAL SD is the same as SD NTSC from @Reel.Deel post. Matrix 470bg=170m. source_primaries=destination_primaries means no primaries change (x:x:2020=>y:y:2020 is the same as x:x:170m=>y:y:170m).

[joearmstrong]

Originally Posted by StvG

Yes, the syntax is correct.
"approximate_gamma=false" will dramatically decrease the speed and probably doesn't worth it.
For UHD scaling if there is no chromaloc property, chromaloc_op="top_left=>top_left" should be added to both lines.

Scaling in linear light could easily lead to increased/created haloing. The chance is very high using spline36.

Which resize filter is more suitable for this operation?

[StvG]

Originally Posted by joearmstrong

Which resize filter is more suitable for this operation?

That depends on the source (sharp, blurred) and the scaling ratio. Kernels that don't overshoot.

Here an example - https://imgbox.com/g/9E2Wj5Mm7r

# first image
FFVideoSource(1080p)
Crop(0, 130, -0, -130)
z_ConvertFormat(pixel_type="RGBPS", colorspace_op="709:709:470bg:limited=>rgb:linear:470bg:full", resample_filter="spline36", approximate_gamma=false)
z_ConvertFormat(width=854, height=364, pixel_type="YUV420P8", colorspace_op="rgb:linear:470bg:full=>709:709:470bg:limited", resample_filter="spline36", approximate_gamma=false)

# second image
FFVideoSource(1080p)
Crop(0, 130, -0, -130)
z_ConvertFormat(pixel_type="RGBPS", colorspace_op="709:709:470bg:limited=>rgb:linear:470bg:full", filter_param_a=-0.6, filter_param_b=0, approximate_gamma=false)
z_ConvertFormat(width=854, height=364, pixel_type="YUV420P8", colorspace_op="rgb:linear:470bg:full=>709:709:470bg:limited", filter_param_a=-0.6, filter_param_b=0, approximate_gamma=false)

Third image is the source.

[Reel.Deel]

Originally Posted by StvG

PAL SD is the same as SD NTSC from @Reel.Deel post. Matrix 470bg=170m. source_primaries=destination_primaries means no primaries change (x:x:2020=>y:y:2020 is the same as x:x:170m=>y:y:170m).

From my understanding SD NTSC and SD PAL use different primaries. For the following lets assume we are converting to linear light RGB as per post #239.

SD NTSC:

colorspace_op="470bg:601:170m:limited=>rgb:linear:170m:full"

SD PAL:

colorspace_op="470bg:601:470bg:limited=>rgb:linear:470bg:full"

Jpeg:

colorspace_op="601:601:470bg:full=>rgb:linear:470bg:full"

Jpeg conversion also needs chromaloc_op="center=>center" unless it's already YUV444.

[StvG]

Originally Posted by Reel.Deel

From my understanding SD NTSC and SD PAL use different primaries. For the following lets assume we are converting to linear light RGB as per post #239.

Originally Posted by StvG

PAL SD is the same as SD NTSC from @Reel.Deel post. Matrix 470bg=170m. source_primaries=destination_primaries means no primaries change (x:x:2020=>y:y:2020 is the same as x:x:170m=>y:y:170m).

z_ConvertFormat(pixel_type="RGBPS", colorspace_op="470bg:601:170m:limited=>rgb:linear:170m:full", resample_filter="spline36", approximate_gamma=false)
z_ConvertFormat(width=320, height=240, pixel_type="YUV420P16", colorspace_op="rgb:linear:170m:full=>470bg:601:170m:limited", resample_filter="spline36", approximate_gamma=false)

z_ConvertFormat(pixel_type="RGBPS", colorspace_op="470bg:601:470bg:limited=>rgb:linear:470bg:full", resample_filter="spline36", approximate_gamma=false)
z_ConvertFormat(width=320, height=240, pixel_type="YUV420P16", colorspace_op="rgb:linear:470bg:full=>470bg:601:470bg:limited", resample_filter="spline36", approximate_gamma=false)

z_ConvertFormat(pixel_type="RGBPS", colorspace_op="470bg:601:2020:limited=>rgb:linear:2020:full", resample_filter="spline36", approximate_gamma=false)
z_ConvertFormat(width=320, height=240, pixel_type="YUV420P16", colorspace_op="rgb:linear:2020:full=>470bg:601:2020:limited", resample_filter="spline36", approximate_gamma=false)

z_ConvertFormat(pixel_type="RGBPS", colorspace_op="470bg:601=>rgb:linear", resample_filter="spline36", approximate_gamma=false)
z_ConvertFormat(width=320, height=240, pixel_type="YUV420P16", colorspace_op="rgb:linear=>470bg:601", resample_filter="spline36", approximate_gamma=false)

z_ConvertFormat(pixel_type="RGBPS", colorspace_op="470bg:601:709:limited=>rgb:linear:709:full", resample_filter="spline36", approximate_gamma=false)
z_ConvertFormat(width=320, height=240, pixel_type="YUV420P16", colorspace_op="rgb:linear:709:full=>470bg:601:709:limited", resample_filter="spline36", approximate_gamma=false)

All above codes give the same result.

[Reel.Deel]

Originally Posted by StvG

All above codes give the same result.

I see what you mean now. Still a bit confusing to use 2020 primaries for a DVD source

I'll add the examples on the wiki similar to post #239.

[DTL]

About quality with processing in linear RGB but typically using Y'U'V' 4:2:0 for storage and broadcast/release.
The idea of perform resample in linear itself do not have issues. But to make linear RGB for resampling we need to resample U'V' from 4:2:0 to Y'U'V' 4:4:4 first. And this resampling will have U'V' channels damaged a bit because I think it is impossible to have data to be conditioned against Gibbs ringing in both linear and system non-linear form at once. I still do not have math ideas how to solve this issue without going in non-linear data processing. So we have nice workflow for Y channel but still need to go into non-linear nightmare when living with subsampled chroma channels in Y'U'V' 4:2:0. The distortions are not very great but for perfectionists may still be. Simple bilinear or even worse point resize for 4:4:4<->4:2:0 conversions are not perfect and long sinc-based can not be used because of non-linearly distorted Y'U'V' data for process.

Resizing of Y'U'V' 4:2:0 with linear-RGB stage is practically long and sad procedure of:
Y'U'V' 4:2:0 -> resample U'V' in non-linear -> Y'U'V' 4:4:4 -> R'G'B' 4:4:4 -> RGB -> resample RGB in linear -> R'G'B' 4:4:4 -> Y'U'V' 4:4:4 -> resample U'V' in non-linear -> Y'U'V' 4:2:0.
With 2 stages of upsample and downsample of UV in non-linear form.

[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:


Linear UV path method:


Standard 4:2:0 to 4:4:4 decoding of linearly prepared UV:

[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:


And 'classic' with spectrum-limiting and downsampling in OETFed domain:


" 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.

Originally Posted by DTL

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?...&postcount=385
http://forum.doom9.org/showpost.php?...7&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]

Originally Posted by jpsdr

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]

Originally Posted by jpsdr

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):





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)


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:

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).