Log in

View Full Version : Is possible makes a upscaling with eedi3 + nnedi3?


luquinhas0021
14th July 2015, 19:23
Tritical (Or who knows), can you tell me all eedi3_rpow2's parameters on Avisynth? I had looked for it on Avisynth Wiki, but I haven't seen. Is possible makes a upscaling with eedi3 + nnedi3, with control of all parameters of every single one?how? eedi3 + nnedi3 upscaling is better than eedi3 alone (Or nnedi3 alone)? What is a optimum algorithm to put on nnedi3's cshift paraneter: spline64, spline 100, lanczos4, or other?

colours
14th July 2015, 20:31
Check the readme files included with eedi3.

The eedi3_rpow2 and nnedi3_rpow2 interfaces have fewer options than eedi3 and nnedi3, so if you want something fancy like using nnedi3 sclip with eedi3 upscaling, what you can do is to PointResize the clip to double height, then use normal eedi3 with the sclip being normal nnedi3. (Likewise for mclip masking, if you want eedi3 to not take forever.)

The downside is that if you do this, you'll have to calculate the shifts needed, which is normally automatically handled when you specify cshift.

Also, rule 12 (http://forum.doom9.org/forum-rules.htm), gosh darn it.

luquinhas0021
14th July 2015, 20:42
Colours, I will try eedi3 + nnedi3. I hope to have a incredible result, even cause nnedi3_rpow2 is very slow. Imagine eedi3 + nnedi3 lol
In this thread was spoken about nnedi4, but... Where it at?! I didn't find it in Tritical's website

MysteryX
15th July 2015, 04:31
Colours, I will try eedi3 + nnedi3. I hope to have a incredible result, even cause nnedi3_rpow2 is very slow. Imagine eedi3 + nnedi3 lol
In this thread was spoken about nnedi4, but... Where it at?! I didn't find it in Tritical's website
I use EEDI3+NNEDI3 for noisy videos (slow), NNEDI3+EEDI3 for average videos (very slow), and NNEDI3+NNEDI3 for good-quality videos (faster)

colours
15th July 2015, 06:29
Far as I can tell, nnedi4 was never released. Also, nnedi3 is like ten times faster than eedi3 so if you were already going to use eedi3 anyway, why not just accept a few percent extra of overhead?

luquinhas0021
15th July 2015, 12:40
By the upscaling, will may Point Resize the more correct, but the pixels are put in incorrect coordinates?

feisty2
15th July 2015, 13:11
plz, ur chasing rainbows, what ur lookin 4 (perfect upscaling algorithm) is still YET TO COME (another word, does not exist)

luquinhas0021
15th July 2015, 13:26
feisty2 is a kind of Doom9's user I don't ask for, because for he, everithing is impossible, everything is try to be perfect.
Festy2, have you already heard speak in IMPROVEMENT? Point Resize is a lossless algorithm, so let's improve it.
Next time, do not talk trash.

feisty2
15th July 2015, 13:40
okay then, go ahead, eedi3+nnedi3 upscaling as you wish

eedi3 (dh=true, alpha=1, beta=0, gamma=0, nrad=3, mdis=40, sclip=nnedi3 (dh=true, nsize=3, nns=4, qual=2, etype=1))
turnleft ()
eedi3 (dh=true, alpha=1, beta=0, gamma=0, nrad=3, mdis=40, sclip=nnedi3 (dh=true, nsize=3, nns=4, qual=2, etype=1))
turnright ()

luquinhas0021
15th July 2015, 13:51
Where I put the parameter rfactor: in eedi3, in nnedi3 or in both? Why "turn left" and "turn right"? Is obbligated to have two lines: eedi3 + nnedi3 "turn left" and eedi3 + nnedi3 "turn right"?

feisty2
15th July 2015, 14:09
please, they're all written in "readme.txt", spend 3 minutes and read them

luquinhas0021
15th July 2015, 14:19
I'm in a mobile, dude! The problems are my mobile doesn't read .txt file and the my house's computer falls down. This means I will have to go in a lan house and test it.
If you can past the content of eedi3 read me file on this thread, I will be glad.
Regards

Bloax
15th July 2015, 14:27
The answer to your question is because **edi is first and foremost a deinterlacer in the form of a field interpolator, with a special flag called "dh" that doubles the height of the input by stacking every individual field from the original data above/below an interpolated field.

The turnleft/edi/turnright is just a workaround for this principle, since rotating the data by 90 degrees means that "height" data is technically the actual "width" data - and so doubling the resolution of this after doubling the height followed by a reverse rotation effectively results in a doubling of both the vertical and horizontal resolution.
(Since doubling the height of the rotated data means doubling the width of the original data.)

nnedi_rpow2() does the same thing, except it does so behind the hood instead of showing you all the nice hacky details.

Groucho2004
15th July 2015, 14:44
feisty2 is a kind of Doom9's user I don't ask for, because for he, everithing is impossible, everything is try to be perfect.
Festy2, have you already heard speak in IMPROVEMENT? Point Resize is a lossless algorithm, so let's improve it.
Next time, do not talk trash.
Considering your history of vexatious questions about "the best" scaling algorithms, you should consider yourself lucky that anyone is answering.

luquinhas0021
15th July 2015, 16:27
Bloax, I will write some values of some eedi3 parameters, then you tell me if it is correct or not, ok?
For upscaling: field=1, dh=true
For deinterlacing: field=3; dh=false
For antialiasing (No interlaced video): field=1, dh=false

Bloax
15th July 2015, 16:35
That's right, and for best effect you blend together the results of nnedi3(field=1, dh=false) and nnedi3(field=0, dh=false).
at least if field=0 is interpolating the field that is left intact when using field=1

luquinhas0021
15th July 2015, 16:47
This blend is for deinterlacing, isn't? How I blend the results?
For antialiasing and or upscaling, there's some blend that makes optimum results? which?

Bloax
16th July 2015, 05:13
The blending is for antialiasing, since doing so results in every field getting interpolated to some degree.

luquinhas0021
16th July 2015, 16:26
Instead makes a eedi3 + nnedi3 upscaling, what do you think about make a PointResize upscaling + (eedi3 + nnedi3 antialiasing)? It is a good choice over make eedi3 + nnedi3 upscaling?

Bloax
17th July 2015, 19:24
Judging by how nnedi works - which is looking at chunks (eg. 32x5) of data - and interpolating based on edge flow, and how point resizing would not only literally halve (or worse) the resolution of these chunks, but also introduce a whole bunch of false square edges, no - that wouldn't be a very good idea.

luquinhas0021
17th July 2015, 19:44
Bloax, thank you for your reply!
I asked because the eedi3 + nnedi3 deinterlacing gives more pleasant results than eedi3 only result or than nnedi3 only result. So, I though the upscaling with eedi3 + nnedi3 gives more affordable results than eedi3 only or than nnedi3 only. Am I write?
I change the order (For upscaling): nnedi3 + eedi3; it's a good idea, over eedi3 + nnedi3?