Deshaker by Gunnar Thalin

[Diamenz]

had to read that a couple of times get it, but i do now. thanks for the reply guth. great plugin.

[Dogway]

I have been struggling with the source pixel aspect ratio setting in the filter. I want to set it to 0.888 as a NTSC 4:3 PAR, will the filter let me choose this? or do I have to stick to 0.912? Another thing is: is it better to crop after the deshaking? that is leaving some black borders for Deshaker to estimate better.

btw. What does PAR have to be with deshaking? some better motion estimation?

[wonkey_monkey]

btw. What does PAR have to be with deshaking? some better motion estimation?

Far be it for me to speak for guth, but PAR affects how a rotation is performed.

0.912 is the closest AR for NTSC (I think it's actually 0.909), because of nominal analogue blanking. What's your source, and how have you determined that the PAR is 0.888?

Another thing is: is it better to crop after the deshaking?

You can do, but Deshaker also has the "Ignore pixels" parameters. I'm not sure which will work better, or why...

David

[guth]

Originally Posted by Dogway

I have been struggling with the source pixel aspect ratio setting in the filter. I want to set it to 0.888 as a NTSC 4:3 PAR, will the filter let me choose this? or do I have to stick to 0.912?

When I looked into this a few years ago, I believe Adobe were the only ones I found who used 0.888, but they seem to have changed that lately too:
http://blogs.adobe.com/toddkopriva/2...n-after-e.html

Anyway, the only way to be sure about what PAR your camcorder uses, is to measure it from the actual video (by filming a circle for example).

And you can enter any PAR value you want in Deshaker. (RTFM! )

And yes, the PAR is important for handling rotation and zoom correctly, and also if you use different PAR values for source and destination.

The reason Deshaker's preset is appr. 0.912 instead of appr. 0.909 is because I was convinced by that web page, but since most video applications out there seem to use 0.909 I may reconsider, even if it's not correct.

Originally Posted by Dogway

Another thing is: is it better to crop after the deshaking? that is leaving some black borders for Deshaker to estimate better.

Deshaker prefers not to see any borders during pass 1. They interfere with the motion estimation. You should remove them either by cropping or using 'ignore pixels'. If you use 'previous and future frames to fill in borders' for pass 2, you should definitely crop any borders before deshaking.

[Dogway]

This is my source. I calculated PAR on the well known 8:9 value for 4:3 NTSC. I have also tried the 4320/4739 PAR on other similar sources (NTSC DVD with black bars on both sides) but they looked better in 8:9 (checking some circles of the footage and general appearance).

guth: Thank you, yes I tried to just input the value, and I got the same PAR I originally had in the .m2t (1.5 DAR), with 0.912 I was getting 1.4xx instead of the original 1.5, but I was unsure if it had some relation on the PAR value.

[wonkey_monkey]

The reason Deshaker's preset is appr. 0.912 instead of appr. 0.909 is because I was convinced by that web page, but since most video applications out there seem to use 0.909 I may reconsider, even if it's not correct.

AIUI, 702 (which would lead you to a PAR of 0.912 for NTSC video) is the "correct" width only for PAL video, whereas NTSC uses 704 pixels:

PAL: 576/(702*3/4)=1.09402
NTSC: 480/(704*3/4)=0.909091

Both the NTSC values we're discussing (0.909, 0.912) do account for NAB, but different amounts. If you don't account for NAB at all, you end up with 0.888, and only careful experimentation will tell you whether your camera is made up "correctly" (the difference is, at most, less than 3%).

David

[Dogway]

Well, I dont digitalize video, just old animation so normally the content I work with is NTSC DVD. My question is whether having the black bars do I have to actually take into account NAB in the 100% of the cases or if it depends on every telecined source.

[guth]

Originally Posted by davidhorman

AIUI, 702 (which would lead you to a PAR of 0.912 for NTSC video) is the "correct" width only for PAL video, whereas NTSC uses 704 pixels:

PAL: 576/(702*3/4)=1.09402
NTSC: 480/(704*3/4)=0.909091

I don't use 702 for NTSC, I use 710.85.
According to this page, which I still believe is the truth, it should be calculated like this:

PAL: 576/(702*3/4)=1.09402...
NTSC: 486/(710.85*3/4)=0.91158...

[guth]

Originally Posted by Dogway

Well, I dont digitalize video, just old animation so normally the content I work with is NTSC DVD. My question is whether having the black bars do I have to actually take into account NAB in the 100% of the cases or if it depends on every telecined source.

I'm afraid I don't understand what you mean. I don't even know what NAB means...

But in case it solves anything for you, the aspect ratio of a pixel (ie the PAR) doesn't change just beacuse the video has borders or not, or if you crop, or not.

Finally, I didn't know you wanted to use Deshaker for stabilizing that kind of video. Deshaker was designed to stabilize unwanted camera motion, not really other kinds of shakes, even if it can do that sometimes too. In your case, it might actually be better to include the borders during pass 1, at least when the animation background isn't supposed to move.

[Dogway]

NAB

Because if I have the black bars (NAB) I would have to assume 704 width, therefore indicating my source is PAR 0.909. So my question is whether this only applies for direct digitalization (analog->digital) or it stands as well for DVD's digital content previous digitalized. Otherwise I would just need to assume PAR 0.888. I mean, I would like to know what do I have to base on to know if the manufacturer assumed 0.888 or 0.909. Mainly because when I do play any DVD (NTSC) on my laptop the object geometry is the same as using 0.888, and in practice it feels more natural than 0.909. Manufacturers must be doing it wrong? Id like to see examples on this.

Sorry this talk derived to AR, its something Ive been carrying on long time.

I cant differentiate between camera shake or other shakes, other than floating cels in case of animations(?)

[guth]

Originally Posted by Dogway

Because if I have the black bars (NAB) I would have to assume 704 width, therefore indicating my source is PAR 0.909. So my question is whether this only applies for direct digitalization (analog->digital) or it stands as well for DVD's digital content previous digitalized. Otherwise I would just need to assume PAR 0.888. I mean, I would like to know what do I have to base on to know if the manufacturer assumed 0.888 or 0.909. Mainly because when I do play any DVD (NTSC) on my laptop the object geometry is the same as using 0.888, and in practice it feels more natural than 0.909. Manufacturers must be doing it wrong?

I'm no expert on this subject, but I don't think the black bars tell you anything about the PAR. The table on the page I referred to above says that the sampling matrices 720x486, 720x480, 711x486, 704x486 and 704x480 all share the same PAR, namely 4320/4739. The table also mentions DV, DVB and DVD for that PAR.

If you think 0.888 looks better, maybe you're fooling your brain to think so, because you want it to be that way, or maybe you're used to looking at video like that, or... maybe the manufacturers are wrong. But I really don't think 0.888 is ever the correct PAR to use (except for correcting other's mistakes).

