Avisynth+

[jpsdr]

Typical could be :
In .cpp file :

extern "C" void fn(void *ptr,ptrdiff_t pitch);

x86 asm file :

fn proc ptr:dword,pitch:dword

	public fn

           push ebx
           
           mov ebx,ptr
           mov ecx,pitch.
           mov eax,dword ptr[ebx+ecx]
.....

x64 asm file :

fn proc public frame

	 push rbx
	.pushreg rbx
	.endprolog

	mov rbx,rcx
           mov rcx,rdx
           mov eax,dword ptr[rbx+rcx]           
....

Note : In x64 the 3 first parameters are passed in registers rcx (ptr) and rdx (pitch) and r8d but not here because there is only 2 parameters.

Will work without issue for positive and negative pitch in both x86 and x64.

If you have this instead :
In .cpp file :

extern "C" void fn(void *ptr,int pitch);

x86 asm file :

fn proc ptr:dword,pitch:dword

	public fn

           push ebx
           
           mov ebx,ptr
           mov ecx,pitch.
           mov eax,dword ptr[ebx+ecx]
.....

No change, still working.

x64 asm file :

fn proc public frame

	 push rbx
	.pushreg rbx
	.endprolog

	mov rbx,rcx
           xor rcx,rcx
           mov ecx,edx
           mov eax,dword ptr[rbx+rcx]          
....

Will not work on negative pitch !!!

Issue can be with negative value in asm functions. If you pass in x64 mode to an asm function a pointer (on 64 bits) and a pitch but on 32 bits for it, it will work only on positive value.
In VDub pitch can be negative. If in avisynth pitch is always positive, issues may not occurs.

[jpsdr]

Originally Posted by TurboPascal7

If you plan on going external...

My purpose is to try to do the same thing i've already done with my VDub filters : One cpp file working for both x86 and x64, 2 asm files (one x86 and one x64).
Will i success ? That's another story.

[TurboPascal7]

Originally Posted by jpsdr

My purpose is to try to do the same thing i've already done with my VDub filters : One cpp file working for both x86 and x64, 2 asm files (one x86 and one x64).
Will i success ? That's another story.

Why two asm files when you can do this in one, simply abstracting register names and maybe some other things?
But whatever works for you, I guess.

[foxyshadis]

Some x64 asm can definitely benefit from the extra registers, but so few that the maintenance cost of two asm functions usually outweighs it. Even more so when you start optimizing for various architectures (SSE2, SSSE3, AVX) and 16-bit depth. x86inc is SO useful, and x86util does handy work papering over some more differences. You really should consider using them, you might be surprised.

[ajp_anton]

Could you make so imagesource returns the original colorspace, e.g. jpeg images encoded in 4:2:0 or 4:4:4, instead of converting them to RGB?
Perhaps with the argument pixel_type="original", if you want to keep it compatible with old scripts that assume RGB.

[ultim]

Originally Posted by jpsdr

x64 asm file :

fn proc public frame

	 push rbx
	.pushreg rbx
	.endprolog

	mov rbx,rcx
           xor rcx,rcx
           mov ecx,edx
           mov eax,dword ptr[rbx+rcx]          
....

Will not work on negative pitch !!!

You could just sign extend your edx into rcx to solve this "problem". For example (untested):

fn proc public frame

	 push rbx
	.pushreg rbx
	.endprolog

	mov rbx,rcx
           movsxd rcx,edx
           mov eax,dword ptr[rbx+rcx]          
....

This should work for x64 with both positive and negative pitches, and even requires less assembly lines.

[ultim]

Originally Posted by ajp_anton

Could you make so imagesource returns the original colorspace, e.g. jpeg images encoded in 4:2:0 or 4:4:4, instead of converting them to RGB?
Perhaps with the argument pixel_type="original", if you want to keep it compatible with old scripts that assume RGB.

The current image library (DevIL) in use by AviSynth doesn't allow that, so no. Neither it is possible with many other generic image decoder libraries, as still images are usually composed on RGB surfaces. If anybody knows a still image library that can do that, I'd be happy to have a closer look at it. On the other hand, if it is only possible with format-specific decoders, then I'd only have it as a separate external plugin.

