Often computer vision projects begin with a very early proof-of-concept, or at best a prototype, to see whether something is going to be feasible. Hopefully it turns out to be, so things then progress to a ‘see how much we can get working’ stage. As long as that goes well, then things eventually move towards a live production release. During this process, the images I’m expected to handle can become more and more ‘real world’: I start to get more noisy images, focus problems, reflections – the nice clean images I was originally testing with seem trivial now. In response, the code (and the computer vision workflow it embodies) gets ever more complex, often evolving from the original prototype, sometimes as a complete rewrite. This is a familiar pattern I’ve experienced across many projects.
Managing this process in a sensible way is something I’ve learned is very important. It’s essential to be aware of how the project is moving from proof-of-concept to production, and to make sure the code-base keeps up. Running multiple projects often in parallel, it’s even more important to keep documentation up to date, and to generally ‘run a tight ship’ on the development front.
Much of this is just good development practice, while some is more specific to computer vision projects. Some specific things I do include:
- Write a program log, with variable-level tracing showing what is going on. I do this in a formalised way so I can identify problem areas in the workflow for a given image very quickly.
- Write debug versions of the images as they move through the workflow, again in a defined and standard way.
- Comment code in a standard way.
- Use tools such as Doxygen to document the program automatically. The class and function dependencies diagrams alone are worth the small amount of effort.
- Use Git to manage the version control, locally, and on the client’s system as well if appropriate. This one has been a learning curve for me, but is paying off now.
- Maintain a document giving a brief overview of the whole system layout.
I don’t use truly ‘formal’ development methods – they don’t bring benefits to most projects of the type I’m involved with – but a little bit of good development practice goes a long way, and means the client ends up getting a documented, maintainable code-base and a production-ready solution.