[Dogway]

I have been doing some checks between different PAR screenshots and some original sketches from storyboards, and yes it seems to be 0.912 or 0.909, rather 0.909 I think. I think that what it was fooling me was the CGI circle, wrongly implemented into the animation (PAR wise), so anyway, who knows I will stick to 10:11 and see if that fully satisfies me, at least for the hand drawn parts.

I dont know where did I get the 8:9 thing, I cant find it, I guess it was in a thread here. Until now I was using this table I made for reference, now I guess is somewhat wrong:

SAR examples: (704x576) (704x480)

4:3 = 12:11 pal = 10:11 ntsc
16:9 = 16:11 pal = 40:33 ntsc

SAR For Digital Playback: (720x576) (720x480)

4:3 = 64:60 (16:15) pal = 64:72 (8:9) ntsc
16:9 = 64:45 pal = 64:54 (32:27) ntsc

*You can also see the 8:9 PAR in the reference section of the PAR wiki

[Boulder]

Gunnar,

some questions for you:

If I set the Deep analysis to kick in at for example <50%, it often doesn't show the "Deep analysis" text in the preview window even if the percentage of OK blocks is less than the limit. If I set it to 100% or so, it's used for every frame. Is this intentional or a bug?

Do you have any plans to improve the motion detection method, for example by introducing overlapping blocks (such as in MVTools2)?

[guth]

Originally Posted by Boulder

If I set the Deep analysis to kick in at for example <50%, it often doesn't show the "Deep analysis" text in the preview window even if the percentage of OK blocks is less than the limit. If I set it to 100% or so, it's used for every frame. Is this intentional or a bug?

The deep analysis percentage is a percentage of all found vectors, while the text gives you the percentage of all blocks. If matching fails for a block, it won't get a vector at all, so there are usually fewer vectors than blocks. That's why. A little confusing, I know.

