Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Some suggested improvements to the Graphics and Bigarray modules
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Berke Durak <berke@a...>
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