[qyot27]

FFMS2 can be used for stills (see the FFImageSource function in FFMS2.avsi), and it returns the original's colorspace. I just tested it, and it returned 4:2:0 and 4:2:2 directly.

[ultim]

Originally Posted by qyot27

FFMS2 can be used for stills (see the FFImageSource function in FFMS2.avsi), and it returns the original's colorspace. I just tested it, and it returned 4:2:0 and 4:2:2 directly.

Does it really return the original image data unchanged? Or maybe it gets RGB data internally from the format's lib, then ffmpeg converts back to planar on its own?

[jackoneill]

Originally Posted by jpsdr

My purpose is to try to do the same thing i've already done with my VDub filters : One cpp file working for both x86 and x64, 2 asm files (one x86 and one x64).
Will i success ? That's another story.

I already converted nnedi3's asm into an external file that you can assemble with yasm. It works for both 32 and 64 bit. If Avisynth(+) doesn't allow negative strides, you can probably use it without any changes.

https://github.com/dubhater/vapoursynth-nnedi3

[ultim]

Originally Posted by jackoneill

I already converted nnedi3's asm into an external file that you can assemble with yasm. It works for both 32 and 64 bit. If Avisynth(+) doesn't allow negative strides, you can probably use it without any changes.

https://github.com/dubhater/vapoursynth-nnedi3

It is extremely rare, but I do think negative pitches exist in Avisynth, for example when some plugin tries to optimize vertical flips away (I faintly remember seeing it somewhere). Anyway, the workaround is really simple, just sign-extend like I have shown a few posts earlier, and it will work for negative pitches too.

[Reel.Deel]

Originally Posted by ultim

...If anybody knows a still image library that can do that, I'd be happy to have a closer look at it. On the other hand, if it is only possible with format-specific decoders, then I'd only have it as a separate external plugin.

vsimagereader it's able to decode JPEG without converting to RGB. All of the libraries used are listed at the bottom.

[ultim]

Originally Posted by Reel.Deel

vsimagereader it's able to decode JPEG without converting to RGB. All of the libraries used are listed at the bottom.

I know, but even VS's support in this respect only applies to jpeg, over the libjpeg(-turbo) library. Which falls under my format-specific point. I'm proposing a new plugin (e.g. JPEGSource) for this purpose.

[Plorkyeran]

Originally Posted by ultim

Does it really return the original image data unchanged? Or maybe it gets RGB data internally from the format's lib, then ffmpeg converts back to planar on its own?

libavcodec doesn't even have a way to convert the data to RGB, and I have no idea why you'd expect it to be automatically converting to RGB and back.

[jpsdr]

Originally Posted by ultim

You could just sign extend your edx into rcx to solve this "problem". For example (untested):

I've already used sometimes movzd in my VDub filters, but haven't searched yet if something else existed.
You spare me time searching, and this will probably work.
Thanks.

[SEt]

Originally Posted by ultim

I'm proposing a new plugin (e.g. JPEGSource) for this purpose.

Actually I have working very nice JPEG decoder that can be ported to Avisynth. It not just keeps original chroma subsampling, but also supports "reconstruction" that accurately suppresses typical JPEG artifacts and can be done only as part of the decoding stage. Won't be open-source though.

It's currently implemented as plugin (http://plugring.farmanager.com/plugin.php?pid=693) for Far Manager (http://www.farmanager.com/download.php?l=en). It has some documentation, but only in Russian.

[jpsdr]

I think i may have discoverd an issue with x64 version, when trying to port the nnedi3 to x64.
When investigating, i've disable the use of ASM function, and fixed number of cpu (or threads) to 1.

I've the following result, code is around lines 1168.

