tracker enhancements

[jbills]

doing some tracking today - love the current system - lots of good stuff in there already.

Could we have an option to update the reference if the accuracy falls below a user defined tolerance? And stop tracking if it falls below a certain point? This periodic auto-update can really help get a solid track quick.

Also, if possible, I'd love to have a hotkey for deleting the last keyframe set and moving the playback head back (or forward if tracking backwards) one frame. That way, when the tracker falls off, you can quickly delete the last couple of keyframes back to where it was solid, reposition the tracker, and continue.


curious what sub pixel accuracy the current system is working at and if making it variable might result in a speed up? Also, wondering if limiting the image processing area to the search region might speed the tracking process - not sure if it would matter if the sequence is cached, but it might be a big speed boost otherwise.

[jbills]

forgot to mention, when doing some tracking, I sprung a dialogue box that popped up and said "St9bad_alloc" and crashed everything.

That can't be good.

[jbills]

adam just had a killer idea -

when smoothing a track, might it be possible to have the smoothing process result in a new tracker? Would be nice to keep that original track intact. Say the smoothing didn't work - if you couldn't undo back to it, you'd be hosed! You might want to try something different with the original data, like avg'ing with another tracker or something.

creating a new track from the smoothing process (or any math operation, for that matter) would be ideal. What do you think?

[jbills]

sorry - thought of another thing.

this is something I wanted in shake for the longest time that may or may not be applicable in s+r.

when viewing the clip in proxy mode, I commonly forget I'm working at reduced rez.

when going to track, I assume the tracker uses the proxy data to perform tracking? that said, could we have a dialogue box that pops up and warns us that we're about to track on proxied footage and not 1:1? That might save me some blunders.

:)

[mikeparsons2]

You could tie a piece of string to your finger whenever you use a proxy and take it off when you go back to full rez...

Good idea, it is too easy with high res plates to not notice rez changes on a small computer monitor.

[mikeparsons2]

While we are looking at the tracker maybe the tracker should be able to load flame/shake tracking data. Often I will roto a simple shape and track it over the length of a shot to get an idea of how much manual roto is needed. I could easily hand this data over with the shot to the roto department.

[perryk]

(still at NAB)

Does anyone have the definition of the tracker data format? We'll need these definitions if we're to import or export the data.

p

[jbills]

I've used this website on jobs before for a quick conversion -

http://www.heimlich.net/trackconvert/

Seems to me if you just had the info for one, you might be able to run it through the conversion grinder and figure out how the others work? Or you might try contacting the person behind this website and digging for info?

There is a commotion to shake converter online at highend2d.com that might be of use.

oops, said the c-word.

[jbills]

question -

so sometimes I'm looking for tracker math that doesn't seem to be available to me in my comp app here so i'm having a hard time describing it.

it's similar to smoothing but different.

ok, so I track a point that is moving lots in x/y. a car headlight driving across the screen, something. track is bumpy.

what I want to do is smooth the points out, but the artifact of smoothing a track that is moving a lot in x/y to begin with is that your points tend to move A LOT from the smoothing process. As in - watch in horror as your golden reference frame #1 that was used to define the track goes flying off as you smooth. The end points gradually shrink in as a result of the blurring of the path - does that make sense?

So I guess what I'm looking for is some sort of jitter algorithm that irons out the bumps but leaves the length of the track intact so that the end points pinned where they were originally. Sorry having such a hard time describing - does that make sense? It's something in discreet software that I've never had to do in Shake and therefore run a quick test to describe what is going on.

really need it, though! the workaround is deleting keyframes, which is fine, but you know what I mean... seems like the code is out there (possibly)...

[jbills]

ooh. could we get point display for the tracking paths? As in, you select a tracker on the timeline, and you see a little point for each keyframe?

just seeing the path makes it a bit hard to visualize, although I do like the cleanliness of it for when a track isn't selected.

[paulm]

Point display would be easy.

More tracker math - stuff coming that will let you do whatever you want. Get that slightly blurry gun ready to shoot yourself in the foot!
:D

[jbills]

sweet! what fun on a friday night. feet didn't do me no good nohow.

hey - how hard would it be to only run the tracker blur function inside the search region when tracking? dog slow on a 2k plate with that blur on... it's chugging along at a frame every 3 secs...

[jbills]

hmmmm...

when copying and pasting a tracker, might it be a good idea to have the copy come in as "copy of Tracker_1" or "tracker_2" or something?

not a big thing, just tossing out.