AvsPmod (Windows_x86) mod

[jpsdr]

@FranceBB
Thanks for the big explaination.
Finaly for now it's somehow an "all or nothing" situation, and not usable on video.
I'll stay for now with NNEDI3 for video if needed (cases for me very few and will even be fewer...).

[real.finder]

Originally Posted by jpsdr

Finaly for now it's somehow an "all or nothing" situation, and not usable on video.
I'll stay for now with NNEDI3 for video if needed (cases for me very few and will even be fewer...).

well, as I said before https://forum.doom9.org/showpost.php...9&postcount=14

nnedi3 will be great if there is nnsharpen (which didn't see the light of the day)

maybe some smart guy can make something similar, who knows

[FranceBB]

AVSPmod mod 2.7.9.0 seems to be behaving ok-ish (as in "it no longer crashes when trying to display frames") with both Windows XP Professional x86 and Windows 10 Enterprise x64, running Avisynth 3.7.4 r4178.
More extensive tests is needed anyway, but I'll let you know if I'm gonna face any hiccups through the day.

Originally Posted by DTL

"4x downscale with SinPowerResize"

It may be somehow outdated and not best way of downsize because it still uses dual-1D resampler instead of more 'natural' 2D (as we have in real physical optics like eye or shooting camera lens). The 2D resamplers expected to make better results.

Yes, that's true, however between the internal Avisynth resizers it was the one that achieved the best results when it came to downscaling.



Not only it kept all the details in the fur, but there are also high frequency details in both the grain of sands and the rocks in the front which got completely flattened out in other resizers like GaussResize().
That's not an outlier, the results are pretty much the same in all tests:

Originally Posted by DTL

Also in your work you use old SincResize from AVS core and it is known as not very perfect in computing in 8 bit and very short kernels (create additional distortions if taps <~80 for 8bit computing).

Well, the calculations were made in high bit depth RGB with 32bit precision, but yeah the point about SincResize() is still valid but it helped showing the problems with overshooting in natural images. I basically used it to show that it was able to preserve the diagonal component (after all it is a Fourier Zero Padding) and that it wasn't subject to staircase artifacts but that it had ripples scattered all over the picture as sinc(x) decays very slowly at the speed of 1/x so the "damage" that we face when we hit an edge (boundary) is spread all over the picture. Although it's possible to see it in natural images as well, I used a synthetic one to make it obvious:



and then I moved on showing how it could be approximated with a compact function and introduced the windowed sincs the likes of LanczosResize() and BlackmanResize().



That's LanczosResize() by the way.

Originally Posted by jpsdr

I'll stay for now with NNEDI3 for video if needed

Yes, I also suggest staying on NNEDI3. While many people's view on the GANs is projected towards the future and with a great hype in mind, mine was pretty much down to earth and very realistic. Currently, the fact that they don't output a deterministic result that can be predicted in all scenarios and the fact that they might introduce details that are not there make their usage in professional settings unfeasible. I'm sure that - with enough optimization - they might find some use in real time applications on consumer devices in the future, but we're not even there yet. As for my use-case, which is remastering and archival, I'm also gonna stick with NNEDI3 whose output is actually solid.



This is the Avisynth Remaster workflow taking in input v210 lossless 720x576 25i (TFF or BFF) BT601 SDR video + PCM 24bit 48000Hz lossless audio, muxed in an AVI container. The workflow indexes the contents, checks the field parity to see whether they're TFF, BFF or progressive, bobs them to 50p if they're interlaced via QTGMC() or just leaves them as 25fps if they're not, then it separates the audio tracks into discrete mono and checks the name of the file (i.e TG24_ or SPORT_ or PCE_ to see whether it's News, Sport or Promo/Cinema/Entertainment). This is important to know which kind of filtering to apply (for instance Sport is spatial only as temporal filters are prone to create artifacts with small fast moving objects like tennis balls, hokey disks etc). Then it checks if there's 4x3 or 16x9 in the name 'cause analog supports don't have an AR flag so the workflow couldn't possibly know (and it relies on a human naming it correctly at acquisition time), at that point it brings everything to 16bit, applies a series of filtering according to the genre and whether it can go temporal or only spatial, but essentially it's a combination of MDegrain3(), dfttest(), z_ConvertFormat(), eventual AddBorders(), nnedi3_rpow2(), Limiter() and if it needs to separate in fields again it does that to get 25i TFF. The final output is an XDCAM-50 file, so

Video: FULL HD 1920x1080 MPEG-2 High 4:2:2 Profile, Level High 50 Mbit/s yv16 25i TFF BT709 SDR

Audio: 8 Mono 1ch PCM 24bit 48000Hz tracks

Container: mxf


Obviously I would never dream to use GANs on such a workflow.

[wonkey_monkey]

Originally Posted by FranceBB

and that it wasn't subject to staircase artifacts

Arguably those are not artifacts if the original image shows a staircase.

[DTL]

" the calculations were made in high bit depth RGB with 32bit precision,"

I think this computing issue does not depend on computing bit depth and will be visible in 8 bit after converting to 8 bit. I think the amplitude of edge-kernel distortion is simply above +-1 LSB of 8 bit so it is visible in 8 bit output. But if you calculate all in 32bit float it may still degrade your PSNR and other metrics.

So SincResize is perfect for perfectly conditioned (for 1D upscale) sources but only in the 'ideal' computing case (when you use large enough taps value and end of kernel can fade enough for current precision). But AVS implementation of SincResize with too low default taps value causes additional distortions. They are not very visible in natural home processing but if you use it as a processing tool for science research it may make some more diffrence between SincResize and LanczosResize.

The distortion at the end of the kernel is not simple sinc ringing - it looks more different. It is > 1 LSB error at the end of the kernel and located at 'taps' distance from some image level transient. So it is expected to cause PSNR metric degradation from possible better value.

You may repeat some of your tests with PSNR metric using SincResize() default taps number and some high value (like 100 or 150 - I do not remember current AVS limit but it is > 100 I think). And to see if the PSNR metric will be different.

Test example - for input bitmap https://drive.google.com/file/d/1wIX...ew?usp=sharing

ImageReader("1point_27_132.bmp")

AddBorders(50,50,50,50)

std=SincResize(width*4, height*4).Crop(400,400,-400,-400)
lk=SincResize(width*4, height*4, taps=100).Crop(400,400,-400,-400)

StackHorizontal(std.Subtitle("SincResize(x4)"), lk.Subtitle("SincResize(x4, taps=100)"))

Result (400%) https://ibb.co/LzxDLLDQ . taps=20 also not save 8bit from distortion only make lower (and at larger distance) https://ibb.co/QvY6MYxm . And when you compute PSNR vs clean input source these 'ghosts' cause additional PSNR metric degradation.

Attempt to make processing in 32bits floats do not helps too :

ImageReader("1point_27_132.bmp")

AddBorders(50,50,50,50)

ConvertToPlanarRGB()

ConvertBits(32)

std=SincResize(width*4, height*4).Crop(400,400,-400,-400)
lk=SincResize(width*4, height*4, taps=20).Crop(400,400,-400,-400)

StackHorizontal(std.Subtitle("SincResize(x4)"), lk.Subtitle("SincResize(x4, taps=20)"))

ConvertBits(8)
ConvertToRGB24()

So LanczosResize with taps > 30..50 of SincLin2Resize taps > 20 emulates SincResize with taps around 10 without such distortions.

[gispos]

AvsPmod has been running for years with more or less problems, but since the new Avisynth API 11 there are very strange errors that I don't want to deal with.
If the script is loaded in a similar way to VDub2 everything works smoothly, but if the C interface is used there are problems, but AvsPmod is dependent on the C interface.

The 2.7.9.0 was just a quick temporary solution to be able to use the API 11 versions. However, I will delete it again because the code is not clean and it should not be used.

I am on Avisynth r4096 and AvsPmod 2.7.8.9 and will stay with it and slowly phase out all AvsPmod programming vor now.
I have reached a point where I don't want to continue yet.

[pinterf]

Originally Posted by gispos

