Gamma-aware, dithered colorspace conversion and resizing

[infoeater]

Sorry for delay and thank you for your explanations Asmodian.

So ResampleHQ ignore (small) gamma differences between BT.709 and sRGB and use sRBG coefficients and gamma for its internal linear colorspace?

High-end consumer video cameras (~1000 USD) often offer really very good calibration to BT.709. In fact it's often only limited by color accuracy of the sensor and cannot be improved in automatic postprocessing. There are some tests at http://www.camcorderinfo.com/. Consumer TV's on the other hand offer usually poor calibration (because many customers like oversaturated colors and cold (high Kelvin) white point), which can be improved, manually by calibration in higher models.

Canon PowerShot SD950 IS use BT.601 for its videos.

Panasonic and Sony consumer camcorders offer "http://en.wikipedia.org/wiki/XvYCC" as an option, which can be disabled in menu.
It is compatible with BT.709, just allows values out of range that define extra colors. It is possible to disable it, because normally camera tries to convert such colors to colors in range, allowing better perceived color accuracy on displays not supporting xvYCC.

BTW I am interested how ResampleHQ will handle out of range xvYCC colors when resizing TV.709 to TV.709? Will it lose them somewhere in it's internal color space?

[Asmodian]

Yes, ResampleHQ uses sRGB gamma for its linear color space but I am sure it would be impossible to tell the difference after converting back.

I believe all color space conversions done in Avisynth, including ResampleHQ's, use "absolute" color conversions. Any out of range colors are clamped to the nearest valid color. However ResamplesHQ's internal color space is in 32-bit float and any clamping occurs at the final conversion to TV.709.

It is good to know cameras actually try for accurate colors. I wonder if/when Windows will ever be gamut aware. The thumbnail generator in Windows 7 is color space aware, a photo tagged as anything but sRGB is converted to sRGB, but not the rest of the OS and it cannot use a calibrated color space instead of sRGB. This means wide gamut displays are bad, not just useless, for anything but a Mac or Photoshop type work. I also really hate all the "fluid motion" features and similar that new TVs have but they cannot get the color even close to correct. Why are all the new Android tablets and phones using 60% of sRGB's gamut and a 7500K+ white point?! What is the point of a 1920x1200 10" screen if not image quality?

Sorry about the rant, I couldn't stop myself. :o

[active1]

how could i know that my image is linear and i need a gamma-correction?

[Asmodian]

Images are never in linear light, they all have a gamma curve (I am sure there are formats which use linear light, but no consumer ones do). At 8 bits per sample linear light is a bad idea as there aren't enough steps in the black/dark grey and too many in the almost white. It is good ResampleHQ uses 32bits for its linear color space. Using linear light when resizing to a smaller resolution allows for a more "optically correct" resize but you never leave the image in linear light for display.

ResampleHQ is not for doing gamma conversions, just resizing.

[active1]

Images are never in linear light, they all have a gamma curve (I am sure there are formats which use linear light, but no consumer ones do). At 8 bits per sample linear light is a bad idea as there aren't enough steps in the black/dark grey and too many in the almost white. It is good ResampleHQ uses 32bits for its linear color space. Using linear light when resizing to a smaller resolution allows for a more "optically correct" resize but you never leave the image in linear light for display.

so when i need to do gamma-correction?
plus i tried ResampleHQ on different images, and i didn't see much different from the other avisynth resizers, but in the earth light image (which is included with resamplehq-x86.dll) the difference was clear

[ajp_anton]

When you have small bright spots or thin lines with sharp high contrast edges, "normal" resizers tend to lower that contrast a bit.


Say the resizer needs to average a bright spot with intensity 1 with a dark background with intensity 0.
"Normal" resizers will simply average this to 0.5, which becomes the new brightness of this bright spot.
Obviously it should get darker when you downsize, but not this much.

Converting to linear light (value^2.2): both 1 and 0 stay as they are. Average = 0.5.
Inverting the previous conversion on this value: 0.5^(1/2.2) = 0.73, which is brighter than 0.5, and is what your eyes would actually see in the real world.

The gamma-curved representation of pixel light intensities doesn't represent actual light intensity, so averaging pixels here doesn't give correct results. It does however work as a good enough approximation in most real-life scenarios.

[Asmodian]

so when i need to do gamma-correction?

Only when wanting to view content on a display with a different gamma than intended but that isn't related to ResampleHQ.

[TheElix]

Is this script meant for real-time usage (for watching videos with)?

[Asmodian]

This isn't a script, just a plugin, but it is fast enough to run real time. I am not sure why you would though, MadVR offers linear-light options for resizing at playback.

Also resizing in linear light is most important when resizing to a smaller resolution which is (I assume) rarely done at playback.

[pancserzso]

Hi,

I'm trying to import a AVCHD file using ffms2 from a Panasonic GH2 camera, which is 4:2:0. I'm looking for the best possible quality. Can you help me which of these are the best?

Is there any point using this plugin when there is no resolution resize, just chroma YV12 -> RGB conversion and Chroma upsample?

Color conversion by FFVideoSource:

FFVideoSource( "mts.mts", seekmode = -1, colorspace = "RGB24", resizer = "LANCZOS" )

Color conversion by AviSynth 2.60:

FFVideoSource( "mts.mts", seekmode = -1 )
ConvertToRGB24( matrix = "Rec709", chromaresample = "lanczos" )

Color conversion by ResampleHQ:

FFVideoSource( "mts.mts", seekmode = -1 )
ResampleHQ( dstcolorspace = "RGB24", srcmatrix = "TV.709", kernel = "lanczos" )

[pbristow]

pancserzso: You need to ask your question in the usage forum, not the development one. Also, open a fresh thread rather than tacking it onto an existing one. That will help you by bringing your question to the attention of more people, and will avoid irritating/confusing people who come to *this* thread looking for info about the stated topic. ("Gamma-aware, dithered colorspace conversion and resizing")

Good luck! :)

[EDIT: OK, Perhaps I'm being too hasty. Your question *does* have to do with the ResampleHQ plugin, after all. But it is more of a usage question than a development one.

Maybe I should just shut up and let someone else talk. :o ]

[pancserzso]

pancserzso: You need to ask your question in the usage forum, not the development one. Also, open a fresh thread rather than tacking it onto an existing one. That will help you by bringing your question to the attention of more people, and will avoid irritating/confusing people who come to *this* thread looking for info about the stated topic. ("Gamma-aware, dithered colorspace conversion and resizing")

Good luck! :)

[EDIT: OK, Perhaps I'm being too hasty. Your question *does* have to do with the ResampleHQ plugin, after all. But it is more of a usage question than a development one.

Maybe I should just shut up and let someone else talk. :o ]

I especially want to ask in in the ResampleHQ thread, since I believe this is the place where the developer and experts of ResampleHQ are. Also, this is the official forum linked in the ResampleHQ docs, I believe I can ask this question here.

So, I think ResampleHQ gives me the highest quality, I just want to hear some expert opinion on:
1. Whether there is any point using ResampleHQ only for chroma upsampling when doing color space conversion as well.
2. What kernel is recommended for the highest quality 4:2:0 -> RGB conversion + chroma upsampling, if the image dimensions don't change?

[Asmodian]

I think this is an ok place to ask about ResampleHQ, development seems to be done so it can/has turned into more of a support thread. :)

I would say it is fine to use ResampleHQ for converting to RGB but U and V do not use gamma so the "gamma-aware" doesn't help in this case. However, as ResampleHQ does the conversion in 32‐bit floating‐point and dithers to R'G'B', I do not believe another option would provide higher quality.

I don't think the normal Avisynth ConverttoRGB() uses dithering. Note that FS dithering (like that used by ResampleHQ) tends to get lost when doing a lossy compression (H.264) unless using very high bit rates.

I like Catmull-Rom, Blackman3, Blackman4, or Spline36 depending on ringing vs sharpness but I have never done or seen any good testing of the kernel choice for YUV 4:2:0 to RGB outside of MadVR. For MadVR the the consensus seems to be Jinc3 or bicubic75 but there are fewer choices in MadVR and ResampleHQ doesn't offer Jinc. I am sure that all choices have tradeoffs. I would think Blackman3 would be good, sharper than some but also low ringing and not blurring. Catmull-Rom (bicubic b=0.0, c=0.5) or bicubic75 (b=0.0, c=0.75 - sharper with more ringing) would also be good choices.

If you have chroma artifacts in the source a little blurring might be good so you could use Mitchell-Netravali or Robidoux.

Sorry, I know I have suggested half the kernels but I don't think there is a right answer for kernel choice. I wouldn't go too ringing and I don't like the stronger blurring of Softcubic unless the chroma is in a bad state.

note: 4:2:0 -> RGB includes chroma upsampling by definition. You cannot have subsampled color with RGB. ;)

edit:
If/when you do pick a kernel please let us know which one.

[pancserzso]

I think this is an ok place to ask about ResampleHQ, development seems to be done so it can/has turned into more of a support thread. :)

