Meant to be Seen

FingerFlinger wrote:By the way, I assume that your code does straight-forward patch correlation? What window size are you using?

Yes, simple window correlation on the epipolar line, but with some personal refinements I can't remember for now. I remember testing Pearson product-moment correlation coefficient to rule out outliers which gave better results in some cases though.

For the window I've tried several sizes, 3x3 was somewhat acceptable and 7x3 was a good compromise in speed vs quality IIRC, on quite low resolution images. My machine at the time was not beefy enough to work on HD images (older AMD Athlon single processor).

FingerFlinger wrote:EDIT: This one is from "FPGA Design and Implementation of a Real-Time Stereo Vision System", and is also based on the Census transform. You can see that their results are almost identical to mine.

Ah yes, I guess it's related to the census algorithm then. I thought it was pretty good since the 2nd best algorithm is using it in the Middlebury evaluation, but it's in fact AD-census, census coupled with absolute differences measure.

The AD-Census is also doing some kind of aggregation magic, but I don't know exactly what. I'm working with the Census transform because it has a low computational cost and is really good for sparse features, but maybe it just has some weaknesses on accurate dense reconstruction.

I saw this BlackFin dev board and thought it might be a good platform to use for this project: http://blackfin.org

I've looked at those BlackFins before, and they seem pretty neat, but I just don't know if they have the grunt for my performance targets. An FPGA would be the ultimate solution I think, but I'm probably going to stick with CPU/GPU until I actually have something working and stable.

brantlew wrote:Good stuff. Camera calibration is definitely a pain. One tip that I've learned for stereo calibration is to separately calibrate each camera and then feed that into rectification, instead of trying to do the all-in-one stereo camera/rectification procedure. Reason being is that when you film the grid pattern in stereo you can't get full coverage across the entire field of view of each camera because you have to find compromise positions in the center where the grid is fully visible to both cameras. Calibrating separately allows you to cover the entire range of each camera.

Can you give a few more details about this? I am just using the stereo_camera_calibrate example - how do you individually calibrate them and then combine?

Chriky wrote:Can you give a few more details about this? I am just using the stereo_camera_calibrate example - how do you individually calibrate them and then combine?

Look on page 427 of the O'Reilly book. The cvStereoCalibrate() function can use data from separate camera calibrations. You will want to read Chapter 11 to get a handle on what all the parameters mean.

http://www.cse.iitk.ac.in/users/vision/ ... OpenCV.pdf

This has been on hiatus for a while already, but I don't expect to find much time for it in the foreseeable future either. I recently accepted a position at Oculus doing computer vision, and my efforts will be focused there (obviously). That said, I still think this is a fruitful direction of research, and would love to get back to it eventually!

Congrats for your new position. Nice to see the most interesting members of this forum working there. I hope you'll still come here from time to time to discuss ideas.

Congratulations Finger! Great to have you on-board.

Congratulations

Good stuff. Hope to see you soon.

How did I miss this? Congratulations Finger! Are you coming out to Irvine?

Just arrived in town today! Hope to find an apartment tomorrow... Are you in the area, zalo?

Congrats on the position! Oculus must have a sizeable team by now.

Congrats on the new position as well FingerFlinger.

Thanks everybody; today was my first day. There are a lot of smart people working here!