AvsPmod has been running for years with more or less problems, but since the new Avisynth API 11 there are very strange errors that I don't want to deal with.
If the script is loaded in a similar way to VDub2 everything works smoothly, but if the C interface is used there are problems, but AvsPmod is dependent on the C interface.

The 2.7.9.0 was just a quick temporary solution to be able to use the API 11 versions. However, I will delete it again because the code is not clean and it should not be used.

I am on Avisynth r4096 and AvsPmod 2.7.8.9 and will stay with it and slowly phase out all AvsPmod programming vor now.
I have reached a point where I don't want to continue yet.

I need your advice.

I've been working on this topic for the past few days because the applied solution should have worked (I added two more conditionals in the Avs value release section - values must be released - except the array itself), but it didn't. I got frustrated because I tested it with an older version of Avisynth, and even the original lines didn't work. I encountered the same problem: not all clips were released. Today, I tried running the plain run.py without the .EXE compilation, and it worked. I switched back to my new AVSValue release lines with the new Avisynth, and it worked!

My version of the release. Everything, except the array itself.

    def release(self):
        if self.is_array():
            for index in range(self.array_size()):
                element = avs.avs_array_elt_w(self.cdata, index)
                if not avs.avs_is_array_w(element):  # Only release non-array elements
                    avs.avs_release_value_w(element)
        else:
            avs.avs_release_value_w(self.cdata)
        if self.is_defined():
            self.set_void()

Have you experienced issues where some versions of the Python 2.7 to .exe utility might be buggy and should be avoided? Or script related? The script contains a check whether it is run from script or within a packed .exe. EDIT: I have 0.6.9.

[gispos]

Originally Posted by pinterf

I need your advice.

I've been working on this topic for the past few days because the applied solution should have worked (I added two more conditionals in the Avs value release section - values must be released - except the array itself), but it didn't. I got frustrated because I tested it with an older version of Avisynth, and even the original lines didn't work. I encountered the same problem: not all clips were released. Today, I tried running the plain run.py without the .EXE compilation, and it worked. I switched back to my new AVSValue release lines with the new Avisynth, and it worked!

My version of the release. Everything, except the array itself.

    def release(self):
        if self.is_array():
            for index in range(self.array_size()):
                element = avs.avs_array_elt_w(self.cdata, index)
                if not avs.avs_is_array_w(element):  # Only release non-array elements
                    avs.avs_release_value_w(element)
        else:
            avs.avs_release_value_w(self.cdata)
        if self.is_defined():
            self.set_void()

Have you experienced issues where some versions of the Python 2.7 to .exe utility might be buggy and should be avoided? Or script related? The script contains a check whether it is run from script or within a packed .exe. EDIT: I have 0.6.9.

You can stop any further efforts.
I have just created a version that works with r4178.

And that is now very very embarrassing!
When I saw your change in 'release' in your posting, I already thought that the old code without 'else' is a stupid bug.

But I didn't think that this could lead to the result.
BUT IT DOES !

I never changed anything there and the stupid bug has probably existed since AvsP exists and only became a real problem with API 11.

I did a lot of tests and deleted almost every function that wasn't needed until I finally had enough and gave up.

4 eyes see more than 2

Thank you for your support!

[gispos]

AvsPmod 2.7.9.2

* Fixed Version that is now working with newer Aviynth API 11 Versions. RIFE should also no longer cause any problems.
The thanks go to pinterf.

[Emulgator]

Congrats, you two, and many thanks for the effort !
Soon testing...
Yes, AvsPmod64 2.7.9.2 can handle AviSynth64+ r4066 and r4178 nicely, releasing works, no stalls on my few attempts.

Still AviSynth64+ r4178 crashes if I call RIFE instances within Scriptclip while r4066 performs nicely.
Will test further with which Avs+ version the regression came in and notice pinterf.
AviSynth64+ r4066: 1 RIFE instance within Scriptclip: ok.
AviSynth64+ r4073: 1 RIFE instance within Scriptclip: ok. Seems last good for me now.
AviSynth64+ r4096 Clang: 1 RIFE instance within Scriptclip: ok, but slower.
AviSynth64+ r4173: 1 RIFE instance within Scriptclip: F5-loading in AvsPmod 2.7.9.2:
1st frame loaded, when press Play: stuck for 5..10 seconds, then AvsPmod aborts.

