RE: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules

["Jeff Henrikson" <jehenrik@yahoo.com>]

> First the color cache in otherlibs/graph/color.c is too small (512
> entries). So if I overlay my image with, say, red and blue zones,
> totaling more than 512 colors, make_image gets terribly slow (I spent
> an entire evening tracking out this mysterious slowdown). As a fix I
> set it to 4096 entries which corrected the slowdown (until I buy a
> color camera, that is).

Sounds like you need some vanilla blitting functionality rather than the high level graphics library.  I hacked lablgtk to have a
function that took a bigarray representing 32 bits per pixel (8 are padding) and blit it to the screen using the GDK call
gdk_rgb_32_image.  I also wrote one C function to do a special case of alpha composting bigarrays together in ARGB format.  (The
wrappers for the so called "rgb" functions of GDK are not included in GTK.)  Unfortunately, this makes lablgtk depend on bigarray,
so it's probably not fit to include in the distribution.

Anyway, they run at not a large constant factor from memcpy speed, I can make a patch if you'd like.  You'll probably have to add a
little C code onto what I did to make it do the thing that you wanted exactly.  But it sounds like not a big learning curve since
you presumably already wrote C code to talk to your camera.


Jeff Henrikson



> -----Original Message-----
> From: owner-caml-list@pauillac.inria.fr
> [mailto:owner-caml-list@pauillac.inria.fr]On Behalf Of Berke Durak
> Sent: Tuesday, October 09, 2001 5:32 PM
> To: caml-list@inria.fr
> Subject: [Caml-list] Some suggested improvements to the Graphics and
> Bigarray modules
>
>
> Hello,
>
> I'm doing some ``real-time'' video processing experiments with Ocaml
> (such as simple motion detection). I'm using the module Graphics for
> displaying grayscale images captured from a video camera. The program
> spends a significant amount of time in Graphics.make_image, which, for
> every RGB value, looks up its pixel in a color cache.
>
> First the color cache in otherlibs/graph/color.c is too small (512
> entries). So if I overlay my image with, say, red and blue zones,
> totaling more than 512 colors, make_image gets terribly slow (I spent
> an entire evening tracking out this mysterious slowdown). As a fix I
> set it to 4096 entries which corrected the slowdown (until I buy a
> color camera, that is).
>
> Second, it would be really nice to have an efficient interface between
> Bigarray and Graphics : a procedure for (quickly) converting either
> a m x n x 3 RGB byte array or a m x n byte array with a given palette
> into an image.
>
> Third, I find that the coordinate convention (increasing y coordinates
> get you higher in the screen) is counter to current practice (CRTs
> scan from top to bottom ; matrices are also written from top to
> bottom). Further, it is contradictory with the semantics of
> make_image, since the higher the row number is, the lower you get on
> the screen. I personally use (row,column) semantics, which is also
> contrary to current (column,row) semantics, but I find it more
> mathematical. A minor point.
>
> Fourth, Bigarray syntax does not work with Camlp4 ; a pity since streams
> are much faster with Camlp4.
>
> Fifth, and most important point (since I can't hack it myself) : I'd
> really like to see access to Bigarrays optimized. Currently, they are
> not (library call for each access). As a palliative a function for
> inter-converting portions of Bigarrays and strings would be welcome,
> as access to strings is much faster.
>
> Thanks for bringing us Ocaml and keep up the good work !
> --
> Berke
> -------------------
> Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
> To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr
>

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr