nnedi2/nnedi3/eedi3

[tritical]

nnedi3 v0.9.4
nnedi3 v0.9.2 - 64-bit
eedi3 v0.9.1
nnedi2 v1.6

Filter operation is the same as nnedi... how it accomplishes the task is improved - hopefully. Syntax is almost the same - removed one parameter, added two new ones. 4x enlargement examples with spline36, nnedi, and nnedi2 are here: (nnedi/nnedi2 were used on r/g/b planes, nnedi2 used qual=3, spline36 was used on rgb)

http://bengal.missouri.edu/~kes25c/nnedi2_images

Differences are best seen if you quickly flip back and forth between images. Improvement over nnedi isn't huge by any means, but I thought it was enough to finally warrant a new release.

Wow, pretty impressive difference

Thanks, will give it a whirl!

7ek

[Adub]

Holy Cow Batman! I would definitely say that there is a noticeable difference. Atleast with still images anyways.

[Inspector.Gadget]

Good work, as always.

[aegisofrime]

It should be relatively easy to retrofit this into TempGaussMC, right?

[thewebchat]

Originally Posted by aegisofrime

It should be relatively easy to retrofit this into TempGaussMC, right?

The readme says it's syntax compatible so you can just search/replace all nnedi with nnedi2. Or you can make some lame function "nnedi(blah) { nnedi2(blah) }"

[LaTo]

Good work, thanks!

[lansing]

really nice stuff, how is the speed compare to the old one?

[Terka]

just added
# Create spatially interpolated bob-clips
dbob = clp.bob(0,0.5)
edi = (EdiMode=="NNEDI") ? clp.nnedi(field=-2)
\ : (EdiMode=="EEDI2") ? clp.SeparateFields().EEDI2(field=-2, maxd=EEDI2maxd)
\ : (EdiMode=="NNEDI2")? clp.nnedi2(field=-2)
\ : (EdiMode=="Yadif") ? clp.Yadif(mode=1)
\ : dbob
speed of TGMC looks +- the same, maybee a bit faster.
!good work tritical!

[Terka]

for my DV source the TGMC difference between using nnedi and nnedi2 is invisible.

[Leak]

What are the chances of this being made into a GIMP-plugin?

np: T.Raumschmiere - Brenner (I Tank U)

[Gavino]

Thanks for this, Tritical - good work!

One question which has puzzled me about nnedi (and now nnedi2):
With YV12 clips, simply interpolating between the original pixels introduces a chroma shift of 1/4 pixel.
Is this too small to worry about?

[tritical]

Originally Posted by lansing

really nice stuff, how is the speed compare to the old one?

On my computer (Q6600) with default settings nnedi2 is 25-30% faster than nnedi.

Originally Posted by Leak

What are the chances of this being made into a GIMP-plugin?

I have no experience with GIMP. I'll see how tough it would be before answering .

Originally Posted by Gavino

With YV12 clips, simply interpolating between the original pixels introduces a chroma shift of 1/4 pixel.
Is this too small to worry about?

You mean when using dh=true? I hadn't thought about it, but you are right. There will be a 1/4 on the original scale, 1/2 on the new scale, shift upwards with field=1, or downwards with field=0, because vertically the chroma samples are half way between 2 luma lines. So just copying the original chroma to every other line of the enlarged image doesn't maintain the positioning relative to the luma.

If you follow that with a turnleft or turnright and another dh=true it gets more complicated. Since horizontally the chroma samples are aligned with the left pixel in each pair in the original image, everything should be fine if you use field=1 in the subsequent nnedi2(dh=true) call. However, another shift would be introduced if you use field=0. That also applies to yuy2 since it has the same horizontal subsampling as yv12.

From that point if you rotate the image back, so that you have a 2x enlargement, there will be a vertical shift in chroma. If instead you rotate the image again in the same direction and make another dh=true call, I think there is the possibility to cancel part of the vertical shift or introduce even more vertical shift depending on how you set 'field'.

I'll try to modify the avs functions in the help file to minimize chroma shift when enlarging yv12/yuy2.

[Gavino]

Originally Posted by tritical

You mean when using dh=true? I hadn't thought about it, but you are right. There will be a 1/4 on the original scale, 1/2 on the new scale, shift upwards with field=1, or downwards with field=0, because vertically the chroma samples are half way between 2 luma lines. So just copying the original chroma to every other line of the enlarged image doesn't maintain the positioning relative to the luma.

Yes, that's what I meant.

If you follow that with a turnleft or turnright and another dh=true it gets more complicated. Since horizontally the chroma samples are aligned with the left pixel in each pair in the original image, everything should be fine if you use field=1 in the subsequent nnedi2(dh=true) call. However, another shift would be introduced if you use field=0. That also applies to yuy2 since it has the same horizontal subsampling as yv12.

From that point if you rotate the image back, so that you have a 2x enlargement, there will be a vertical shift in chroma. If instead you rotate the image again in the same direction and make another dh=true call, I think there is the possibility to cancel part of the vertical shift or introduce even more vertical shift depending on how you set 'field'.

