From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA01344; Tue, 9 Oct 2001 23:36:20 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA01290 for ; Tue, 9 Oct 2001 23:36:19 +0200 (MET DST) Received: from localhost.localdomain (Mix-Montsouris-110-2-3.abo.wanadoo.fr [193.248.189.3]) by concorde.inria.fr (8.11.1/8.10.0) with SMTP id f99La9924405 for ; Tue, 9 Oct 2001 23:36:09 +0200 (MET DST) Received: (qmail 3853 invoked by uid 1001); 9 Oct 2001 21:31:43 -0000 Date: Tue, 9 Oct 2001 23:31:42 +0200 From: Berke Durak To: caml-list@inria.fr Subject: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules Message-ID: <20011009233142.A10140@gogol.zorgol> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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