TDeint and TIVTC

[manono]

I also reworded that error message slightly in case someone somehow gets it again

"manono is a dumbass" maybe?

Darn, now I'll have to try and break it to see what the message is. Thanks for the fast update.

[manono]

Been testing:

+ Added trimIn parameter (trim before tfm w/ d2v support)

I could actually encode with the previous version, but it didn't honor the Trim, as I found out much to my chagrin. However, using the new version, this doesn't open in VDubMod:

Trim(450,0)
TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
TDecimate(mode=0)

The message is, "D2V frame count doesn't match filter frame count!" This does open and encodes properly:

TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
Trim(450,0)
TDecimate(mode=0)

[Leak]

I also reworded that error message slightly in case someone somehow gets it again

"manono is a dumbass" maybe?

Darn, now I'll have to try and break it to see what the message is. Thanks for the fast update.
Or you could just cheat and look at the source files... not that I would do or encourage it, of course... ;)

[TheBashar]

However, using the new version, this doesn't open in VDubMod:

Trim(450,0)
TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
TDecimate(mode=0)


Isn't this exactly what the trimIn parameter is for?

[tritical]

I could actually encode with the previous version, but it didn't honor the Trim, as I found out much to my chagrin. However, using the new version, this doesn't open in VDubMod:

Trim(450,0)
TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
TDecimate(mode=0)

The message is, "D2V frame count doesn't match filter frame count!"
Previous to this version tfm didn't require that the number of frames it had info for from the d2v file actually matched the input frame count. Instead, it simply used the first frame count number of entries (if the d2v had more) or it used nothing for the extras (if the d2v had less). That wasn't a very good solution, but it did stop tfm from crashing when filling the d2v info array if the d2v had more info. With the addition of the trimIn parameter I decided to require that the frame info from the d2v file match the input frame count (that is where the new error msg comes from). The whole reason that the trim before requires special support is that tfm has no way to determine if a trim statement actually came before it or not.

This does open and encodes properly:

TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
Trim(450,0)
TDecimate(mode=0)
Trimming after tfm is a viable option, the only thing it messes up is that when TDecimate gathers the hint information from tfm it assumes that the incoming frames are in the same order as when they came out of tfm. For example, to determine duplicates via matches tdecimate looks at the frame matches delievered by tfm. It uses that info to see if the same field has been used in two frames in a row... i.e. if the current frame match is 'p' and the previous match was 'c' (and neither match was marked as combed and deinterlaced) then there was a repeated field. If you use trim() before tdecimate then those assumptions are no longer correct for the first frame after the cut position. TDecimate also considers rff duplicate info that is passed by tfm, and that information would also be incorrect for the first frame following a cut. Currently there is no way to disable tfm's hinting or to force tdecimate not to use the information if it sees that it is present.

Changing your script to use trimIn would work like this:

TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0,trimIn="trim.txt")
TDecimate(mode=0)

with trim.txt containing the following line:

0,449

Here 0,449 is marking the frames that were cut out (inclusive).

[manono]

Yep, manono is a dumbass. Thanks for the heads up, TheBashar, and for the detailed explanation, tritical.

[tritical]

Unfortunately, school and other things have set me back on getting TDeint2 completed, as well as getting TIVTC and TDeint released (but they will be out eventually). I have had a little bit of time to do some low level optimizing of TIVTC, which I have been putting off. Here is the first take which focuses on tdecimate... [link removed], changes:

TDecimate:

+ optimized c metric calculation routine (~2.5-3x faster)
+ removed width restrictions on isse yuy2 scenechange detection routine
+ added mmx yuy2 scenechange detection routine
+ removed all pitch and width restrictions on isse sad/ssd block metric
calculation routines
+ added mmx sad routines
+ require mmx and not isse for the assembly ssd routines because they use
only mmx instructions
+ removed width restrictions on mmx denoise routines
- fixed possible divide by zero crash with vidDetect = 4Next, I'm going to spend a little time on optimizing tfm and porting the above tdecimate changes into framediff/framediffc.

[MacAddict]

I guess it is not that clear in the documentation, but for mode 5 it needs all the stats so it can calculate everything at the beginning, which means two passes need to be made. In the first pass use/run this script:

mpeg2source("c:\sg1614.d2v",cpu=4,idct=7,ipp=true)
assumetff()
converttoyv12(true) <= is your source 4:2:2?
clp = last.rgbob().selecteven()
tfm(pp=4,clip2=clp,output="matches.txt")
tdecimate(mode=4,output="metrics.txt")
crop() <= change this to crop the image down to 32x32 or 16x16 to speed things up

