<div dir="ltr">=This week=<div><br></div><div>I worked entirely on multicamera reconstruction this week. This included a fairly big change to the way multicamera tracks are stored.</div><div><br></div><div>Tracks are stored as just a set of markers, where each marker has associated image, track, and camera identifiers. I previously treated "image" like "frame", where a marker with image 0 and camera 0 would be the first frame of camera 0, and image 0 and camera 1 would be the first frame of camera 1. This, however, means that all of the libmv algorithms need significant changes to start iterating over images <i>and</i> cameras. This doesn't really make sense, because libmv doesn't care about which images come from which cameras - it doesn't even care that they come from a video camera at all. It just receives a set of images and reconstructs from them.</div>
<div><br></div><div>My new approach is to simply use the camera identifier as a kind of annotation. All frames from all cameras will receive a unique image identifier, and the camera identifier is just used to keep note of the source camera that the image came from. In this way, the camera identifier denotes subsets of the image identifiers. With this method, libmv can stay mostly the same - it just iterates over all images. Users of libmv who don't want multicamera functionality can just ignore the camera identifier.</div>
<div><br></div><div>Most of the commits this week were getting the internal libmv algorithms working with multiple cameras. There will be a few more of these commits, and then I can do some work on the blender side of things.</div>
<div><br></div><div>=Next week=</div><div><br></div><div>I'll keep working on multicamera reconstruction, particularly on the front end, because I'd like to have something nice to show by the hard pencils down date. I'll make sure I leave enough time to work on the wiki documentation (I've been keeping the in-code documentation up to date as I go).</div>
</div>