Computer Vision development

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.