AlignFields

[kassandro]

AlignFields is a deinterlacer plugin. Actually it contains four different deinterlacers. My attempt was to preserve a maximum amount of detail combined with high compression ratios. For more details see the web site www.AlignFields.de.tf (http://www.AlignFields.de.tf).
2004|03|14 version 0.9 released (first public release)

[sh0dan]

Looks very interesting - I'm looking forward to testing it out!

Edit: Both Binary and Source code links are 404 :(

[Si]

Ref your documentation, KernelDeInt has motion-mapping.

regards
Simon

[morsa]

I cannot download the files.The links are dead.

[kassandro]

Originally posted by morsa
I cannot download the files.The links are dead.
Thank you for pointing this out. The files were there, but the links to them on the web site were wrong (false file names were false). I should have checked it.

[Mug Funky]

not bad at all.

i haven't had time to read the docs properly, however i'm getting some shimmer when using it as a bob filter.

also there's an issue with dropped frames - it seems to b0rk the motion detection and leaves either a combed frame or a pure black frame.

this is easily reproducible with the "duplicateframe()" command if you want to try it, but it makes sense for any model based on frame-differencing.

[edit]

works great if you want super-slow motion! try this on a pure interlaced stream:

doubleweave()
alignfields(tff=false,mode=3,fps2=true)

[kassandro]

Originally posted by Mug Funky
not bad at all.

i haven't had time to read the docs properly, however i'm getting some shimmer when using it as a bob filter.

also there's an issue with dropped frames - it seems to b0rk the motion detection and leaves either a combed frame or a pure black frame.

this is easily reproducible with the "duplicateframe()" command if you want to try it, but it makes sense for any model based on frame-differencing.

[edit]

works great if you want super-slow motion! try this on a pure interlaced stream:

doubleweave()
alignfields(tff=false,mode=3,fps2=true)

You should have read the documentation. If you use mode=3 you should always use should also scene=3, in order to handle sharp scene switches. I hope this solves your problems. I have deinterlaced already 5000-10000 minutes with AlignFields(mode=3, scene=3) but all these videos were top field first (digital satellite tv recordings). I have to check, whether there are problems with tff=false, by using crop(0,1,0-1), which should convert a top field first yuy2 clip into a bottom field first clip. If AlignFields(mode=3) is used without scene=3, then it behaves very badly at sharp scene switches. This mode should also not be used for videos with special effects like blinking large areas (as they occur often in music videos). When I return from CEBIT, I will finish a filter ImproveSceneSwitch as part of the RemoveDirt plugin, which will also be useful for AlignFields(mode=3). Please keep me informed about this shimmer, which you reported. I definitely want to get rid of it. If you use fps2=true or slomo=3, there will always be a little bit of shimmer with any filter, which provides such functionality, but I hope it will be minimal with mode=3. However, there should be no such shimmer for normal deinterlacing. In fact, it should soften the flickering pixels which are generated even by the most modern video cameras.

[kassandro]

Originally posted by Mug Funky
some shimmer when using it as a bob filter.

AlignFields is not very suitable as a bob (height doubling) filter, because even if you ignore motion detection completely, it tries to use as much information from the other field as possible. If you want to use it as bob filter use it always with ythreshold=0 and uvthreshold=0, to ignore motion detection. mode=0 should give the best and mode=3 the worst (very blurry) results. mode=0 incorporates a smart edge algorithm, which should handle well even sloping thin lines. This mode is quite slow, though. mode=3 uses a simplified form (6 neighbouring pixels instead of 10) of trbarry's weird bob, which is SSE fast. If there is demand, I could incorporate these algorithms into genuine bob filters, which then should yield better quality than the deinterlacer, which always try to use both fields as much as possible.
I also plan to make a contribution to the thread Smart edge filter (continued from rududu thread) (http://forum.doom9.org/showthread.php?s=&threadid=72174). There I would like to present a two dimensional mathematical optimality principle for resizing accompanied by a filter for doubling the height or both the height and the width. So far all resize filters are either one dimensional in nature (like the builtin filters) or use some cooking recipe like the two algorithms which are behind mode=0,1.

[Mug Funky]

hehe. the more smart bobbers out there the better.

PAL land requires extremely good (and hopefully fast) bobbers in order to get rid of that f**king field blending from NTSC->PAL conversions. without a smart bob that retains a maximum of detail (and a means of rejecting frames that are blends), viewing on progressive screens becomes quite a painful experience.

[morsa]

with these settings:

alignfields(mode=0,tff=false,topfield=false)

It gives me some ugly black and white orphan pixels, mostly on diagonals.Less with mode 1 and none with modes 2 and 3.
DV material PAL 720x576.

Talking about blurry against sharp, please don't take theory so seriously.For what I've seen and my own experience through these years, the blurry way only works well when you are seeing the video on a relative small display.When you go bigger you really notice that with a blurry deinterlacer (e.g. field blending) anything that moves get terribly and notoriously out of focus against its background.
You can make a comparison between a progressive image shot at shutter 1/50 and a blurry deinterlacer.Keep in mind that many, many times the movies you see at cinema are shot with faster shutters than 1/48, mostly action scenes, and nobody says the motion is jerky.
Modes 2 and 3 are really too blurry, they don't even look as their progressive counterparts.

[kassandro]

Originally posted by morsa
It gives me some ugly black and white orphan pixels, mostly on diagonals.Less with mode 1 and none with modes 2 and 3.
DV material PAL 720x576.
I would be very nice if you could post part (100x100 pixels should be enough) of the original and the deinterlaced frame, such that I can spot the problem.

[morsa]

Ok I'll post it on my page.Please read my editing of the above post.

[kassandro]

Originally posted by Mug Funky
hehe. PAL land requires extremely good (and hopefully fast) bobbers in order to get rid of that f**king field blending from NTSC->PAL conversions. without a smart bob that retains a maximum of detail (and a means of rejecting frames that are blends), viewing on progressive screens becomes quite a painful experience.
Fortunately, I experience field blending very rarely and I always throw away the such videos. However, we have often the much easier problem that for progessive cinema films we receive

T2 T3 T4 T5
B1 B2 B3 B4

instead of

T1 T2 T3 T4
B1 B2 B3 B4

and I hope to come up with a better solution for this problem than trbarry's Uncomb.

[morsa]

images posted at

http://www.geocities.com/morsa20002000/morsafilter.html?1077427198530

pay special attention to the tree on the left and to the ,I don't remember the english word, stick of the tool someone uses to make a hole on the ground....

[Mug Funky]

Fortunately, I experience field blending very rarely and I always throw away the such videos.

man, i wish i could do that. any PAL anime that wasn't a theatrical release will pretty much invariably be field-blended and converted from NTSC. there currently isn't a good way to make this conversion, but blends look okay on an interlaced monitor. try as i might i can't spot the blends in 30p->25i conversions unless i hit pause and skip through. but it makes backups a messy business. the only time blends look really ugly on an interlaced monitor is when converting 30i to 25i. then you get beating patterns on pans, etc.

if only i knew more maths and programming... i'd have a filter out that would reverse this process.

[scharfis_brain]

Fortunately, I experience field blending very rarely and I always throw away the such videos.

I completely desagree!

most of the imported american sitcoms etc. are fieldbelnded conversion. including startrek, x-files, buffy, and a LOT more!

for german readers, I've explained all known (to me, hehe) methods to convert a FILM (24fps) to PAL

http://home.arcor.de/scharfis_brain/ExotischesInterlacing/


I've read your manual of alignfields an do not understand what it makes differencing from the other deinterlacers out there.

A threshold based deinterlacer always work like this:
- build a motionmask out of the fields,
- supress static parts
- fill the areas detected as motion with the preferred kind of interpolated data.
this may be: nearest neighbor, bilinear/cubic, kernel or edge-direction (tomsmocomp, sangnom)

so I do not (theoretically) se the difference to your deinterlacer

btw. Me always needs a very good bobbing deinterlacer, because 'normal' deinterlacing always results in a loss of motion information.

Okay, after this theoretical critisism, I'll try out your filter and post some practical critisism later :)

[sh0dan]

Partially google translated version of Brains Exotic Deinterlacing (http://translate.google.com/translate?u=http%3A%2F%2Fhome.arcor.de%2Fscharfis_brain%2FExotischesInterlacing%2F&langpair=de%7Cen&hl=en&ie=UTF-8&oe=UTF-8&newwindow=1&prev=%2Flanguage_tools) page. (It seems to stop translation at some rather random place in the document)

[kassandro]

Originally posted by morsa
Talking about blurry against sharp, please don't take theory so seriously.For what I've seen and my own experience through these years, the blurry way only works well when you are seeing the video on a relative small display.When you go bigger you really notice that with a blurry deinterlacer (e.g. field blending) anything that moves get terribly and notoriously out of focus against its background.
You can make a comparison between a progressive image shot at shutter 1/50 and a blurry deinterlacer.Keep in mind that many, many times the movies you see at cinema are shot with faster shutters than 1/48, mostly action scenes, and nobody says the motion is jerky.
Modes 2 and 3 are really too blurry, they don't even look as their progressive counterparts.
Well, I only blur in those areas with motion which includes also a few flickering pixels. If you look at the average mathematical distance between the deinterlaced frame and the original frame, AlignFields, even with mode=3, has a relatively small distance compared with other deinterlacers. Of course, for deinterlacers which keep one field unchanged, you have to double the difference for a fair comparison.
My basic philosophy for deinterlacing is the following: if there is motion the eye should only see the larger details of the moving object, because the brain is already quite busy to digest the motion. Showing too much motion details may lead to an overflooding of the brain and the viewer feels uncomfortable, if that lasts too long. Now, when there is not much motion, the brain is idle and looks for something to do and it is then only natural to look at details more closely. I agree, modern film and video cameras have a much faster shutter speed than necessary, but people not used to such fast sharp action scenes are feeling uncomfortable. Those, who are used to such scenes, have simply learned to overlook most of the details, even if there are many available. Codecs react very similar. Temporal complexity has a much more negative impact on the compression rate than spatial complexity. That's why there is such a big difference between different kinds of blurring. The trivial blur deinterlacer dein[x,y] = (2*orig[x,y] + orig[x,y-1] + orig[x,y+1] + 2)/4 built into most encoders like Dr. Divx, MS WM9 encoder, etc. changes a lot more in the average than my mode=3, but the compression rates are far inferior. I just tested the bob().selecteven() deinterlacer. It is a sharp deinterlacer but completely discards one field and the compression ratio is nevertheless poor (39.976.469 bytes with my test file).

[morsa]

well, did you check the images?
Understand what I'm talking about now ? similar to TomsMoComp with search effort higher than 10.

[kassandro]

Originally posted by morsa
well, did you check the images?
Understand what I'm talking about now ? similar to TomsMoComp with search effort higher than 10.
I couldn't find any link to download!
I have found it! I simply didn't reload the page.

[scharfis_brain]

scroll down on morsa's site (the link posted by him above)
and then you'll see the example-pics.

(they show that the non-moving backgroung is getting deinterlaced)

this seems to confirm my tests, too.

non moving areas are still getting deinterlaced... :rolleyes:

[kassandro]

Originally posted by scharfis_brain
[i]for german readers, I've explained all known (to me, hehe) methods to convert a FILM (24fps) to PAL

http://home.arcor.de/scharfis_brain/ExotischesInterlacing/

Look's like a very fine explanation of how different videos can be from ordinary progressive material. I'll probably add a link to the next version of my documentation.

[i]
I've read your manual of alignfields an do not understand what it makes differencing from the other deinterlacers out there.

A threshold based deinterlacer always work like this:
- build a motionmask out of the fields,
- supress static parts
- fill the areas detected as motion with the preferred kind of interpolated data.
this may be: nearest neighbor, bilinear/cubic, kernel or edge-direction (tomsmocomp, sangnom)

so I do not (theoretically) se the difference to your deinterlacer
[/QUOTE]
From that very crude perspective, you are right: There is nothing new with AlignFields and it is virutally impossible to do something new.
But the current deinterlacer do not fully implement the above design.
A good deinterlacer should never change a clip with identical frames, but currently all deinterlacers do just this. To say it bluntly: they are all cheating, they do not adhere to the "no motion no change" principle In the documentation I have provided a simple script to test a deinterlacer for this principle. Thus our first
aim for AlignField was a full and true implementation of the no motion no change principle.
Secondly, I wanted to explore interpolation techniques which are particularily favorable for compression (mode=2,3). All the interpolation techniques mentioned by you are one field only interpolation (sharp deinterlacing) and with this kind of interpolation it is impossible to get high compression ratios without additional blurring like TomsMoComp(1,5,1). The interpolation techniques which give both fields equal weight (blur deinterlacing) deserve at least the same amount of attention. The interpolation theme is by no means exhausted.

[scharfis_brain]

softdeinterlacing=blended-sharpdeinterlacing

is this assumption correct?

this means

a=dgbob() # or any other bobber preferable my bobmatcher :p
layer(a,a.trim(1,0),"fast")
selecteven()

should give a similar, well compressible video

even better compressive would be something like this:

a=dgbob()
b1=a.deleteframe(0) #future
b2=a #present
b3=a.duplicateframe(0) #past
layer(layer(b1,b3,"fast"),b2,"fast")
selecteven()

imo dgbob (i dislike it)
gives more image definition on static parts, than your align-fields-deinterlacer, but your deinterlacer has the better interpolation.

I do always use sharp-deinterlacing for 50i video, because I'll get the cinema-look (1/50 sec shutter)
soft-deinterlacing will simulate a 1/25 sec shutter which is a bit too blurry and soft for my taste.

But thats a question of taste. I think a lot of people can get happy with your deinterlacer, because its pretty fast.

[kassandro]

Originally posted by scharfis_brain
scroll down on morsa's site (the link posted by him above)
and then you'll see the example-pics.

(they show that the non-moving backgroung is getting deinterlaced)

this seems to confirm my tests, too.

non moving areas are still getting deinterlaced... :rolleyes:
I have found some orphane looking dark grey pixels on the left chromium border of the car window. Clearly they are a consequence of deinterlacing. Hence there must have been some kind of motion. It cannot be the guy in front, otherwise the combs in the original frame would be larger. It is also not likely that it was caused by a slight movement of the car. My best explanation is that this was caused by flickering reflection of the sun (even the best video cameras generate some flicker). For a definitive explanation, why there was deinterlacing, I would need also the previous or the subsequent frame depending on the values of the tff and topfield variable.
Now an inspection of these orphane pixels under high magnification shows that they are not really orphane. In fact, there is always a 45 degree diagonal of three similar pixels and the algorithm has determined this diagonal as the optimal diagonal (it always has a choice of three diagonal, trbarry has even 5 diagonals). mode=0,1 emphasize edges and mode=0 also thin lines. Thus the interpolation is okay, but the pixels there should have been left unchanged. All and all, if I look at the guy in front, it did a good job in removing the combs.

[morsa]

Sorry to tell you this but if you look to the image with a little more attention, you´ll see that those artifacts I´m talking about are everywhere on the image, the trees the man's face, the man´s shirt, the tool beside the guy on the left and yes, the car.
For me it is not a matter of if it is being deinterlaced or not (I'm really happy with its quality), but a problem of the interpolator (the same happens with Tom's) but seeing that they are near black, near white, I guess a simple way of checking every interpolated zone against its sorroundings or before value could be implemented as an option, Am I crazy?.

I would try to do it myself, but these days I really lack the time...

[kassandro]

Originally posted by morsa
Sorry to tell you this but if you look to the image with a little more attention, you´ll see that those artifacts I´m talking about are everywhere on the image, the trees the man's face, the man´s shirt, the tool beside the guy on the left and yes, the car.
For me it is not a matter of if it is being deinterlaced or not (I'm really happy with its quality), but a problem of the interpolator (the same happens with Tom's) but seeing that they are near black, near white, I guess a simple way of checking every interpolated zone against its sorroundings or before value could be implemented as an option, Am I crazy?.

I would try to do it myself, but these days I really lack the time...
There is no need to be sorry. In fact, I appreciate any critical comment as long as it is constructive and your criticism is certainly constructive, because it is underpinned by concrete pictures. Unfortunately this is the last day until march 25, that I can run any tests, because I am at CEBIT beginning tomorrow. If there wouldn't have been this stupid dead link mistake of mine (I wondered already about sh0dan's remark), I wouldn't have the hassle now. So I will certainly come back to your problem, but it will take a while.

[kassandro]

Originally posted by scharfis_brain
softdeinterlacing=blended-sharpdeinterlacing

is this assumption correct?

a=dgbob() # or any other bobber preferable my bobmatcher :p
layer(a,a.trim(1,0),"fast")
selecteven()

should give a similar, well compressible video

If I am right about DGBob, then it gives both fields equal weight. Hence it is a true blur deinterlacer. With my standard test file I obtained the following results (I had to convert to yuy2 because of the layer filter) : 9-10 fps, 36.855.788 bytes output size. Though you do much more blurring than AlignFields(mode=3) your compression ratio is relatively poor. Why that? If topfield=true and tff=true, then I use the top and the bottom field of the current frame as well as the bottom field of the previous frame for interpolation (I don't use the top field of the previous frame!). The current bottom field is 1/50 s ahead of the current topfield, while the previous bottom field is 1/50 s behind the current topfield. Thus giving the current and the previous bottom equal weight cancels the time bias of the bottom field. This purely theoretical thought obviously bodes well for codecs. Also I have always three transition pixels between interpolation and non-interpolation areas. This is very dct friendly. Furthermore, all current blur deinterlacer use only vertical interpolation. However, it looks better and gives better compression to treat the horizontal direction equally. Altogether there is a huge difference between smart and brainless interpolation as far as compression is concerned. Let's try the next super blurrer:


even better compressive would be something like this:

a=dgbob()
b1=a.deleteframe(0) #future
b2=a #present
b3=a.duplicateframe(0) #past
layer(layer(b1,b3,"fast"),b2,"fast")
selecteven()

This beast makes only 6-7 fps (even divx 5.1.1 with bframes is faster)
and the output size is still 34.755.449 bytes. At least you are now third in the compression ranking, but you still can't play in the same league as AlignFields(mode=3, scene=3) and you have to pay with a lot of blurriness. Also, you really can't use the above blurrers as deinterlacers, because they behave very poorly at sharp scene switches (the layer filter is the evil guy in that respect), even more poorly than AlignFields(mode=3, scene=0). So you really need a layer filter with scene switch protection.
Here is the script I have used

orig=MPEG2Source("input3.d2v")
orig=AvsTimer(orig, name="mpeg2dec", type=2, total=false)
converttoyuy2(orig)
a=dgbob(1)
b1=a.deleteframe(0) #future
b2=a #present
b3=a.duplicateframe(0) #past
layer(layer(b1,b3,"fast"),b2,"fast")
selecteven()
AvsTimer(frames=200, name="deinterlace", type=2, difference=1)
crop(12,4,-20,-4)



imo dgbob (i dislike it)
gives more image definition on static parts, than your align-fields-deinterlacer, but your deinterlacer has the better interpolation.

What is more image definition? If there is no motion and no camera flicker AlignFields won't change anything, if the horizontal distance to a motion pixel is more than 11 pixels (in the average a 5.5 pixels distance is enough).


I do always use sharp-deinterlacing for 50i video, because I'll get the cinema-look (1/50 sec shutter)
soft-deinterlacing will simulate a 1/25 sec shutter which is a bit too blurry and soft for my taste.

Clearly sharp deinterlacing with 50 fps looks cool, but you have always a significant amout of shimmer between odd and even frames. With AlignFields(mode=3, scene=3, fps2=true) you have significantly less shimmer and much better compression, though moving objects are clearly less sharp, if the interlaced original was shot with a good camera.

[scharfis_brain]

hm.. I don't really get into your stuff.

I have to think about this.

had you had a look on my bobmatcher?
especially the routine that deinterlaces pure-video-parts by using
previous and future field to interpolate over the current field.


bwt. dgbob gives the priority only to the current field. the other field (its EITHER the next OR the previous one, I dont't know, but it is always one of them) is only used, if no motion is present (both fields contain same image) if motion relatively to the other field is present, dgbob does its ugly kind of pixel duplication to fill the combed areas. this means that dgbob is a sharp-deinterlacer according to your definition.

with 'definition' I meant, that alignfields deinterlaces rock-solid-static-areas, which dgbob or any other good thresholded deinterlacer doesn't touch.

[kassandro]

Use show=true to see the pixels, which are deinterlaced. However, the transition pixels are not shown with this option.

[kassandro]

My script contained a mistake. Instead of converttoyuy2(orig) one has to take converttoyuy2(orig, interlaced=true). Surprisingly, this had very little impact on output size. I obtained 34.630.731 bytes. The same mistake was done with the first filter, but I won't repeat the benchmark.

[scharfis_brain]

okay, I've played a little bit with its threshold and now got the static areas untouched, but at the cost of remained combing.

Your filter seems to be very sensitive to noise (my test-clip has a very low noise level). this means it deinterlaces noise which is resulting in shimmering high detailed static areas.

[kassandro]

Originally posted by scharfis_brain
okay, I've played a little bit with its threshold and now got the static areas untouched, but at the cost of remained combing.

Your filter seems to be very sensitive to noise (my test-clip has a very low noise level). this means it deinterlaces noise which is resulting in shimmering high detailed static areas.
This is true. Actually I don't really know how a digital video camera works. An analog video camera records one pixel after the other, just as the electron beam of the tv tube draws one pixel after the other on the phosphorescence layer. Thus for an analog video camera interlace makes a lot of sense. However, a digital video should record all pixels in one stroke like a digital photo camera or a chemical film camera. Interlace simply doesn't make sense for such a camera. It should only emulate interlace to be tv compatible, but then there should not be this kind of noise. The noise may also be mpeg2 compression noise. It can be visualized with show=true.
The noise has a negative impact on compression, whence it is a good idea that AlignFields takes care of it.

[Mug Funky]

[quote]Interlace simply doesn't make sense for such a camera.{/quote]

hehehe. but that doesn't stop the true progressive cameras starting at $20k...

i'm not entirely sure how consumer-level digicams work, but it could be a matter of a single-line CCD and a scanning action (the earlier broadcast video cameras and telecine devices had these, and in fact the highest-end telecine machines today still have a single line CCD in order to keep the film running at a constant speed)

but all the DV cams i've used (crap or otherwise) work best in interlace. even broadcast digibeta cams give their best detail in interlace mode (ie. smart deinterlacing later will preserve more vertical detail than shooting in progressive mode).

and other nasty DV cam things are dropped frames - with a true "no motion no change" scheme, a dropped fram will be passed through untouched, combs and all, as it is a duplicate of the last frame (the computer experiences an underflow, knows it should have captured a frame, and so it just writes the last good frame it could find, hoping nobody will notice :)) this of course happens while capturing, not shooting. (and shouldn't happen at all if your 1394 card + HDD + OS can handle the throughput)

[kassandro]

Originally posted by Mug Funky

hehehe. but that doesn't stop the true progressive cameras starting at $20k...

Well, but the Fuji S602 a photo camera, can make videos at 30 fps with a resolution of 640x480 and it is hard to imagine that it produces interlaced video.


i'm not entirely sure how consumer-level digicams work, but it could be a matter of a single-line CCD and a scanning action (the earlier broadcast video cameras and telecine devices had these, and in fact the highest-end telecine machines today still have a single line CCD in order to keep the film running at a constant speed)

It would be really amazing, if digicams would work like a fast scanner. Because of the speed the mechanical strain for such a device would be enormous, because an interlaced single line CCD has to move twice over the whole picture. Thus for 60 minute video the CCD has to move 180000 times up and down.


and other nasty DV cam things are dropped frames - with a true "no motion no change" scheme, a dropped fram will be passed through untouched, combs and all, as it is a duplicate of the last frame (the computer experiences an underflow, knows it should have captured a frame, and so it just writes the last good frame it could find, hoping nobody will notice :)) this of course happens while capturing, not shooting. (and shouldn't happen at all if your 1394 card + HDD + OS can handle the throughput)
This is true. Duplicate frames do not bode well for the no motion no change principle, because one of the frames is left unchanged.

[scharfis_brain]

ccd-cams are internally either proceesing 50fps progressive with later reinterlacing like separatefields.selectevery(4,0,3).weave does.

Or the video is already read out in an interlaced way like first only collecting odd lines from the ccd and then the even ones.

since photo-cams are pure-progressive - devices they do not know anything about interlacing. so it would be complicatet to output a interlaced 60fps-video

the same thing in DV-Cams: they are built to collect interlaced video, but not for progressive video. This mean, that progressive video on existant consumer-solutions will be a large HACK (deinterlacing -> loss of resolution -> useless).

True Progressive will only be clean possible on a completely redisgned product. And this will be too expensive IMO.

[morsa]

Well, I've been using progressive cameras for about 3 1/2 years.
The things discussed here has nothing to be with reality, sorry :)
Every CCD in the world is naturally progressive, what is not progressive is the circuitry coupled to it.
With the new arrival of CMOS tecnology this is changing really fast, in a couple of years expect that most camera will be progressive.
DV looks far better when you use a progressive CCD, because of its crappy compression scheme (interfield would be a right name)Dv doesn´t like interlaced video and blurs it too much.
What scharfis says is right, except for the expensive stuff and those things.
You don´t need to redesign for example a digibeta to record progressive, you just need to change its CCD for a progressive one and everything goes perfectly right.(believe we've test it at some friends laboratory)

[acrespo]

I have many red dots in all video, mainly in black parts. My source is PIC MJPEG anime analog video.

[kassandro]

Originally posted by acrespo
I have many red dots in all video, mainly in black parts. My source is PIC MJPEG anime analog video.
What variables do you use? Especially the value of the mode variable is important. I would appreciate, if you could post the original frame and a badly processed frame (parts of the frames should be sufficient), but I can only make a look at it on thurday, when I come home.

[acrespo]

Recently, I changed my filters and I found one that generate the red dots. Sorry, forget my wrong report.

[kassandro]

Originally posted by morsa
images posted at

http://www.geocities.com/morsa20002000/morsafilter.html?1077427198530

pay special attention to the tree on the left and to the ,I don't remember the english word, stick of the tool someone uses to make a hole on the ground....
I surrender! mode=0,1 will be replaced. I simply tried the impossible. While these smart edge methods work well in some cases they produce arifacts like the ones described by morsa in other cases.
The new modes will emphasize minimal oscillation with the neighbouring pixels. Such kind of interpolation will avoid orphane pixels and will yield higher compression ratios. On the other hand, thin lines will not be handled well, but that seems to be less of a problem. One simply cannot have both.

[morsa]

But, I like the sharpness of mode 0 and 1.
Can't these wrong pixels be corrected as a postprocessing based upon ther neighbour pixels or their before ones (I mean before deinterlacing) ?

[acrespo]

I am a newbie with interlaced content, but as I understood, all blur deinterlacer blends, right?
I think the interpolate method of sharp deinterlace is line based, because my analog anime content is very bad with this kind of deinterlacer (edges are not "connected" between lines) .
Mode = 2 is perfect on edges for me, because eliminate the "edges are not connected between lines" effect completly, but I have a lot of ghosts (blends). There is any parameter or other filter for eliminate these ghosts?
The only way to eliminate my dot crawls is with TomsMoComp (1,5,0) or AlignFields(mode=2). Tomsmocomp is not perfect but don't have ghost.

There is a possible to create a new method with the best of Mode = 2 and TomsMoComp (1,5,0)? In other words, with better edges and less ghosts?

[kassandro]

Originally posted by acrespo
I am a newbie with interlaced content, but as I understood, all blur deinterlacer blends, right?

This is correct.


I think the interpolate method of sharp deinterlace is line based, because my analog anime content is very bad with this kind of deinterlacer (edges are not "connected" between lines) .

I made at a thorough look at the source code of Tomsmocomp and essentially I learned SSE programming from it. I think Trbarry tried very hard within Tomsmocomp to connect edges across lines. Essentially it connects those pixels from the line above and below which are the closest. Not only the vertical direction but also diagonal directions are considered. Within his "weird bob" function (part of Tomsmocomp) Trbarry considers even 4 diagonal directions. For my mode=0, and mode=1 I consider only 2 diagonal direction. The other two diagonals of tomsmocomp are - in my opinion - too far away and increase the risk of artifiacts. You may try my mode=0 and mode=1 (this mode is somewhat similar to TomsMoComp (1,5,0) but with 2 diagonals only. But all "smart edge" techniques must fail under certain circumstances and will creat artifacts, because it is simply not possible to creat new detail through interpolation. TomsMoComp (1,5,1) removes some of the artifacts of TomsMoComp (1,5,0) and yields improved compression.


Mode = 2 is perfect on edges for me, because eliminate the "edges are not connected between lines" effect completly, but I have a lot of ghosts (blends). There is any parameter or other filter for eliminate these ghosts?

It is the nature of blur deinterlacers that you get these ghosts. With my mode=3 you may even get two ghosts. Usually these ghosts don't hurt if motion is not sharp anyway (this is the case with more than 90% of all videos). However, if a video is shot with a very fast shutter speed, i.e. the motion is very sharp, then the ghosts created by blur deinterlacers may look very ugly.
I am not an anime expert, but I haven't seen any, which are really interlaced. In fact, within anime video you have usually a lot of frame duplication. However, that doesn't mean at all that anime videos are progressive. Two things may happen. Firstly, there may be a field shift, i.e. the bottom field of the current frame really belongs to the top frame of the next frame or the previous frame. A sharp deinterlacer, usually takes care of such a situation, though it is certainly not the optimal solution. Secondly, there may be blended fields. A sharp deinterlacer usually keeps one field unchanged and interpolates the other. If the unchanged field is sharp then everything is ok. However, if the unchanged field is blended, then you just get garbage. Unfortunately, in such videos blending alternates between both fields and a sharp deinterlacer is not a good solution. A blur deinterlacer should not be used either for anime, because the motion is normally very sharp and you get the very unpleasant ghosts, described by you.


There is a possible to create a new method with the best of Mode = 2 and TomsMoComp (1,5,0)? In other words, with better edges and less ghosts?
You may try other deinterlacers. Kerneldeint is a favorite of many contributors here.

[You Know]

I have try ImproveSceneSwitch and this is result

Original Strip (http://wwwstud.dsi.unive.it/~nfalco/gto/strike.jpg)

inp = MPEG2Source("F:\gto\gto.d2v",iPP=true)
out = inp
return ImproveSceneSwitch(inp,ratio=2)

Result (http://wwwstud.dsi.unive.it/~nfalco/gto/strikeA.jpg)

so i try this way

MPEG2Source("F:\gto\gto.d2v",iPP=true)
inp = last

AssumeTFF().SeparateFields()
even = SelectEven().BilinearResize(720,576)
odd = SelectOdd().BilinearResize(720,576)

odd = ImproveSceneSwitch(odd, inp,ratio=2).VerticalReduceBy2()
even = ImproveSceneSwitch(even, inp,ratio=2).VerticalReduceBy2()

return interleave(even, odd).Weave()

Result separating field (http://wwwstud.dsi.unive.it/~nfalco/gto/strikeB.jpg)

I try deinterlacing source

Deinterlaced source (http://wwwstud.dsi.unive.it/~nfalco/gto/Strikedeint.jpg)

and lauch this script

inp = MPEG2Source("F:\gto\gto.d2v",iPP=true).AssumeTFF()
out = inp.FieldDeinterlace(blend=false)

return ImproveSceneSwitch(out, inp,ratio=2)

Result on deinterlaced source (http://wwwstud.dsi.unive.it/~nfalco/gto/strikedeintA.jpg)

more than ratio=2 ImproveSceneSwitch miss switch but hit switch where there are not, I tested virtualdubmod sceneswitch on same deinterlaced material and work better.
The problem is that in this filter miss possibility of specify how many frame duplicate for example this filter change sequence ABCD with AADD, but 99% of case on anime repair is more useful change ABCDEF with AAAFFF or with ABBFFF, leave user decide how frame copy.

If you can improve your filter it will be the base for anime restore (gto, harlock, under arrest, starblazers, evangelion (not renewal) ecc ecc ecc)

[kassandro]

Sorry, You Know
for not having answered your private message and answering your posting so late, but at the moment I have not enough time (but that will hopefully improve soon).

more than ratio=2 ImproveSceneSwitch miss switch but hit switch where there are not, I tested virtualdubmod sceneswitch on same deinterlaced material and work better.

I think ratio=2 is far too low. With ratio=2 fast motion can be easily confused with a scene switch. I don't know about vdubmod's scene switch detection. For what purpose does it need one? During encoding scene switch detection is made by the codec and not by vdubmod and the scene switch detection of codecs is not very impressive though a codec could use the results of its very slow motion vector search also for scene switch detection (probably it does so). ImproveSceneSwitch must be a fast filter and therefore cannot use such very slow techniques. It will never be error free and therefore the ratio variable has to be chosen conservatively. You simply use ImproveSceneSwitch for a task for which it was not intended. Having said that, I can improve the scene switch detection capabilities of ImproveSceneSwitch by replacing the simple difference based method by a more sophisticated fluctuation and difference based method and the speed penalty will be moderate.

The problem is that in this filter miss possibility of specify how many frame duplicate for example this filter change sequence ABCD with AADD, but 99% of case on anime repair is more useful change ABCDEF with AAAFFF or with ABBFFF, leave user decide how frame copy.

This is easier to do, but again I didn't have such applications in mind. I probably return to ImproveSceneSwitch and the related problem of duplicate frames in August or September. So you have to be patient. The problem with your clip is not scene switch detection, rather you have the problem that the fields do not fit together at all
(one field belongs to the old scene, while the other belongs to the new scene). Your pic strikeA pic shows that ImproveSceneSwitch did detect the scene and did convert ABCD into AADD. Unfortunately the frame D is a bad frame again and that's the problem.

[You Know]

don't worry, i will attend next mouth, until then i try to do by script.

THANKS

[cwolf]

One side effect of Alignfields mode=3 is the rainbow removal!

I was so pleased that from now on I will always capture interlaced and use Alignfields for 1-removing rainbows and 2-do some cleaning because my source is noisy (my coaxial and composite cables suck, or maybe it's Ati all-in-wonder's fault, plus I don't have S-video output from my settop-box).

About Improvesceneswitch: I have scene changes (interlaced) that have mixed fields from previous and next scene. Given scenes a and b I have:
[frame|frame]
aa|bb => perfect scene switch (ok)
aa|ab|bb => first frame of scene b has a field from previous scene, or is it
.............last frame of scene a has a field from next scene?
ac|bb => c = a + b, i.e, a blend of previous and next fields/scenes
aa|cb => idem

So, to make Improvesceneswitch work and get most of the scene changes, my script has it twice, so that if one fails the other catches it:
Improvesceneswitch(orig,ratio=3,field=2,last=true,first=true)
Improvesceneswitch(orig,ratio=3,field=1,last=true,first=true)

And because of fields of type c it sometimes fails to detect a scene switch, unless I low ratio but I cannot do it.

So, I was thinking of a Improvesceneswitch at field level, that is, doubling one field to hide the alien field to the scene, and putting it before Alignfields or maybe Alignfields could do it. Well, that is my wish...
Cecilia

[kassandro]

Originally posted by cwolf

About Improvesceneswitch: I have scene changes (interlaced) that have mixed fields from previous and next scene. Given scenes a and b I have:
[frame|frame]
aa|bb => perfect scene switch (ok)
aa|ab|bb => first frame of scene b has a field from previous scene, or is it
.............last frame of scene a has a field from next scene?
ac|bb => c = a + b, i.e, a blend of previous and next fields/scenes
aa|cb => idem


I have never seen blended fields in a truely interlaced video, though it may be used for PAL/NTSC and NTSC/PAL conversion of interlaced material. I have seen blended fields in videos of progressive origin, primarily anime. In general for a video with blended fields, these should be unblended first. Of course, this is easier said than done.
ImproveSceneSwitch is simply not prepared for blended fields and blending essentially transforms a sharp scene change into a soft one, which ImproveSceneSwitch shouldn't detect. On the other hand, because you the scene change is sharp in the other field it should be caught, if you use ImproveSceneSwitch twice as you did. To be more specific, if you use AlignFields(mode=3, tff=true, topfield=true), which is indicated by your choice of ImproveSceneSwitch parameters, then you
should use first Improvesceneswitch(orig, field=2,last=false,first=true) to catch aa|bb, aa|ab|bb and aa|cb and to get aa|bb, aa|bb|bb and aa|bb. Then you should use Improvesceneswitch for a second time with Improvesceneswitch(orig, field=1,last=true,first=true) to catch ac|bb and to get aa|bb. Unfortunately, the second application catches again aa|bb, whence for such a normal sharp scene switch, both frames are doubled though only the first frame of the new scene requires doubling. Thus, essentially you did the best possible, but you could be more restrictive with first=true and last=true, though it doesn't really matter for a normal sharp scene switch.


And because of fields of type c it sometimes fails to detect a scene switch, unless I low ratio but I cannot do it.

If there is at least one field with a sharp scene switch, at least one of the two applications of Improvesceneswitch should catch it. Of course, a more sophisticated routine for measuring frame differences is desirable to use higher ratio values. I personally use higher ratio values to avoid jerkiness caused by frame doubling of motion frames.


So, I was thinking of a Improvesceneswitch at field level, that is, doubling one field to hide the alien field to the scene, and putting it before Alignfields or maybe Alignfields could do it. Well, that is my wish...
Cecilia
Of course, you could use Improvesceneswitch before AlignFields and you can apply it on fields instead of frames, by separating the clip into two, one for the top and one for the bottom field. However, you can never get rid of blended fields this way and that's the key problem here.

[acrespo]

VirtualDubMod always crash without any message when I close this AVS:

LoadPlugin("d:\encodes\filtros\degrainmedian.dll")
LoadPlugin("d:\encodes\filtros\Decomb521.dll")
LoadPlugin("d:\encodes\filtros\dup.dll")
LoadPlugin("d:\encodes\filtros\dgdecode.dll")
LoadPlugin("d:\encodes\filtros\mpasource.dll")
LoadPlugin("d:\encodes\filtros\AlignFields.dll")

v=MPEG2Source("d:\tenchi2.d2v")
a=MpaSource("d:\tenchi2 MPA T01 DELAY 0ms.mpa")
AudioDub(v,a)

AlignFields()
Decimate(5)

Crop(16,16,-16,0,align=true)
BicubicResize(640,480)
TemporalSoften(4,8,8,mode=2,scenechange=10)
DeGrainMedian(mode=1)
dup(threshold=1,blend=true,maxcopies=8)

Amplify(2)

str = "WAS - DC Hub (wasbr.com) " + Time("%d") + "/" + Time("%m") + "/" + Time("%Y")
Subtitle (str,10,7,0,240,"Courier New", 14)
Subtitle ("E-Mail: was@wasbr.com",10,18,0,240,"Courier New",14)
Subtitle ("WAS",540,44,0,300000,"Courier New",26)

I did other AVS files that crash virtualdubmod too. Change to mode=1 or mode=0 solve my problem, but I need mode=2 for this case!

[acrespo]

I found a way to solve the problem.

ConvertToYUY2(interlaced=true)
AlignFields()
ConvertToYV12()

There is something wrong with mode = 2 and YV12 colorspace.