This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
On Mon, Aug 24, 1998 at 06:41:24PM -0500, it occurred to Corey Sweeney to write: > #1 in order to get the image into memory, would a framegrabber->guile > chunk of code have to be written in C? Well, you need some sort of an interface to the grabber. If you have command line utilities that do the grabbing, just using system should work. If the only interface to access the grabber is in C, you can't avoid it.. > #2 in order to access the image once it's in memory, what type of > "sturcture" can be used for the image? could it be "bluffed" into looking > like a list of lists to the program? or should a real interface be made > for it, so pixels could be accessed by new guile commands that are really > written in C? I really doubt you want to do large-scale pixel-crunching in guile, or any interpreted language.. (All right, SART does it, but that's just because ray-tracing is slow anyway.) If you really want to access direct binary data, strings might be the way to go. They're just char arrays (they can contain anything from ^@ to ÿ). I think you're better off providing real functions for manipulating the framebuffers. > also, has GIMP already addressed these issues, and come up with data types > for this (actually their, but hopefully compatible) purpose? Well, script-fu scripts don't manipulate image data, they just call (external) procedures with references to images. Gimple might eventually allow guile scripts to do all the stuff that plugins written in C do, but because of performance issues I'm rather doubtful about how sensible it is, so I'm not bothering with that right now. Lauri Alanko la@iki.fi