With this :

		else if (vi.IsYV12())
		{
			for (int i=0; i<ct; ++i)
			{
				v = new nnedi3(v.AsClip(),i==0?1:0,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
				env->ThrowError("Ok");
				v = env->Invoke("TurnRight",v).AsClip();
				// always use field=1 to keep chroma/luma horizontal alignment
				v = new nnedi3(v.AsClip(),1,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
				v = env->Invoke("TurnLeft",v).AsClip();
			}

the script stoped with "Ok" error.

With this :

		else if (vi.IsYV12())
		{
			for (int i=0; i<ct; ++i)
			{
				v = new nnedi3(v.AsClip(),i==0?1:0,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
				v = env->Invoke("TurnRight",v).AsClip();
				env->ThrowError("Ok");
				// always use field=1 to keep chroma/luma horizontal alignment
				v = new nnedi3(v.AsClip(),1,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
				v = env->Invoke("TurnLeft",v).AsClip();
			}

script stop with "acces violation" error.

With this :

		else if (vi.IsYV12())
		{
			for (int i=0; i<ct; ++i)
			{
				v = new nnedi3(v.AsClip(),i==0?1:0,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
				//v = env->Invoke("TurnRight",v).AsClip();
				// always use field=1 to keep chroma/luma horizontal alignment
				v = new nnedi3(v.AsClip(),1,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
				env->ThrowError("Ok");
				v = env->Invoke("TurnLeft",v).AsClip();
			}

script stoped with "Ok" error.

With this :

		else if (vi.IsYV12())
		{
			for (int i=0; i<ct; ++i)
			{
				v = new nnedi3(v.AsClip(),i==0?1:0,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
				//v = env->Invoke("TurnRight",v).AsClip();
				// always use field=1 to keep chroma/luma horizontal alignment
				v = new nnedi3(v.AsClip(),1,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
				v = env->Invoke("TurnLeft",v).AsClip();
				env->ThrowError("Ok");
			}

script stopped with "acces violation" error.

and with this :

		else if (vi.IsYV12())
		{
			for (int i=0; i<ct; ++i)
			{
				v = new nnedi3(v.AsClip(),i==0?1:0,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
				//v = env->Invoke("TurnRight",v).AsClip();
				// always use field=1 to keep chroma/luma horizontal alignment
				v = new nnedi3(v.AsClip(),1,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
				//v = env->Invoke("TurnLeft",v).AsClip();
			}
			env->ThrowError("Ok");

script stopped with "Ok" error.

So, according the results, i have the feeling it's something related to the x64 version of avisynth, as crash seems to occur during call of internal avisynth functions.

[real.finder]

Originally Posted by ultim

You are not the first to suggest that some data types should be changed, but we cannot do so without breaking existing x64 filters.

um, existing x64 filters most of them (maybe all) in 2.5

since there is no avs 2.6 x64 around, and 2.6 x64 filters is just a few, actually the existing is:- mask tools 2 and TP7 filters and last is LaTo filters, it can be update

so, 2.6 in x64 can be change alone? or it can't?

[steptoe]

I'm trying to work out how to use the updated RGTools.dll in place of the RemoveGrain package, but unsure if its just a case of replacing all calls in the removegrain package with rgtools.dll or if the syntax is different

At its most basic, calling for example RemoveGrain(17) or RemoveGrain(2) would this simply now be RGTools(17) or RGTools(2), and loading RGTools.dll instead of RemoveGrain.dll via the 'loadplugin' command

The docs for the updated plugins for avisynth+ are a bit sparse, and don't really suggest if they are direct drop in replacement or if a bit more work may be needed if the original plugins are called within scripts


Scripts that call various parts of the removegrain package, such as RemoveDirtMC, RemoveNoiseMC or RemoveNoiseMC_SE scripts are giving me a headache trying to update them to use RGTool. These all call different parts of the RemoveGrain package, such as the clense function for temporal noise/grain removal

Thanks

[TurboPascal7]

First of all, you're posting in a wrong thread. This is the right one.
First 24 modes of RGTools should be drop-in replacement of the old removegrain plugin. Same goes for repair (24 modes), verticalcleaner (3 modes) an clense (normal, backward, forward). RGTools doesn't have some of the parameters in Clense so you'll have to drop those if you want to use it.