Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • For a pet project* of mine, I needed to do some image processing/recognition from a video camera. First, I wrote the recognition algorithm with PDL, which turned out to be just a few, maybe five, lines of very dense code.

    It turned out to be very difficult to use the resulting, transformed image in the way I wanted to, because passing it from the video4linux driver (JPEG output) to perl/PDL (binary PNM is the keyword there) to SDLPerl took *a lot* longer than the actual processing.

    So I rewrote the whole thing in an ugly conglomerate of C&C++. Eventhough I tried to optimize it, the image processing part never was much faster than those five lines of PDL code. But the integration with SDL and friends was much more seamless. (There's actually documentation for SDL, woah!)

    So maybe you'd be best off do parts of what you want in C/XS by hand.

    Oh, and in terms of throughput, I'm currently limited by the 640x480 and 25fps the camera provides. My CPU usage on a 1.8GHz Core2 is hovering around 15%, but that includes decompressing the jpg, transforming it to pnm, switching the red and blue bytes, running the recognition on it, passing it to SDL (with a pointer, which was the core of the efficiency problem in Perl), rescaling it to the screen resolution, and displaying it.

    Cheers,
    Steffen

    * I seem to have an infinite number of those. :(

    • Given that I'm using a 1024x768 on 1.5Ghtz hardware, that suggests that the mechanism I'm using could just about handle your camera feed, albeit at around 100% of CPU. Granted I'm not displaying the results, but this is probably still only around an order of magnitude slower.

      Since the regex itself only costs less than 0.01 seconds, that just leaves the overhead of the capture call itself (which could itself contain a Windows internal transformation) and the non-trivial cost of packing the bytestream into Im