From: ptkwt@... (Phil Tomson)
Date: 2005-12-29T10:52:54+09:00
Subject: Re: Real-time image processing in Ruby

In article <2a14ed641166a177977c5f6a33bdc7b5@ruby-forum.com>,
John Koschwanez  <ishkaprog@gmail.com> wrote:
>I'm a Ruby newbie - "Programming Ruby" was great Xmas break reading!
>I write image analysis and processing code to analyze single cells under 
>a microscope in real-time and to automate lab equipment.  I now write 
>solely in C++ for PC, but I would love to use Ruby to quickly try new 
>ideas without plowing through C++ code.  I have read through the forums 
>and I see Ara Howard is using C extensions to process images - I'll try 
>the same thing.  I have some questions for the group:
>- I capture images from a camera, process and analyze them, and display 
>them at ~10 fps.  Ruby-v4l (capture) is for Linux only.  Tk is probably 
>too slow, and someone recommended using OpenGL for display.  Has anyone 
>had success with image capture or display using Ruby?  What worked?  Any 
>advice?
>- Is anyone using pure Ruby to process images real-time?  RMagick is too 
>limited for my applications.  I doubt Ruby would match the speed of C, 
>but it might be fun to try.

Ruby will probably be too slow for your needs (I doubt you'll be able to 
make even 10fps unless you write a lot of your code in a C extension).  What 
if you take a C or C++ image processing lib (like CImg) and wrap it for use 
from Ruby?  Well, CImg might be a tough one as it relies (too much) on macros 
- that could make it tough to wrap, I suspect.

Another option might be to use Ruby as a code generator.  I was working on a 
project last summer where we were using a Matrox card for image 
capture/processing.  We 
were using the Matrox image processing API which is a bit of a pain to work 
with (you end up having to violate DRY all the time the way it's set up).  So 
what I started doing was to create a DSL (domain specific langauge) which 
could generate the C code using the Matrox image processing API.  I didn't 
finish it, but I think the appraoch had potential.  Basically, you could write 
a bit of Ruby code that would then generate a whole lot more C code (something 
like 4 to 8X the number of lines; and you didnt' need to violate the DRY 
principle).  So the description of what you wanted to do was in fairly 
compact, easier to understand Ruby code which generated the C code and 
compiled it.  While Ruby itself isn't fast enough to do realtime image 
processing, you really only need to describe how you want the image processed 
and then generate C code which runs many, many times faster.  And you wouldn't 
even need to write any C code (after you've worked out the code generation 
details, that is).

I think image processing is very  amenable to this sort of highlevel 
description, because most image processing is just a matter of a series of 
transfromations:

Captured Image -> transform A -> transform B ... transform N -> output image.

In our case what we needed was to be able to easily plug in different 
transforms to find out which one(s) would give us the most desireable results.  
Perhaps in your case you already know what transforms you need and what order 
they should be in, if that's the case you may not find much benefit from this 
approach.

Phil