I would say it is fine to use ResampleHQ for converting to RGB but U and V do not use gamma so the "gamma-aware" doesn't help in this case. However, as ResampleHQ does the conversion in 32‐bit floating‐point and dithers to R'G'B', I do not believe another option would provide higher quality.

I don't think the normal Avisynth ConverttoRGB() uses dithering. Note that FS dithering (like that used by ResampleHQ) tends to get lost when doing a lossy compression (H.264) unless using very high bit rates.

I like Catmull-Rom, Blackman3, Blackman4, or Spline36 depending on ringing vs sharpness but I have never done or seen any good testing of the kernel choice for YUV 4:2:0 to RGB outside of MadVR. For MadVR the the consensus seems to be Jinc3 or bicubic75 but there are fewer choices in MadVR and ResampleHQ doesn't offer Jinc. I am sure that all choices have tradeoffs. I would think Blackman3 would be good, sharper than some but also low ringing and not blurring. Catmull-Rom (bicubic b=0.0, c=0.5) or bicubic75 (b=0.0, c=0.75 - sharper with more ringing) would also be good choices.

If you have chroma artifacts in the source a little blurring might be good so you could use Mitchell-Netravali or Robidoux.

Sorry, I know I have suggested half the kernels but I don't think there is a right answer for kernel choice. I wouldn't go too ringing and I don't like the stronger blurring of Softcubic unless the chroma is in a bad state.

note: 4:2:0 -> RGB includes chroma upsampling by definition. You cannot have subsampled color with RGB. ;)

edit:
If/when you do pick a kernel please let us know which one.

Thanks a lot! I've compared it a bit more, and I'm confident in using ResampleHQ for the task.

Some results I've found out:
using dither gave me no visual difference (I seriously cannot see the effect on my source), while it slows down the script extremely. In my case it was 3.7 fps vs. 22 fps with dither = false

for the normal kernel, I've played around and for downsampling 1920x1080 -> 1280x720, I concluded that:
- Lanczos is too sharp / ringy for my liking
- The best filter for my liking was Mitchell

for the chroma kernel, the honest conclusion was:
- there is almost no difference visible at least on my soft real-camera source
- the only exception is SoftCubic, which is actually visibly too soft on red lights, like LEDs
- the PNG file sizes go like this:
softbicubic, bicubic = mitchell, catmull, lanczos

I think I'll choose mitchell here as well.

ResampleHQ( width = 1280, height = 720, dstcolorspace = "RGB24", srcmatrix = "TV.709", kernel = "MitchellNetravali", chroma_kernel = "MitchellNetravali" )

[creaothceann]

using dither gave me no visual difference (I seriously cannot see the effect on my source)

Watch for color banding.

