z.lib resizers for AviSynth+

[real.finder]

I asked here https://forum.doom9.org/showpost.php...1&postcount=69

z_ConvertFormat(colorspace_op="470bg:470bg:470bg:limited=>709:709:709:limited",dither_type="ordered")

give dark output, is this normal or it bug?

[poisondeathray]

Originally Posted by real.finder

I asked here https://forum.doom9.org/showpost.php...1&postcount=69

z_ConvertFormat(colorspace_op="470bg:470bg:470bg:limited=>709:709:709:limited",dither_type="ordered")

give dark output, is this normal or it bug?

Expected result

The original colormatrix() only changes the matrix, nothing else.

You are are telling avsresize to change matrix, transfer and primaries

[real.finder]

Originally Posted by poisondeathray

Expected result

The original colormatrix() only changes the matrix, nothing else.

You are are telling avsresize to change matrix, transfer and primaries

so z_ConvertFormat should be better, right?

but it's not as fast as colormatrix, is it because colormatrix only change matrix?

[poisondeathray]

Originally Posted by real.finder

so z_ConvertFormat should be better, right?

"better" in what way?

For HD/SD , the standard of practice is actually to only change matrix . (Not for UHD). For matrix, 470bg and 170m have the same value (SD, 601) . 709 does not

Transfer function value is the same for 601/709 .

Primaries are slightly different between 601/709 .

The list is in the h265 document . Table E4.

But you check with other programs, resolve, premiere , dozens of others, only matrix is ever adjusted. The colors will be slightly shifted in media players, other programs, hardware, displays, AV equipment if you adjust for the primaries - even though it's technically more correct

but it's not as fast as colormatrix, is it because colormatrix only change matrix?

I don't know why one is faster

Quality wise colormatrix can produce more pronounced banding artifacts under some conditions. It's more visible in cartoons and anime .

[real.finder]

Originally Posted by poisondeathray

"better" in what way?

For HD/SD , the standard of practice is actually to only change matrix . (Not for UHD). For matrix, 470bg and 170m have the same value (SD, 601) . 709 does not

Transfer function value is the same for 601/709 .

Primaries are slightly different between 601/709 .

The list is in the h265 document . Table E4.

But you check with other programs, resolve, premiere , dozens of others, only matrix is ever adjusted. The colors will be slightly shifted in media players, other programs, hardware, displays, AV equipment if you adjust for the primaries - even though it's technically more correct





I don't know why one is faster

Quality wise colormatrix can produce more pronounced banding artifacts under some conditions. It's more visible in cartoons and anime .

I mean better for HD <-> SD convert

also I know colormatrix can produce more pronounced banding artifacts since it 8bit

I did post another time there https://forum.doom9.org/showthread.p...76#post1905976

z_ConvertFormat(colorspace_op="470bg:601:170m:limited=>709:709:709:limited",dither_type="ordered")

seems fine but aside from matrix how one know for sure the color info in DVD? or if I cap from VHS

and aside from that, can we have update for avsresize? https://forum.doom9.org/showthread.p...49#post1906749

and since the documentation is kinda shortened, is avsresize has all Dither_resize16/fmtconv features like kernel inversion mode and additional Kernels?

[poisondeathray]

Originally Posted by real.finder

also I know colormatrix can produce more pronounced banding artifacts since it 8bit

It's not just an 8bit thing; there are some weird noise patterns enhanced by colormatrix on some anime. If you check by disable dithering and use 8bit with zimg, it's still more pronounced with colormatrix . Haven't seen the issue on live action content , it's probably hidden by natural noise and grain

z_ConvertFormat(colorspace_op="470bg:601:170m:limited=>709:709:709:limited",dither_type="ordered")

seems fine but aside from matrix how one know for sure the color info in DVD? or if I cap from VHS

No way to know for sure.

If you assume the colors are correct on the DVD in the first place, you're asking the wrong question. You should be asking what method is your viewing hardware or software using to convert back to RGB for display ? ie. is it using something like ConvertToRGB24(matrix="rec709") ? Because that accounts for matrix only . If you adjust for primaries the colors will be shifted for the HD version when viewing on that hardware or software

I would only adjust matrix, unless you knew primaries were adjusted and the SD image is wrong in the first place

I would always use full=>full . I thought it was a no-op limited=>limited, but it makes a difference on the brightest
and darkest pixels if you look closely . Detectable with metrics too

and aside from that, can we have update for avsresize? https://forum.doom9.org/showthread.p...49#post1906749

I would like update too, but I don't know how to compile it

and since the documentation is kinda shortened, is avsresize has all Dither_resize16/fmtconv features like kernel inversion mode and additional Kernels?

No ; and available kernels are only the common ones and they are listed in the readme

[pinterf]

zimg integration is on my roadmap but not in the very near future

[StvG]

Here update (zimg@5896a26). Added few things (cpu_type, nominal_luminance, approximate_gamma, alpha plane). Check readme for more info.

[MeteorRain]

Originally Posted by real.finder

seems fine but aside from matrix how one know for sure the color info in DVD? or if I cap from VHS

Some DVD mastering company can't even resize the image correctly (like SAR and over scan stuff). Some staff probably don't even have the skills that we have. God knows how they converted the colors.

[pinterf]

Originally Posted by StvG

Here update (zimg@5896a26). Added few things (cpu_type, nominal_luminance, approximate_gamma, alpha plane). Check readme for more info.

