Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] camlimages and kernel memory
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-06-12 (16:20)
From: Jun P.FURUSE <Jun.Furuse@i...>
Subject: Re: [Caml-list] camlimages and kernel memory

> This is the hard way :-)  A simpler way to memory map files or devices
> in a Caml program is to use the function "map_file" from the Bigarray
> library.  However, it currently always map the file from offset 0,
> which is probably not appropriate for /dev/kmem...  I'll have to look
> into this limitation.
> > The other problem is whether camlimages can handle data that is
> > organized as ring.  I don't have any ideas.
> The type Image.t is a relatively complex data structure, so some work
> is definitely needed to go from a raw string or bigarray
> (corresponding to the memory-mapped file) to a value of type Image.t.
> I'll let the authors of CamlImages comment on that.

If the kernel memory contains the same data structure as one of
the camlimages internal image formats, the solution may be... 
Somehow (= I do not know) get the kernel memory as a raw string,
then create an image using ???.create_with function. 

The kernel memory may use different pixel layout, I am afraid.
In such case, you have to write your own version of module like
Rgb24, Index8 and so on. I am sorry but they are not well documented...

BTW, once I tried to implement Image.t using Bigarray, but it was too
slow. It seemed to me that it performed the array boundary checks for
each access. For image manipulation purposes, the unsafe versions of set
and get are really required. 

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: