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 thin

    • 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 Imager::RawImage structures, and then sucking them back out again into BMP format.

      I suspect that the stream->struct->stream cost is most likely the biggest removable cost, by a significant margin.

      So once we've managed to remove that cost, maybe then we can see if there's a stray variable copy or something that is removable. Or perhaps by pulling the screenshot at 24-bit vs 32-bit vs whatever, we can somehow avoid a transform in the Windows layer and speed up that bit.

      For now, I'm really happy that I can achieve these sorts of speeds in pure Perl (ignoring the work of Imager) because it means it's going to be a lot more flexible in the ways it can be applied. And many systems only really need one frame per second capturing, so we're talking 25% of a CPU, which isn't too intensive for many types of use cases.