caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Berke Durak <berke@altern.org>
To: caml-list@inria.fr
Subject: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules
Date: Tue, 9 Oct 2001 23:31:42 +0200	[thread overview]
Message-ID: <20011009233142.A10140@gogol.zorgol> (raw)

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


             reply	other threads:[~2001-10-09 21:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-09 21:31 Berke Durak [this message]
2001-10-09 23:21 ` [Caml-list] " Christopher Quinn
2001-10-10  0:52 ` [Caml-list] " Jeff Henrikson
2001-10-10  7:04   ` Chris Hecker
2001-10-10 19:47     ` Jeff Henrikson
2001-10-11  0:50       ` John Prevost
2001-10-12 14:29 ` Jun P. FURUSE
2001-10-12 15:02 ` Xavier Leroy
2001-10-12 15:38   ` Berke Durak
2001-10-12 17:15     ` Daniel de Rauglaudre
2001-10-13 23:16       ` Berke Durak
2001-10-14  3:14         ` Daniel de Rauglaudre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011009233142.A10140@gogol.zorgol \
    --to=berke@altern.org \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).