next up previous
Next: Bibliography Up: The Stereocam System: Specification Previous: 4.3 Main program

5 Proposed Development Schedule

As mentioned in Section 3.1, the modular design of the system allows it to be built in an incremental fashion. What follows is an outline of the way in which development of the reference implementation (on the SGI IRIX platform) is expected to proceed.

It is believed that steps 1 to 6 (inclusive) could be completed in the time corresponding to a 4 credit point semester course. However, due to optimistic estimating (and other factors outlined in [Brooks, 1975]), this may not be possible. In this instance, steps 1 to 5 should be completed, providing functionality similar to the Preliminary Investigation, Section 2.

  1. The basic framework. This would include a main program similar in spirit (though more sophisticated in its details) to that outlined in Section 4.3, with facilities for selecting the input, output and processing modules. It would also include the abstract classes Input, Output and Process and most likely some trivial implementations of these13.
  2. The image file input and output modules. This would allow stereo images (for example, those used in the Preliminary Investigation, Section 2) to be input and subsequently output to other files. This step is non-trivial because reading and writing images files is an important, yet difficult step. It is envisaged that some kind of image processing programming library would be sourced and used for this step. Further, it may be necessary to have a Strategy style pattern for selecting the algorithm required to input and output a given image file format.
  3. The rotation processing module, that is, the RotateProcess class. This should be relatively easy, as it's a simple matrix transpose, and will allow the so far manual intermediate step of rotating the images to be performed automatically.
  4. The CrystalEyes output module. This would allow stereo images read from image files to be displayed by the system, effectively providing the functionality of the Preliminary Investigation, Section 2.
  5. The Indycam input module (and possibly also the \( \textrm {O}_{2}\)cam module, depending on the system interface differences). This would allow images and movies to be captured directly from the cameras. However, at this stage, only still images could really be used (outputting to image files) as it's not possible to have more than one Indycam per computer, and the network support isn't yet present.
  6. The network input and output modules. This would allow still images to be taken on two remote computers with the Indycam input module, and then displayed in stereo with the CrystalEyes output module. Further, it should allow stereo movies to be displayed in this fashion, though without special optimisation work it is unlikely that the performance would be adequate.
  7. The movie file input and output modules. This would allow movies to be recorded and played back without the potential performance degradation imposed by the network in the previous point. As with the image file input and output modules, it is likely that movie processing programming libraries would be sourced to aid this step.
  8. Tune and optimise areas of the system which are degrading performance, especially where this prevents stereo movies from being satisfactorily displayed. This would involve finding these areas (possibly profiling the system) and then implementing the required extensions and enhancements required. For example, this may require image compression and decompression when transmitting across the network.

next up previous
Next: Bibliography Up: The Stereocam System: Specification Previous: 4.3 Main program
Kevin Pulo