Thanks. Do you have a github link (also for addgrain stuff), it's hard to follow the changes (and to give you the proper credits on a re-use).

[poisondeathray]

Originally Posted by StvG

Here update (zimg@5896a26). Added few things (cpu_type, nominal_luminance, approximate_gamma, alpha plane). Check readme for more info.

thanks for the update

[Reel.Deel]

Originally Posted by StvG

Here update (zimg@5896a26). Added few things (cpu_type, nominal_luminance, approximate_gamma, alpha plane). Check readme for more info.

Thank you for the update StvG!

Not long ago I added documentation to the wiki: http://avisynth.nl/index.php/Avsresize

I'll will update the documentation with the things that were added.
I see that compatibility aliases "gauss", "lanczos4", "blackman", "sinc" were removed. And also z_BlackmanResize(), z_GaussResize(), z_SincResize() are gone. I know these essentially did nothing since they are just aliases, will they be gone forever?

[Stereodude]

Originally Posted by Reel.Deel

Thank you for the update StvG!

Not long ago I added documentation to the wiki: http://avisynth.nl/index.php/Avsresize

I'll will update the documentation with the things that were added.
I see that compatibility aliases "gauss", "lanczos4", "blackman", "sinc" were removed. And also z_BlackmanResize(), z_GaussResize(), z_SincResize() are gone. I know these essentially did nothing since they are just aliases, will they be gone forever?

It would be nice if you could list the terminology of all the allowed color formats in the wiki or if the plug-in aligned its accepted naming with Avisynth+'s terms. It will not accept some of the names used by AVIsynth+.

Like using RGBP8 gives you a bad pixel type error. It looks like it wants RGBP, not RGBP8.

[StainlessS]

The affected ones look to all have entries in the Remarks column. [ RGBP vs RGBP8, on wiki:- http://avisynth.nl/index.php/Avisynthplus_color_formats ]
Oops, wrong link, FIXED.

[StvG]

Originally Posted by pinterf

Thanks. Do you have a github link (also for addgrain stuff), it's hard to follow the changes (and to give you the proper credits on a re-use).

Sorry, I don't have any github links.

Originally Posted by Reel.Deel

Thank you for the update StvG!

Not long ago I added documentation to the wiki: http://avisynth.nl/index.php/Avsresize

I'll will update the documentation with the things that were added.
I see that compatibility aliases "gauss", "lanczos4", "blackman", "sinc" were removed. And also z_BlackmanResize(), z_GaussResize(), z_SincResize() are gone. I know these essentially did nothing since they are just aliases, will they be gone forever?

IMO, yes, they are gone "forever" unless zimg adds support for them. For example I had a version compiled without spline64 too (spline64 was spline32 alias) but when zimg added spline64, I added back spline64.

Btw on the wiki page chromaloc_op "top_left" is missing.

[FranceBB]

Originally Posted by MeteorRain

Some staff probably don't even have the skills that we have. God knows how they converted the colors.

You mean morons who don't know how to do these things?
They do it via hardware, mostly.
The reason? They have little to no clue about what they're doing as they're just operators that someone put there and they don't know how to code or use pseudo-scripting softwares like Avisynth, BUT they strictly follow a procedure that someone not too incompetent put in place several years ago back when there was no software at all.
It generally involves a play port (like the Omneon ones), a resizing hardware converter (Evertz and similar), a Softel/Cavena for subtitles and either a DVD itself or a Rec Port.
They generally put the colorbars, then the file, then black at the end, then they route the signal from the playback port to the converter and from the converter to the Softel or Cavena which "plays" the subtitles according to the timecode read from the SDI port and it places it in the inactive lines of the stream while playing and from there to either the DVD itself or to a Rec Port which records the file that is going to be mastered to the DVD.

Stone age at its best as it could be easily done in a fraction of the time with Avisynth or literally anything that isn't from decades ago, but I've seen it with my eyes and years ago I was one of the people who had to do it this way (i.e I was forced to do it this way) because of "sacred procedures"... -.-

[Reel.Deel]

Originally Posted by StvG

IMO, yes, they are gone "forever" unless zimg adds support for them. For example I had a version compiled without spline64 too (spline64 was spline32 alias) but when zimg added spline64, I added back spline64.

Btw on the wiki page chromaloc_op "top_left" is missing.

I've updated the wiki to match these changes and added chromaloc_op "top_left"

[Reel.Deel]

Originally Posted by Stereodude

It would be nice if you could list the terminology of all the allowed color formats in the wiki or if the plug-in aligned its accepted naming with Avisynth+'s terms. It will not accept some of the names used by AVIsynth+.

Like using RGBP8 gives you a bad pixel type error. It looks like it wants RGBP, not RGBP8.

Done: http://avisynth.nl/index.php/Avsresize#z_ConvertFormat

-----

@StvG

Any thoughts on adding YUV420P8, YUVA420P8, YUV422P8, YUVA42AP8, YUV444P8, YUVA444P8, RGBP8, RGBAP8 aliases?

[StvG]

Here r1e:
- zimg@8815111;
- added pixel type RGBP8, RGBAP8, YUV444, YUV444P8, YUVA444P8, YUV422, YUV422P8, YUVA422P8, YUV420, YUV420P8 , YUVA420P8, YUV411, YUV411P8;
- added version.

[Reel.Deel]

StvG

I updated the wiki accordingly.