AviSynth64+ r4177: 1 RIFE instance within Scriptclip: F5-loading in AvsPmod 2.7.9.2: 1st frame 0 gets loaded.
When I press Play: I hear the first audio blip for that frame 0, then frame 0 is shown stuck for 5..6 seconds, no audio.
After these 5 seconds I hear the same audio blip of frame 0 a second time, then AvsPmod aborts.

AviSynth64+ r4178: 1 RIFE instance within Scriptclip: F5-loading in AvsPmod 2.7.9.2: 1st frame 0 gets loaded.
When I press Play: I hear the first audio blip for that frame 0, then frame 0 is shown stuck for 5..6 seconds, no audio.
After these 5 seconds I hear the same audio blip of frame 0 a second time, then AvsPmod aborts.

[pinterf]

Originally Posted by gispos

AvsPmod 2.7.9.2

* Fixed Version that is now working with newer Aviynth API 11 Versions. RIFE should also no longer cause any problems.
The thanks go to pinterf.

Long live AvsPMod!

[pinterf]

Originally Posted by Emulgator

Congrats, you two, and many thanks for the effort !
Soon testing...
Yes, AvsPmod64 2.7.9.2 can handle AviSynth64+ r4066 and r4178 nicely, releasing works, no stalls on my few attempts.

Still AviSynth64+ r4178 crashes if I call RIFE instances within Scriptclip while r4066 performs nicely.
...

Thanks! Since this isn't quantum mechanics, there must be a core reason that's most probably not specific to AvsPMod. I'll get it resolved sooner or later.

[gispos]

AvsPmod 2.7.9.3

Additional updates for Avisynth API 11

Originally Posted by Emulgator

AviSynth64+ r4178: 1 RIFE instance within Scriptclip: F5-loading in AvsPmod 2.7.9.2: 1st frame 0 gets loaded.
When I press Play: I hear the first audio blip for that frame 0, then frame 0 is shown stuck for 5..6 seconds, no audio.
After these 5 seconds I hear the same audio blip of frame 0 a second time, then AvsPmod aborts.
[/SIZE]

It hangs in the playback?
I have tested RIFEwrap and normal RIFE with playback, and it runs smoothly for me.

You using another ScriptClip in addition to the RIFEwrap ScriptClip or do you use RIFE in ScriptClip direct?
Here is a short video in 7z of my test with RIFE.

https://drive.google.com/file/d/1uhy...ew?usp=sharing

[Emulgator]

gispos, many thanks ! All is/was solved, already in your version 2.7.9.2.
It was a regression within AviSynth+. Ferenc found it and built AviSynth+ r4182.
https://forum.doom9.org/showthread.p...12#post2014712
Yesterday I started a "mean stacked script", fed this to Topaz 2.6.4 and just in this very minute it finished sucessfully.
Do you accept donations ?

[gispos]

Originally Posted by Emulgator

gispos, many thanks ! All is/was solved, already in your version 2.7.9.2.
It was a regression within AviSynth+. Ferenc found it and built AviSynth+ r4182.

Ferenc is once again working at full capacity. Thanks again from my side

Originally Posted by Emulgator

Do you accept donations ?

No, never ask that again.

[tormento]

Originally Posted by DTL

Also in your work you use old SincResize from AVS core and it is known as not very perfect in computing in 8 bit and very short kernels (create additional distortions if taps <~80 for 8bit computing). Better use SincLin2Resize (taps >8..10) or simple LanczosResize with big enough taps value (taps >20). They are not suffer from computing issues at the edges of very truncated sinc kernel.

You wrote SincResize but actually FranceBB wrote Sin not Sinc and they are two different beasts.

[Emulgator]

Hi gispos ! While I am digging into python incompatibilites against older systems (XP SSE, XP SSE-2)
it may be helpful if you could upload some builds of your missing AvsPmod Versions from back in 2018 (if still available at all):

Version 2.5.1.12 [2018-09-29] GPo
Version 2.5.1.14 [2018-11-06] GPo
Version 2.5.1.15 [2018-11-17] GPo
Version 2.5.1.16 [2018-12-08] GPo
Version 2.6.0.1 [2019-01-04] GPo

first non-starter under these vintage conditions so far is Version 2.6.0.2 [2019-01-07] GPo, Python fault (2.7.15150.1013)
(non-starter under GERICOM M6T WinXP32ProSP3 Tualatin 1,2GHz MMX,SSE 512MB)
(non-starter under Toshiba Satellite 5200-801 WinXP32ProSP3 P4m-2000 2,0GHz MMX,SSE-2, TM1 1GB)

mixed under these vintage conditions: Version 2.5.1-452 [2015-08-09] Python 2.7.10150.1013
(non-starter under GERICOM M6T WinXP32ProSP3 Tualatin 1,2GHz MMX,SSE 512MB)
(starts under Toshiba Satellite 5200-801 WinXP32ProSP3 P4m-2000 2,0GHz MMX,SSE-2, TM1 1GB)

last good under these vintage conditions seems to be Version 2.5.1-90 [2017-03-24] Python 2.7.13150.1013
(starts under GERICOM M6T WinXP32ProSP3 Tualatin 1,2GHz MMX,SSE 512MB)
(starts under Toshiba Satellite 5200-801 WinXP32ProSP3 P4m-2000 2,0GHz MMX,SSE-2, TM1 1GB)

Many thanks in advance !

[gispos]

Originally Posted by Emulgator

Hi gispos ! While I am digging into python incompatibilites against older systems (XP SSE, XP SSE-2)
it may be helpful if you could upload some builds of your missing AvsPmod Versions from back in 2018 (if still available at all):

Version 2.5.1.12 [2018-09-29] GPo
Version 2.5.1.14 [2018-11-06] GPo
Version 2.5.1.15 [2018-11-17] GPo
Version 2.5.1.16 [2018-12-08] GPo
Version 2.6.0.1 [2019-01-04] GPo

first non-starter under these vintage conditions so far is Version 2.6.0.2 [2019-01-07] GPo
(non-starter under GERICOM M6T WinXP32ProSP3 Tualatin 1,2GHz MMX,SSE 512MB) Python fault (2.7.15150.1013)
(non-starter under Toshiba Satellite 5200-801 WinXP32ProSP3 P4m-2000 2,0GHz MMX,SSE-2, TM1 1GB) Python 2.7.10150.1013

mixed under these vintage conditions: Version 2.5.1-452 [2015-08-09]
(non-starter under GERICOM M6T WinXP32ProSP3 Tualatin 1,2GHz MMX,SSE 512MB) Python 2.7.10150.1013
(starts under Toshiba Satellite 5200-801 WinXP32ProSP3 P4m-2000 2,0GHz MMX,SSE-2, TM1 1GB) Python 2.7.10150.1013

last good under these vintage conditions seems to be Version 2.5.1-90 [2017-03-24]
(starts under GERICOM M6T WinXP32ProSP3 Tualatin 1,2GHz MMX,SSE 512MB) Python 2.7.13150.1013
(starts under Toshiba Satellite 5200-801 WinXP32ProSP3 P4m-2000 2,0GHz MMX,SSE-2, TM1 1GB) Python 2.7.10150.1013

Many thanks in advance !

Oh dear,
the oldest version on my PC is 2.7.4.0 and on VideoHelp under older versions 2.6.1.1
And there is still a 2.6.0.6 on Github.

I'm sorry, but I can't help you with that.

[Emulgator]

No problem at all. This was rather academic, and geared toward python.
I may as well be moving python around and see where it fits.

[gispos]

AvsPmod 2.7.9.4

* Further changes for the avisynth API 11:
- e.g. if AvsPmod was terminated and the memory was exceeded (to many scripts opened), it could happen that AvsPmod did not terminate. 
- for API 10 and before a Destroy() call was sufficient which could lead to problems with API 11