That pass is only to allow tfm/tdecimate to gather the needed info (i.e. create the output files), so the actual video output of that pass doesn't matter.

Just to clarify, I could essentially turn off all extra video codec options I'd typically have on for this first pass right? For example I'll disabe Qpel, VHQ, Motion Search, B-Frames and even set a constant quant of 31 within XviD. I'm assuming that would be correct ;)

Edit- Thanks again for your effort on this project, greatly appreciated.

[tritical]

Yep, that would work. For the first pass when tivtc gathers info, literally anything that requests all the frames of the script will work... a getall() (from avstimer) at the end of the script, using preview in vdub, etc... whatever runs fastest for you. I usually just open the script (which after crop outputs 16x16 or 32x32 res) in vdub, select fast recompress with huffyuv as the codec (though at that size which codec you use doesn't make much difference), and then save as avi. That way is very fast and you can select the process priority.

[DarkNite]

I'm always happy about faster metrics calculation.

The funny thing is this news actually made my day several degrees better than it was. For a moment there I was about one spreadsheet or phone call away from DEFCON 4. This was just enough good news to lift myself out of a rut. :p

:thanks: I'd hand you a beer if I could.

[foxyshadis]

That way is very fast and you can select the process priority.
Virtualdub actually has a 'run video analysis pass' which is pretty much the same as what you do, without having to select a codec or save file. No big difference, just thought you might like to know. It gave me a bit of trouble in 1.6.10, but not since 1.6.11.

[MacAddict]

Virtualdub actually has a 'run video analysis pass' which is pretty much the same as what you do, without having to select a codec or save file. No big difference, just thought you might like to know. It gave me a bit of trouble in 1.6.10, but not since 1.6.11.
Hmmm I'm not having any success using Vdub 1.6.11 doing 'run video analysis pass' feature. The analysis runs fine without error but then I go to run the 2nd pass and immediately get an error: Input Error(mode 5 & 6, all frames must have entries).

mpeg2source("D:\ep17.d2v")
assumetff()
#
#First pass VFR
#tfm(d2v="D:\ep17.d2v",order=1,output="matches.txt")
#tdecimate(mode=4,output="metrics.txt")
#crop(344,224,-344,-224)
#
#second pass VFR
tfm(d2v="D:\ep17.d2v",input="matches.txt")
tdecimate(mode=5,hybrid=2,vfrDec=0,input="metrics.txt",tfmIn="matches.txt",mkvOut="mkv-timecodesfile.txt")

Any ideas or am I just missing something obvious?

[tritical]

@DarkNite
Thanks, and I would definitely take the beer if I could :).

@foxyshadis
Didn't even know about or ever notice that function, will definitely have to try it out. :thanks:

@MacAddict
Gonna try out the 'run video analysis pass' function now, will report if it works for me or not.

EDIT: It worked fine for me. I don't see anything wrong in your scripts... does it work correctly if you actually use "save as avi"? If so, could you create the output files once using that method and then again using the "run video analysis pass" method and see how they differ?

[MacAddict]

@tritical
You read my mind. VdubMod 1.5.10 b2540 works flawlessly of course as we normally use it with different passes. Vdub 1.6.11 does work fine with the same script using "save as AVI" but unfortunately I'm in the middle of a 11 hour TDeint bob encode and can't do an analysis on the matchcode files. I'll try and reproduce the problem on another PC tomorrow and post my findings to see if a difference does exist between the two methods. Thanks for trying it out.

@foxyshadis
Thanks for the 1st pass tip in Vdub. Too bad VdubMod isn't being developed and including that feature, I prefer it for the extra functionality and configuration.

[ChronoCross]

Virtualdub actually has a 'run video analysis pass' which is pretty much the same as what you do, without having to select a codec or save file. No big difference, just thought you might like to know. It gave me a bit of trouble in 1.6.10, but not since 1.6.11.
Additionally you can just hit the play button, that works well. Just diable previews. but a reminder to all who use this method you have to remember to close out of the avs when you finish the pass. any additionaly frame jumping will also be recorded into the metrics file which is bad.

[MacAddict]

I'm not able to reproduce the the issue I mentioned above, even using the same files/episodes and scripts on the same PC. I tested 2 other PCs and it appears to work fine. Only difference I can think of now is that I rebooted this PC. If all else fails reboot! Sorry for the waste of time tritical.

@ChronoCross
I noticed the same thing early on. It appears the text files aren't created until Vdub/VdubMod is closed. Good tip.

@all
I'm just starting to get my head wrapped around TFM/Tdeint finally and understanding the basic parameters for my material. Does anyone have examples thats worked well for them on standards converted movies where Restore24 and Cpackage has failed? I currently have some NTSC->PAL and vice versa film material thats driving me insane due to it not being smooth. Mode=7 helps in some cases on the blended fields but I'm still seeing some jerkiness on occassion. Combed isn't a problem at all so would it be safe for me to use PP=0 in order to prevent jerkiness?

[scharfis_brain]

tritical: is the a pre-build of TDEint2 somewhere to play with?

[tritical]

I'll try to put one up in the next few days. Currently, the motion stuff is in one program and the interpolation is in another... I just haven't had the time to merge it all and get everything working together.

I am gonna go ahead and release a standalone edge directed interpolation filter that resizes by 2x in the vertical direction using my new ela method. TIVTC has the clip2 option so it could make use of it already, and it would be very simple to add a clip2 type option to TDeint as well (and that is a feature I think it should really have).

[tritical]

Here's [link removed]... it resizes by 2x in the vertical direction by copying the current image to every other line in the resized image and then interpolating the missing field. Basically, it works the same way as "elaresize" which was a filter I posted on neuron2's forum some time ago. This filter is my latest edge-directed interpolation for deinterlacing attempt. The goals have been to preserve the filter's ability to connect edges and operate without the need for value capping (a sanity threshold), while at the same time eliminating the typical artifacts that usually produces. In order to do that it uses a two step process so that it can force spatial consistency and coherency of the direction map... in other words it is SLOW :p. While not as perfect as I would like it to be, it is, under most conditions, more stable then TDeint's type=3 or type=1 methods and does a much better job.

Anyways, here is a sample... I took this image from a thread on the virtualdub forums where it was posted by neuron2. In each case one field from the original image has been discarded, and the remaining field has been used to construct a new frame:

original:
http://bengal.missouri.edu/~kes25c/orig_1.jpg

avisynth's bob:
http://bengal.missouri.edu/~kes25c/bob_1.jpg

tdeint_type=1:
http://bengal.missouri.edu/~kes25c/td1_1.jpg

tdeint_type=3:
http://bengal.missouri.edu/~kes25c/td3_1.jpg

eedi2:
http://bengal.missouri.edu/~kes25c/eedi2_1.jpg

In this example EEDI2 easily beats both type=1 and type=3 of TDeint. The lines are too dark and small for type=1 to allow them to be connected (it's sanity threshold kicks in), and it drops back to cubic interpolation. Type=3 does a better job since it doesn't work by selecting one candidate and then testing it against the sanity threshold, but tests all other possible candidates as well. However, it still can't actually connect the lines due to the sanity threshold.

To build a dumb deinterlacer out of EEDI2 you can use the following:

1.) tff, keep top field:

separatefields().selecteven().EEDI2(field=1)

2.) tff, keep bottom field

separatefields().selectodd().EEDI2(field=0)

3.) bff, keep bottom field

separatefields().selecteven().EEDI2(field=0)

4.) bff, keep top field

separatefields().selectodd().EEDI2(field=1)

or to make a bobber:

1.) tff

separatefields().EEDI2(field=3)

2.) bff

separatefields().EEDI2(field=2)

In this manner it is possible to use EEDI2 in combination with TIVTC via TIVTC's clip2 parameter. For the moment it isn't possible to use EEDI2 with TDeint... but hopefully there will be a way to use it in conjunction with a motion-adaptive or motion-compensated deinterlacer sometime soon. Needless to say this filter was developed testing exclusively on anime and the sample image posted above... how well it works on real life images is still a mystery :).

[Mug Funky]

that's really impressive! it's finding diagonals that i didn't think it was possible to find with any reasonable speed.

crossing objects appear to artefact in a similar way to sangnom though... try an "x" shape that crosses at an angle of about 30 degrees and you'll probably see them.

i'm only using defaults at the moment though.

[edit]

it also makes a very good comb mask :)

[Guest]

Tritical, please explain the field parameter in detail. Thank you.

[Guest]

I see that the EEDI2 filter has these parameters:

mthresh
lthresh
vthresh
estr
dstr
maxd
field
map
nt

