As a disclaimer, our drive team was better at dead-reckoning our catapult last year than our code was at aiming during autonomous. If you don't have to move (don't intend to pick up frisbees) during autonomous, you could simply determine what image parameters would indicate a hit, and output text to the dashboard ("On Target", "Too far left/right/back/forward").
(They were also better at aiming during the match with a tape-cross-hair on the screen, so we removed the whole function.)
Given the above, you weren't very clear how far into the image processing you've gotten. Here is my code from last year, it's not broken into modules very well so I'll give you some line numbers:
https://github.com/TeamExcel/Project.../Robot2012.cpp
1313: A function to init the camera
795: A function that takes a camera image and does image processing, and sets up variables for the pid.
753: Has teleop glue logic.
451: Has logic in disabled to report on/off targeting
My strategy last year was to capture an image every second, and use each image to feed parameters to the PID loops. The actual PID loop was driven by a gyroscope (for rotation) and accelerometer (a not so great way of tracking distance). I never got far enough to check whether or not taking a picture in motion (every image after the first) was an accurate way to feed the PIDs, I'm guessing that time delay which likely exists was causing a long settling time (since each updated target after the first would not capture the motion that had taken place between taking the image and setting the new target).
I thought it would work well, and hope to be able to develop it further this year. It certainly reduced the processing power needed for image processing, and it did work sorta (I hadn't done PIDs before, so that was the primary issue, ran out of time on build season for tuning/guessing).