That's the conclusion I came to thinking further about it. I think you can minimise the accumulation of shift by alternating between field=0 and field=1 on each further vertical doubling. Then you are always left with just 1/2 final pixel of shift.

Conversely, for the horizontal resizings, you need to use field=0 if doing TurnLeft.Nnedi2().TurnRight() and field=1 for TurnRight().Nnedi2().TurnLeft(). In either of these cases, there will be no shift at all.

EDIT:
Arghh, the vertical doubling case is not so simple once you move beyond 4x. It turns out that for a chain of vertical doublings, the way to minimise the shift is to have field=0 for the first one and field=1 for all the others, or vice versa (start with field=1 and use field=0 for the others). So for 8x, use fields (0, 1, 1) or (1, 0, 0).

[tritical]

Originally Posted by Gavino

That's the conclusion I came to thinking further about it. I think you can minimise the accumulation of shift by alternating between field=0 and field=1 on each further vertical doubling. Then you are always left with just 1/2 final pixel of shift.

Arghh, the vertical doubling case is not so simple once you move beyond 4x. It turns out that for a chain of vertical doublings, the way to minimise the shift is to have field=0 for the first one and field=1 for all the others, or vice versa (start with field=1 and use field=0 for the others). So for 8x, use fields (0, 1, 1) or (1, 0, 0).

Hm, what I came up with in the 4x case using nnedi2(dh=true).turnright() four times in a row is to use the same field value for both vertical shifts, nnedi2 calls 1/3, and to use field=1 for call 2, and field=0 for call 4.

Say you start with field=1, that introduces an upwards shift. turnright() and use field=1 because chroma is aligned with the top field luma... so that doesn't introduce any shift. turnright() again, and the image is now upside down (and flipped horizontally). Since the first call introduced an upwards shift we want to introduce a downwards shift by using field=1 to shift the upside down image upwards. turnright() again, and use field=0 because chroma is aligned with bottom field luma, which introduces no shift. turnright() the final time and the image is enlarged 4x with chroma shifted 1/2 pixel (at 4x scale) upwards relative to luma.

Right or wrong

[Gavino]

Originally Posted by tritical

Right or wrong

Right. Indeed, we're both right.

You are essentially using the same approach as me, but doing things in a different order. I was applying the vertical doublings without rotation, so using a different field for the second one. In your case, the second doubling is done on an upside-down image, so you use the same field. And changing the field used for the horizontal doubling is consistent with my description, since the field to use depends on whether you have turned left or right.

For the 8x case using your approach, if you started with field 1, you would continue with
nnedi(0, dh=true).turnright().nnedi(1, dh=true).turnleft

[Leak]

Wouldn't it be possible for your filter to have a dedicated function that'll internally enlarge the image a given number of times in both directions with non-subsampled chroma?

np: Lali Puna - B-Movie (Faking The Books)

[roozhou]

Where can i get the source code?

[*.mp4 guy]

Originally Posted by Leak

Wouldn't it be possible for your filter to have a dedicated function that'll internally enlarge the image a given number of times in both directions with non-subsampled chroma?

np: Lali Puna - B-Movie (Faking The Books)

nnedi is basid on training a neural net to interpolate a specific spatial position very well, If nnedi2 is based on the same principles, it would be quite dificult to change its interpolation operation. It would also most likely end up two times slower.

[tritical]

Originally Posted by Gavino

Right. Indeed, we're both right.

Yep, I missed that you weren't rotating all the way around. Your way is easier to follow.

Originally Posted by roozhou

Where can i get the source code?

You can't right now.

Originally Posted by Leak

Wouldn't it be possible for your filter to have a dedicated function that'll internally enlarge the image a given number of times in both directions with non-subsampled chroma?

I don't follow. *.mp4 guy is right that changing the location of interpolation isn't possible. However, your suggestion did give me the idea to automate this scripting by making an internal function to take care of the turnright/turnleft sequencing.

On that note, v1.1 changes (zip file is at the same location).

+ added RGB24 support
+ added nnedi2_rpow2 function
+ faster SSE2 routines

This version should be about 25% faster for those with SSE2 but not SSE3. Syntax for nnedi2_rpow2 is

nnedi2_rpow2(int rfactor, int qual, bool pscrn, string cshift, int fwidth, int fheight, int threads, int opt)

It will use nnedi2 to enlarge by a power of 2 (rfactor) while minimizing relative luma/chroma shifting as much as possible. With a secondary goal of minimizing image center shifting when possible. It can then automatically correct for any image center shifting using the resizer you specify with 'cshift', and if you do specify 'cshift' it also gives you the option to set a new output width/height (fwidth/fheight). It works with yv12, yuy2, rgb24. Examples:

enlarge image by 4x, don't correct for center shift.

nnedi2_rpow2(rfactor=4)

enlarge image by 2x, correct for center shift using spline36resize.

nnedi2_rpow2(rfactor=2,cshift="spline36resize")

enlarge image by 8x, correct for center shift and downsample from 8x to 7x using lanczosresize.

nnedi2_rpow2(rfactor=8,cshift="lanczosresize",fwidth=width*7,fheight=height*7)