01 (http://bakashots.me/guide/index.php?prob=band&num=1)
02 (http://bakashots.me/guide/index.php?prob=band&num=2)
03 (http://bakashots.me/guide/index.php?prob=band&num=3)

(pictures change upon mouseover)

[IanB]

Image links are all "Forbidden"

[Sparktank]

That's strange. They work for me.
Country-dependent access? :erm:

[pancserzso]

Thanks for the samples. My source is my own Panasonic GH2 camera, which cannot make such perfect smooth gradient like on the images you've linked, but I might try taking a video of the sky or sunset or something which is like that. On normal, everyday scenes, it didn't happen.

[astronob]

I can't get this filter to work with cinema craft encodersp3. I get a small black mpv file with the words in red on top "Unknown ResampleHQ Internal Error" Any suggestions?

[Asmodian]

please :script:

[astronob]

Hi Asmodian,

here's my little avisynth script. I can get this to work with CCE 2.5, but CCE SP3 won't work, nor will Tmpgenc with it. I need to go RGB to use the Virtualdub DeLogo plugin with Avisynth, then back to YUY2 for avisynth to use ResampleHQ. Also a question. One person said that the Dither plugin gave a sharper output to ResampleHQ. Is this so? I'd like to try it and compare encodes with it. What would be an equivalent Dither script I could use, if someone could suggest one? Thanks.

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\DGDecode.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\ColorMatrix.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\NicAudio.dll")
mpeg2source("O:\The Runaways - School Days (RAGE SD).d2v", info=3)
converttorgb32()
LoadVirtualDubPlugin("C:\VirtualDubMod_1_5_10_2_All_inclusive\plugins\delogo.vdf", "delogo")
delogo(1,"","C:/Delogo/Mask Files/Deblend.bmp", "C:/Delogo/Mask Files/Alpha.bmp", "c:/Delogo/Mask Files/Color.bmp", "C:/Delogo/Mask Files/Repair.bmp", 15, 40, 1, 0)
crop(98,2,-94,-0)
ResampleHQ(width=720, height=576, dstcolorspace="YUY2", srcmatrix="TV.601", kernel="spline36", chroma_kernel="spline36")
ConvertToYUY2

[Asmodian]

You are going back to YUY2 after ResampleHQ but that is ok as ResampleHQ supports RGB color spaces.

Maybe the one person who thought Dither is sharper was in the context of YV12 or YUY2? Dither is "sharper" than ResampleHQ because dithering is not currently supported for YV12 and YUY2 in ResampleHQ. Dithering is mostly destroyed by DCT compression.

Here is an example Dither script to implement a ResampleHQ like resize. Like with ResampleHQ I suggest you only use liner light resize when downsampling.
Dither_convert_8_to_16()
Dither_y_gamma_to_linear()
Dither_resize16(1280, 720)
Dither_y_linear_to_gamma()
DitherPost()

If you want an anti-ringing algorithem applied you can replace Dither_resize16 with Dither_resize16nr. There are good examples in the Dither docs.

[astronob]

Thanks, but putting "dither" in the script, gives me "DitherPost: Input Must Be Planar." I have no idea what that means. Also, can someone PLEASE explain why ResampleHQ won't work with Tmpgenc but works fine with old version of cinema craft encoder? When I try and frameserve the script to Tmpgenc, I get a line in red letters "ResampleHQ Internal Error:". The latest version of CCE won't work either. I'm at a loss. Is there something extra I need to put in the script so Tmpgenc will work? Thanks. Also, I don't think ResampleHQ supports RGB color space. If I put "RGB" instead of "YUY2" in the script. It won't work. Has ResampleHQ been updated to work with RGB color space now? Thanks.

[cretindesalpes]

Thanks, but putting "dither" in the script, gives me "DitherPost: Input Must Be Planar." I have no idea what that means.
YUY2 is not a planar colorspace, Y, U and V components are interleaved and packed in pairs of pixels. You can convert first your clip with ConvertToYV16(), which is the same as YUY2 but in a planar form.

[astronob]

Doesn't work, colors are stuffed up. In addition, no one has offered an explanation for the "ResampleHQ Internal Error" error message.

[Richard1485]

I received that error only when I used Avisynth MT. The normal Avisynth has always been fine. My two cents!

[De-M-oN]

Please integrate YV24 support.

[l33tmeatwad]

This projected seems to be dormant since 2011, but there was a newer source code posted and since version 8 did not include a 64-bit plugin I decided to build it. I can't promise it will be stable as it was never released by the creator, but it does appear to be working. I included a compile of the x86 version too, but I would trust version 8 over this one.

Download (http://www.mediafire.com/download/4m31za3np4o5d24)

[burfadel]

This projected seems to be dormant since 2011, but there was a newer source code posted and since version 8 did not include a 64-bit plugin I decided to build it. I can't promise it will be stable as it was never released by the creator, but it does appear to be working. I included a compile of the x86 version too, but I would trust version 8 over this one.

Download (http://www.mediafire.com/download/4m31za3np4o5d24)

It's unfortunate development hasn't continued on it. The plugin seems to produce a subtle, but nice, improvement over the standard spline filters.

[De-M-oN]

Spline100 has the best compressability which is awesome for youtube.

Also I like the ringing free scaling by Spline100 in general :)


edit: oh I thought it was the SplineResize Thread instead of ResampleHQ. sorry.

edit 2: But I can add something to this thread as well:

The documentation of ResampleHQ says youtube uses tv.601

But thats wrong. They use tv.709.

[Treaties Of Warp]

BUMP!!!

Is there any way to add Spline100 and Spline144 to ResampleHQ?

[Upscale_Lover]

Any way to downscale 4k SDR content to 720p using ResampleHQ? What is the source matrix value for 4k?

[DTL]

Any way to downscale 4k SDR content to 720p using ResampleHQ? What is the source matrix value for 4k?

Possibly that plugin https://forum.doom9.org/showthread.php?p=1843107#post1843107 will helps with SDR too.

With
ConvertYUVtoLinearRGB()
Do_resample()
ConvertLinearRGBtoYUV()

"What is the source matrix value for 4k?"

It depends on content source. May be any of 601/709/2020 for SDR. Try to look in metadata if available.

[joearmstrong]

Since v2.1.0 ResampleHQ supports HDR sources in Vapoursynth. Unfortunately there's no update for the Avisynth version. Someone should compile a new version for Avisynth from the latest Vapoursynth release.

[Reel.Deel]

Since v2.1.0 ResampleHQ supports HDR sources in Vapoursynth. Unfortunately there's no update for the Avisynth version. Someone should compile a new version for Avisynth from the latest Vapoursynth release.

ResampleHQ for VapourSynth is a script using core filters to convert to linear light and resize. It's not a plugin like the AviSynth version. Regardless, the same can be accomplished with avsresize. Take a look at the ">8bit (AVIsynth+) linear/gamma light aware resizing? (https://forum.doom9.org/showthread.php?t=175428)" thread.

[joearmstrong]

I confused something. Thanks for the explanation. What is the correct script for HDR gamma-aware resize?

My Idea:
z_ConvertFormat(pixel_type="RGBPS",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:l",resample_filter="spline36",resample_filter_uv="spline36",approximate_gamma=false)
Spline36Resize(1920,1080)
z_ConvertFormat(pixel_type="YUV422P10",colorspace_op="rgb:linear:2020:l=>2020ncl:st2084:2020:l",resample_filter="spline36",resample_filter_uv="spline36",approximate_gamma=false)

[Boulder]

I think the HDRTools plugin makes it even easier.

z_ConvertFormat(chromaloc_op="top_left=>mpeg2")
ConvertYUVtoLinearRGB(color=1, outputmode=2)
Spline36Resize(1920,1080)
ConvertLinearRGBtoYUV(color=1, outputmode=2)
z_ConvertFormat(chromaloc_op="mpeg2=>top_left")

It should return a 16-bit YV12 clip you can feed to the encoder. I think the chroma location should also be changed before and after resizing because the standard resizer does not use the UHD one.

[StvG]

I confused something. Thanks for the explanation. What is the correct script for HDR gamma-aware resize?

My Idea:
z_ConvertFormat(pixel_type="RGBPS",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:l",resample_filter="spline36",resample_filter_uv="spline36",approximate_gamma=false)
Spline36Resize(1920,1080)
z_ConvertFormat(pixel_type="YUV422P10",colorspace_op="rgb:linear:2020:l=>2020ncl:st2084:2020:l",resample_filter="spline36",resample_filter_uv="spline36",approximate_gamma=false)

Here version with removed redundant stuff:z_ConvertFormat(pixel_type="RGBPS",colorspace_op="2020ncl:st2084=>rgb:linear",resample_filter="spline36",approximate_gamma=false)
z_ConvertFormat(1920,1080,pixel_type="YUV422P10",colorspace_op="rgb:linear=>2020ncl:st2084",resample_filter="spline36",approximate_gamma=false)

[Reel.Deel]

Here version with removed redundant stuff:

z_ConvertFormat(pixel_type="RGBPS",colorspace_op="2020ncl:st2084=>rgb:linear",resample_filter="spline36",approximate_gamma=false)
z_ConvertFormat(1920,1080,pixel_type="YUV422P10",colorspace_op="rgb:linear=>2020ncl:st2084",resample_filter="spline36",approximate_gamma=false)


I want to add some linear light downscaling examples to the wiki:


For 1080p HD (Rec709) content:
z_ConvertFormat(pixel_type="RGBPS", colorspace_op="709:709:709:limited=>rgb:linear:709:full", resample_filter="spline36", approximate_gamma=false)
z_ConvertFormat(width=1280, height=720, pixel_type="YUV420P16", colorspace_op="rgb:linear:709:full=>709:709:709:limited", resample_filter="spline36", approximate_gamma=false)

And if for some reason you wanted to resize SD NTSC content:
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)

And regular RGB content:
z_ConvertFormat(pixel_type="RGBPS", colorspace_op="rgb:srgb:709:full=>rgb:linear:709:full", resample_filter="spline36", approximate_gamma=false)
z_ConvertFormat(width=1280, height=720, pixel_type="RGBP16", colorspace_op="rgb:linear:709:full=>rgb:srgb:709:full", resample_filter="spline36", approximate_gamma=false)


Is that the correct way of doing it?

[StvG]

Is that the correct way of doing it?

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.

[Boulder]

Does PAL SD use the same coefficients as HD?

[StvG]

Does PAL SD use the same coefficients as HD?

What do you mean?

[Boulder]

What do you mean?

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

[StvG]

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]

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]

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]

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 (https://forum.doom9.org/showthread.php?p=1948131#post1948131).

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]

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 (https://forum.doom9.org/showthread.php?p=1948131#post1948131).

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]

All above codes give the same result.
source_primaries=destination_primaries means no primaries change (x:x:2020=>y:y:2020 is the same as x:x:170m=>y:y:170m).

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

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.