EddieOffermann dot com

Read this question on cgtalk tonight and thought I'd kick the question and my response out here since I've repeated much this same advice many, many times.

I use Boujou for matchmoving but am tracking 640x480 camera resolution all of the time... I often have shots with handheld very shaky camera and motion blur. Boujou has trouble tracking it. Is it just that there's to much blur/shakiness or would a higher camera resolution help?

and my response:

Well, it looks like there are a number of issues to overcome:

First, the quality of the footage: handheld/shaky/moblurred footage is just awful to work with. If you're just the artist, ie, you get what's handed to you: you work with what you have. There's no telling Mann, Fincher or Stone they have to reshoot because your job is hard. Their job is harder and it's them the client paid for, not you. If it's for your own projects, ie, you're the director or at least the vfx supervisor on a smaller project: you have to take this into your hands (so to speak) and fix it before it gets past the camera! Since you're working with 640x480 footage, I have to assume you can address it at this stage: these are obviously personal projects, not features or broadcast. Fix the source first! Don't shoot/allow to be shot footage that's going to suck to do post on!

Second, the resolution of the footage: Until you've worked in HD or film res, it's hard to appreciate just how much easier it is to work with on a tracking level. A dot that is so small it'll disappear into noise at NTSC is an obvious crosshair at 2k. Smudges on the wall and skin blemishes become usable tracking points. If you have the option to work with higher resolution footage, insist on it!

Third: Lighting. Again, this is only something you can influence if you're shooting your own projects, but remember to light for contrast not final levels. More light means faster shutter speeds means less motion blur. Light for the type of shadows you want, not how dark you want the scene when you're shooting for visual effects. If your key and fills are set properly, you can always make the shot darker when grading. This isn't as much of an issue when shooting film or deep color digital like the Arri Digital cameras since their shadow detail is good enough to boost for tracking detail. But if you're shooting with consumer or prosumer cameras, you've got jack but noise in the shadows and the low light levels will mean excessive blur and bad noise overall.

Fourth: Manual vs Auto. Boujou has a reputation as being the fire-and-forget solution for people that don't understand tracking. The really hard shots are going to need manual solutions. I don't mean hand-keyed (necessarily) but we're talking careful selection of usable tracking detail and improved setting of constraints. Personally, I recommend SynthEyes - unbelievably good price point and an unbeaten feature set. I know there are shots that people say they can click a button and get a solve on in Boujou that they can't get in SynthEyes, but the reverse is true far more often than it's not. When the footage is hard to work with, throw away the automatic solutions. Give them one run at it if you've got the time and processor power to spare, then move to something where you have some control.

Fifth: Tracking techniques. Track the center, not the edges. When doing a supervised track of moblurred features, follow the center of those blurs.

Sixth: Rendering techniques. Moblurred footage is hard to render to match because what you have to match is a particular slice of time. Think of it this way: you're placing tracking points on each frame, generally spaced apart at the rate of 24, 25 or 30 frames per second. Between frame 1 and frame 2, there's a fraction of a second where anything could happen. The camera could jump up a couple centimeters and back down for instance, before hitting frame 2. This will show in the motion blur but not in the keyframes. You can't easily fix for this! (See tip 1). More often, though, the problem is the phase of the render. How to address this will depend on your renderer. You may be able to adjust this in the renderer, you may have to adjust it in the actual animation keyframes depending on what 3d software you're working from. Basically, you need control of the shutter timing and shutter offset: when in that frame it opens and how long it stays open.

For high end vs. low end facilities, #6 can often be the difference between them. For all the skill you can buy from freelancers in tracking, modeling, animation, textures, etc: having the resources to do test renders and tweak that setting (and having someone on staff who can make sure you're addressing this) makes all the difference.

photo credit: Capture Queen ™I have a side project for iPhone that I'm working on. There's a patent filing in process, incorporation paperwork to do, all that good stuff - so I won't be doing a lot of specifics about the project until it's ready to go. It's basically a location-based-services thing but when we've looked over what everyone seems to be doing with LBS and social networking and the like, it all seems to be thinking very inside the box. Just like a few years ago there was a rash of "... on the internet!" patents where things we'd done forever in the wetworld were being done online and called "visionary", now there's a rash of similar "... on a mobile phone!" patents and websites that are no more groundbreaking than when we did them online or on our feet. It's like patenting driving in nails with the side of a hammer. It works, but it's not especially groundbreaking nor is it even ideal.

We really feel that this project is going to move mountains though, and change the way people view the real world around them, not just when they're in front of a computer.

The tendency towards developing for the iPhone is that the iPhone has arguably the best SDK there is: and a substantial and rapidly growing marketshare. Still, though, that limits our deployment: it's the largest selling smartphone-style device, but it doesn't represent the majority of the market. No-one does.

Today I've been evaluating Mojax, a cross-platform mobile development environment. It looks promising. It promises cross-platform compatibility, including access to a number of necessary core services like GPS, and currently runs on all phones supporting J2ME (Java on Mobile), all color Blackberry phones, and shortly Windows Mobile devices from WinMo 2003 onward, any mobile running Brew V2 or later, and Helio devices. Just the J2ME support gets me onto most smartphones - so this effectively would get the product onto every mobile device there is with gps capability.

This excites me because I like the prospect of running the application on every feature-capable mobile phone without having to separately develop for Blackberry, HTC, Samsung, and Nokia. Getting the product out simultaneously for iPhone, Windows Mobile, PalmOS and Blackberry would be fantastic. There are some annoyances with using J2ME midlets, but I'll take the slight user experience tradeoff for being able to deliver an application at all without breaking the bank

So I'm working on a side project that's mainly just for me, but it's so damn handy I might just make it publicly available when it's done (probably for a small monthly fee). It's basically a super quick way to run certain types of scan for stocks during the day, picking out data that's usually hard to get until the end of the day. I'm tying it into the OptionsXpress API so that when I identify a good entry or exit point on a stock, I can change my position with the click of a button.

I've been designing the site to automatically rescale for my mobile phone, but I need a way to determine if I'm looking at it on the phone or on a desktop - and since my mobile browser is generally configured to identify as a desktop browser (so that I don't get sent to the "mobile version" of the sites I visit) it's harder to do. My browser does a great job of rendering full-screen pages and scaling them - if you've seen the iPhone browser, both Opera Mini and Pixsel do something similar though without 'multi-touch'.

That said, there's something to be said for designing a website that will gracefully scale when it's on a phone.

But when the browser identifies itself as a desktop browser, what's left? Javascript can pick up the screen size, but what about PHP? All my pages are created in PHP...

More »