Originally Posted by Boulder

Do you have any plans to improve the motion detection method, for example by introducing overlapping blocks (such as in MVTools2)?

Most people seem to think deshaker is too slow. What you propose wouldn't exactly make it faster.
We'll see, but I'm afraid it probably won't happen any time soon anyway...

[Boulder]

Originally Posted by guth

The deep analysis percentage is a percentage of all found vectors, while the text gives you the percentage of all blocks. If matching fails for a block, it won't get a vector at all, so there are usually fewer vectors than blocks. That's why. A little confusing, I know.

OK, thanks for the info.

Most people seem to think deshaker is too slow. What you propose wouldn't exactly make it faster.
We'll see, but I'm afraid it probably won't happen any time soon anyway...

The clips I use Deshaker on are very important so speed is not an issue.. The current 1st pass analysis is running at 0.9 - 1.2 fps at close to max settings so I don't know if it's that slow, though there's nothing in the AVS script but conversion to RGB24. Computers are getting faster all the time, my Core2Duo rig is from 2007

[Boulder]

Another feature request: it would be nice to be able to use Lanczos or Spline for resampling. I assume that you use the selected resampling option for zooming in the edge compensation functionalities? Lanczos or Spline should provide sharper output than bicubic.

[guth]

Originally Posted by Boulder

Another feature request: it would be nice to be able to use Lanczos or Spline for resampling.

From what I've seen the difference is barely visible, except under extreme test scenarios. And not even then is it easy to see which is better, I think. So I don't think I'll bother. (And that's coming from a perfectionist )

Originally Posted by Boulder

I assume that you use the selected resampling option for zooming in the edge compensation functionalities? Lanczos or Spline should provide sharper output than bicubic.

Deshaker needs resampling for lots of reasons, but everything is always combined into one single resampling (so no pixel is ever resampled twice between input and output). And that single resampling uses the selected algorithm.

[Undead Sega]

Hello guth, it has been awhile, hope all is well.

i probably mentioned this before a couple years ago but i cant find what ive type,plus im more experienced in this matter but im still having a problem. The problem im having is to stablize a shot, this contains a panning camera from right to left in an empty (static) room to only have a person sitting in the middle of the shot making large and fast movements. The camera itself is of course what i want to stabilize, however from what im gathering, the motion vections are picking the person's movement as camera shake, therefore the resulting video look would shake in accordance to the movement that the person is making. I was wondering how can i avoid this? and what parameters do i need to set accordingly?

i hope u understand what i mean, and i would really appreciate it if u can help me on this. thanks and look forward hearing back,

[guth]

Originally Posted by Undead Sega

The problem im having is to stablize a shot, this contains a panning camera from right to left in an empty (static) room to only have a person sitting in the middle of the shot making large and fast movements. The camera itself is of course what i want to stabilize, however from what im gathering, the motion vections are picking the person's movement as camera shake, therefore the resulting video look would shake in accordance to the movement that the person is making. I was wondering how can i avoid this? and what parameters do i need to set accordingly?

If the deshaked video is only slightly wavy, you should probably reduce the value for "discard motion of blocks that move > X pixels in wrong direction". Maybe to 1 or even lower. That's to avoid picking up even very slow motion from the person.

If it's very shaky after deshaking, then Deshaker probably lost track on where the stable background is and started matching partly or completely on the person. Remember, you shouldn't get any white vectors on parts of the person that are moving. The white vectors should only be on the background or on the person's still parts. This can sometimes be tricky to accomplish, especially if the person takes up a large portion of the frames. You can try decreasing block size and increasing differential search range and set "use pixels" to "all". If possible, you should definitely use "deep analysis". And if everything else fails, you can use "ignore pixels" to help Deshaker ignoring the person.
Next version of Deshaker will have more ways to help avoiding this problem. (Now that VirtualDub 1.9.9 is out and seems to include a bugfix I've been waiting for, I'll probably release it soon. Don't expect any major cool new features, though...)

[Boulder]

What sort of improvements are expected to be in the next version? I'll start working on the second passes of my projects and was wondering whether I should wait a while for the new release?

While I'm writing, here's another shameless feature request It would be nice to have limits for horizontal and vertical corrections in pixels so that I could enter a value that I know I can live with (for example I've measured that my TV has approximately 16 pixels of overscan).