Would it be possible for you to explain them in detail?

Thank you.

[Guest]

Thanks for the great interpolator.

Please describe parameter 'nt'. It's not in the README.

EDIT: I tried it on some natural video and it looks great there too; much better than a Lanczos resize.

[tritical]

crossing objects appear to artefact in a similar way to sangnom though... try an "x" shape that crosses at an angle of about 30 degrees and you'll probably see them.

i'm only using defaults at the moment though.
Yeah... junctions are still a problem, specifically those involving diagonal lines/edges. There are also some patterns that can cause it to mess up when they are present at the right spacing. I still have quite a few ideas for improving it (slowing it down more) though... haven't even gotten to testing for consistency of interpolated values among directionally corresponding neighbors or testing for consistency among the final interpolation directions.

Please describe parameter 'nt'. It's not in the README.
In certain places a starting value is given to the "min" variable when checking for the direction that minimizes the cost function. If no direction gives a value less than the starting minimum then no direction is used. The nt variable is used when setting that initial value. The cost function sums the abs() differences of pixels in the sliding vectors, so nt corresponds to a pixel difference and the min variable is usually set equal to: # of differences*nt. I normally use 50 (TDeint's type=3 uses the same thing), but for testing purposes I decided to make it alterable. I found that changing it didn't effect things much at all and decided to leave it out of the readme. Theoretically, increasing nt should allow better diagonal edge/line reconstruction while creating more artifacts, and decreasing nt should hurt diagonal edges/lines but decrease artifacts.

[AVIL]

@tritical

I'vi give to EEDI2 v0.9 a try as bobber. I'm very happy with the results. Far better as TDEINT even with the default values. My footage is real video, not anime. Only a word : chapeau

[scharfis_brain]

here my small contribution to produce artifact free motion adaptive deinterlacing:

function securedeint(clip i, int th, int l)
{ function staticmask(clip e, int th, int l)
{e0=e.motionmask(thy1=0,thy2=th,thc1=0,thc2=th,thSD=255)
e1=e0.trim(1,0)
e2=e0.trim(2,0)
e3=e0.trim(3,0)
e4=e0.trim(4,0)
e5=e0.trim(5,0)
e6=e0.trim(6,0)
e7=e0.trim(7,0)
ea0=logic(e0,e1,"OR")
ea1=logic(e2,e3,"OR")
ea2=logic(e4,e5,"OR")
ea3=logic(e6,e7,"OR")
eb0=logic(ea0,ea1,"OR")
eb1=logic(ea2,ea3,"OR")
ec=logic(eb0,eb1,"OR")
(l==0) ? ec. greyscale().duplicateframe(0).duplicateframe(0).duplicateframe(0) :\
(l==1) ? eb0.greyscale().duplicateframe(0) :\
(l==2) ? ea0.greyscale() :\
e0.greyscale()
}



i.converttoyv12(interlaced=true).separatefields()
e=selecteven().staticmask(th, l)
o=selectodd().staticmask(th, l)
interleave(e,o)
m=doubleweave().blur(0,1).binarize(upper=false)

b= getparity(i) ? i.separatefields().eedi2(field=3) : i.separatefields().eedi2(field=2)

d=i.doubleweave()

overlay(d,b,mask=m)
}

what it does:
creating two separate motionmasks for odd and even fields each. then combining them. so it is possible to identify static areas for sure.
but this will reduce detail in static areas, where a moving object recently has passed by.

parameters:
th = deinterlacing threshold:
0 -> stupid bob
6 -> a good value to start with
the higher the more residual combing

l = length of the combmask:
0 -> 16+2 fields are used for motion masking
1 -> 8+2 fields
2 -> 4+2 fields
any other value -> 2+2 fields

this large radius (l=1 or l=0) effectively helps against holes for linear moving, patterned structured, short shutter videos, that show deinterlacing holes with all other traditional deinterlacers.
(zilogjones, this one is for your games ;) )

[tritical]

@scharfis_brain
Nice function. Your motion masking effectively does what my motion masking for TDeint2 does, though it doesn't have a sliding window and I do some spatial denoising prior to testing temporal differences in order to deal with noisy clips. Somehow I could bet yours runs faster :p.

@All
So here come some releases. First is [link removed], changes:
TDecimate:
+ speeded up some of the mmx functions that were added in the last release
+ modes 0, 1, and 3 now pre-compute metrics for the next needed cycle while
delivering frames for the current cycle in order to evenly distribute cpu
usage

TFM:
+ Added mmx versions of the isse scenechange routines
+ Optimized combed frame detection routines
Second is [link removed], changes: + Added edeint parameter
edeint works the same as "clip2" in tfm. It can be used to specify and external clip from which to take pixels instead of using one of TDeint's own interpolation routines. That means TDeint could use EEDI2 in the following way:

see this post for setting combinations (http://forum.doom9.org/showthread.php?p=748199#post748199)

or for a combo of eedi2/tdeint for deinterlacing frames for tivtc you can use:

1.) tff

interp = separatefields().selecteven().EEDI2(field=1)
deinted = tdeint(edeint=interp,order=1,field=1)
tfm(clip2 = deinted,order=1)

2.) bff

interp = separatefields().selecteven().EEDI2(field=0)
deinted = tdeint(edeint=interp,order=0,field=0)
tfm(clip2 = deinted,order=0)

Also, I noticed a mistake in the EEDI2 readme. Values 2/3 of the field parameter are switched. 2 actually starts with bottom and 3 actually starts with top.

Finally, I have been playing around with some possible ways of detecting junctions and corners in an image, which is where EEDI2 usually has problems, and a slightly modified version of the harris corner detection algorithm seems to do the job nicely. It completely avoids detecting plain diagonal lines while triggering on junctions and very complex areas. I'm probably going to add it as an optional step for avoiding artifacts.

[MacAddict]

Hmmm...Tdecimate is causing Vdub and VdubMOD to exit at the end of my scripts for some reason. This is the latest TIVTC v1.0 Beta 3. Using decimate() instead of tdecimate() resolves the issue on 2 film sources. Anyone else or do I have something strange going on?

I just went back to beta 2 and the script works fine. Perhaps the MMX speedups has caused this somehow in beta 3?

Edit-typo

[DarkNite]

Confirmed. It happens on both boxes here as well.

[tritical]

It is more likely the pre-buffering in modes 0, 1, and 3, cause the mmx speedups only effected ssd routines (requires ssd=true to be used) and one yuy2 luma difference routine. Plus, those mmx routines, if they are being used, get used on every frame so they would cause an error long before the end of the script. Also, I tested out all of the mmx routines on multiple clips, but didn't test a full encode (all the way to the end) with the pre-buffering :D. Will take a look.

EDIT:
Yeah it was the pre-buffering. I am guessing you both must be running windows xp sp2 cause TDecimate actually isn't crashing, it is throwing an avisynth error. Using a modified version of avisynth that doesn't have the little seh/c++ exception handling crash problem on sp2, this error reported in vdub:

"TDecimate: internal error during pre-buffering (%d,%d,%d)!"

Will put up a fix in a few minutes.

EDIT 2:

Here is a fixed version: [link removed]. Only change was one line of code to fix the end of clip processing in modes 0, 1, and 3. I will try to test things more thoroughly in the future :).

[DarkNite]

That was fast, thanks for the quick fix.

[manono]

Hi-

I don't know if I got the same thing or not. I didn't think much of it at the time, and didn't write down the error message VDubMod gave me, but after seeing the 2 other posts I thought I'd better report. This was with the new TDeint, using it as a bobber:

TDeint(Mode=1)
RePAL(Quality=3)

The message was something about VDubMod not responding and having locked. Can't really remember. The encode had completed, and near as I can tell, the video was complete. Using Win XP SP1.

[MacAddict]

Thanks tritical, that was very speedy indeed :-)

In all my cases Vdub/VdubMod was just exiting at the end of every script no matter how small or large the source file. Unfortunately my AVS version doesn't throw the exception here on XP SP2 :-\

[tritical]

@manono
I tried to reproduce your problem but wasn't able to... using tdeint(mode=1) both with and without repal in yv12 and yuy2. What was the rest of your script? and what was the source?

@All
I did notice another bug with TDeint though... it doesn't handle the edeint option correctly when mode=1. It checks for the edeint clip to have the same number of frames as the input clip, which is correct for mode=0, but should be 2x for mode=1.

@MacAddict
It actually does throw the exception... its just that due to a bug in one of xp sp2's dlls, mixing seh/c++ exception handling will cause a hard terminate. Avisynth no longer uses such a mix when the script is initially loaded (so any errors detected and reported by a filter in its constructor will be reported correctly in vdub), but still uses such a mix when requesting frames from the chain of filters (so any avisynth errors thrown by a filter during it's getframe() processing will cause vdub to hard terminate on xp sp2).

[Mug Funky]

@ manono: it didn't say "possible livelock" by any chance?

that's more a warning than an error - means at some point during the encode virtualdub didn't use any CPU cycles. this'll happen if some other program maxes out your CPU (and you don't have hyperthreading or something similar) for 10 seconds or more.

i get it a lot when i use virtualdub to export the audio out of an avs, and encode to mpeg-2 at the same time.

[manono]

Yes, that may have been it, Mug. I'll pay more careful attention the next time it happens. It happened after the encode had finished, I think. I wasn't around, and when I came back, the uncompressed Lagarith AVI was done and this message was sitting on the VDubMod screen. For what it's worth, here's the script:

LoadPlugin("F:\DivX Stuff\GKnot\DGDecode.dll")
LoadPlugin("F:\DivX Stuff\GKnot\TDeint.dll")
LoadPlugin("F:\DivX Stuff\GKnot\RemoveGrain.dll")
LoadPlugin("F:\DivX Stuff\GKnot\RePAL.dll")
LoadPlugin("F:\DivX Stuff\GKnot\Undot.dll")
mpeg2source("K:\March Of The Penguins\5-1\5-1.d2v")
Trim(0,94874)
TDeint(Mode=1)
RePAL(Quality=3)
Undot()
RemoveGrain()

Damn R1 March Of The Penguins has an extra that's a mix of 30fps interlaced footage and PAL2NTSC blended 25fps footage. I decided to RePAL the whole thing and see how it turned out.

[Chainmax]

I tried it on some natural video and it looks great there too; much better than a Lanczos resize.

Really? I have an immensely crappy 160x112 video I want to resize to 320x256, how would I go about using this filter for that?

[Guest]

You can't, because it can only double the height. But you can first use eedi2 to get to 160x224. Then resize with Lanczos. It should be at least better than just using Lanczos.

[mg262]

How about turnright().eedi2(...).turnleft()?

[Chainmax]

You can't, because it can only double the height. But you can first use eedi2 to get to 160x224. Then resize with Lanczos. It should be at least better than just using Lanczos.

Ok, so how do I do that? Would mg262's method work?

[Guest]

Ok, so how do I do that? My way:

eedi2() # 160x112 -> 160x224
lanczosresize(320,256) # -> 320x256

Would mg262's method work? What he gave is not complete. I suppose he's just saying that you can resize the width by turning. But he still has to get from 224 vertical to your required 256. So maybe he means this:

turnright().eedi2().turnleft() # 160x112 -> 320x112
eedi2() # -> 320x224
lanczosresize(320,256) -> 320x256

[mg262]

I suppose he's just saying that you can resize the width by turning.Yes, that's all I meant. Sorry if I was too brief -- I was posting in a hurry. I would also try both variants:

turnright().eedi2().turnleft() # 160x112 -> 320x112
eedi2() # -> 320x224
lanczosresize(320,256) #-> 320x256

eedi2() # 160x112 -> 320x112
turnright().eedi2().turnleft() #-> 320x224
lanczosresize(320,256) #-> 320x256

There probably won't be a difference, but it's hard to be certain without knowing exactly how the filter works... and it doesn't take long to try both. For general resolutions, I would also try overshooting the target resolution and then downsampling... but in this case, 224 and 256 are so close that I don't think it's worth trying.

[Chainmax]

Ok, which one of these three you prefer:

http://img476.imageshack.us/img476/2795/14ha.th.png (http://img476.imageshack.us/my.php?image=14ha.png)http://img476.imageshack.us/img476/7403/22uz.th.png (http://img476.imageshack.us/my.php?image=22uz.png)http://img476.imageshack.us/img476/1940/30sv.th.png (http://img476.imageshack.us/my.php?image=30sv.png)

?

[mg262]

Definitely not the second -- horribly blocky. There's not much between the first and the third, but I think I prefer the third. But both emphasise vertical features more than I would like.

[Chainmax]

What do you mean by that?

[mg262]

It looks like everything has been painted by someone who only understood how to make vertical strokes. That may just be a feature of the scene, of course.

[Chainmax]

Well, the second picture is the source with just lanczos and addborders, does it show that issue as well?

[mg262]

Now that you mention it, looking again, I think it does.

[Guest]

The size is not 320x256 as you said you required. Why are you changing the game?

[Chainmax]

The actual picture size is 320x256, I'm just adding borders to reach a DVD compliant resolution.