I saved a fork of Surround 360 when the code became available in July. The attraction is the opportunity to examine a complete capture problem. Camera design, control software and rendering belong to the same system, which makes the repository more interesting than a stitching filter presented in isolation.
Facebook's release explanation describes the problem in terms of stereo consistency, data volume and processing cost. Those are good questions to bring to a code reading. Where does the pipeline establish correspondence? Which errors are corrected, and which are assumed to have been prevented during capture?
Follow one object through the overlap
Imagine a narrow pole near the cameras with a building behind it. In neighboring images, the pole moves against the building because the viewpoints differ. A transformation that aligns the background cannot necessarily align the pole as well.
This is where the familiar idea of stitching photographs reaches its limit. A single warp may describe a distant scene reasonably well, yet a close object asks for a different displacement. Optical flow offers a way to estimate more local correspondence between images. It does not make every correspondence unambiguous.
An occluded strip of the building is a simple counterexample. One camera sees it and another does not. No amount of searching can find the exact counterpart of information that was never visible. The rendering system still has to decide which observations to trust and how to handle the transition.
Following the pole through the stages is a useful reading technique. It turns an abstract collection of modules into specific questions about coordinates, visibility and interpolation. A variable called "flow" becomes interesting when it explains where the pole's edge will appear in the output.
The pair is the product
A stitched view should not be judged independently from its partner. If the two eyes receive different compromises around the pole, an image that looks acceptable on a monitor may become uncomfortable in stereo. The system is constructing a relationship between views, not merely two attractive pictures.
This also changes how to think about debugging output. Intermediate images are valuable precisely because they are less polished. A correspondence visualization, an overlap mask or an isolated seam can reveal a problem that is harder to locate in a finished panorama.
For my own reading, I would keep a small notebook of coordinate systems: sensor pixels, corrected lens directions, neighboring camera views and final panorama locations. Many confusing bugs are simple operations performed in the wrong space. Writing the spaces down can be more productive than staring at the final shader.
The open repository is useful as an engineering argument, including the constraints behind its choices. It is not necessary to build the complete camera to learn from that argument. Understanding why a nearby pole causes trouble already improves the questions I would ask of any stereo stitching system.