Re: targets and ?sources?
Marcus Sundberg writes: Image loading should ideally be written as two libraries: One library that does not use LibGGI and does not know about visuals. It should dynamicly load readers/writers for different image formats, and read images into/write imaghes from it's own simple structure (basicly just width, height, format and a pointer to the data). It should also be able to convert images between different formats. libmagick ? It's free software, can be used without X, and supports a sheet-load of image formats. Cheers, __ \/ Andrew Apted [EMAIL PROTECTED]
Re: targets and ?sources?
On Wed, 23 Feb 2000, Andrew Apted wrote: Marcus Sundberg writes: Image loading should ideally be written as two libraries: One library that does not use LibGGI and does not know about visuals. It should dynamicly load readers/writers for different image formats, and read images into/write imaghes from it's own simple structure (basicly just width, height, format and a pointer to the data). It should also be able to convert images between different formats. libmagick ? It's free software, can be used without X, and supports a sheet-load of image formats. Two questions: 1. Is it generic? This is necessary, because the main point about GGI is being _generic_. 2. Which distributions comes with libmagick? libmagick should come with as many distributions as possible... Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: targets and ?sources?
On Fri, Feb 18, 2000 at 11:07:04AM -0500, Brian S. Julin wrote: For GBL and OVL to work nicely, we will need some way of allocating offscreen video memory. Any ideas on that ? Should that go into LibGGI or should we push it into an extension ? If it's going to play nice with SetMode, it'll have to go in the base. Else, we have a new AdvancedSetMode and any app using the extension is barred from calling vanilla SetMode. That's the only issue I see with extension vs core. Good question. I was wondering about this - about which part of the code is in charge of allocating video memory. Is it the chipset driver, or KGI(con) ? There is an issue here when different areas of memory have different capabilities, for example on i740, the hardware-cursor buffer (if used) must be in the first 4Mb. Jim -- Jim Peters / __ | \ Aguazul / /| /| )| /| / )|| \ jim@aguazul. \ (_|(_|(_|(_| )(_|I /www.aguazul. demon.co.uk \._) _/ / demon.co.uk
Re: targets and ?sources?
On Sun, 20 Feb 2000, Jim Peters wrote: Good question. I was wondering about this - about which part of the code is in charge of allocating video memory. Is it the chipset driver, or KGI(con) ? The "chipset driver" == KGI(con). The allocation would be handled by a combination of the driver and the driver-lib. It's sort of a two way street -- offloading the functionality into userspace and just having the driver check the requests for security has the benefit of keeping the kernel drivers simple, but implementing a standard API in-kernel would help reduce the number of customized driver libs needed. There's been a lot of correspondence on a generic "feature" API (see the list archives.) It would handle all types of features and would integrate in some way with the mode parameters to allow the negotiation of features vs each other and vs the video mode. Probably what needs to be done is pick one feature that people need the most and implement it in the form of the feature negotiation API -- but with the back-end being a simple hack because even though the API is generic, only one feature has been implemented, then work on making it handle more than one type of feature. BTW, we should accumulate all the old list traffic about this in one file and post it on the website for easy access because this thread comes up so often. -- Brian
Re: targets and ?sources?
Hi ! I think that is the best compromise between speed (single pixels would use less memory, but it would crawl) and memory usage. Well, I don't like compromises when you can get both worlds. ;) What I want (for the simple conversions like truecolor-truecolor at least) is: Ouch - we were talking about very different stuff :-). convert(handle1, handle2); which doesn't do any intermediate load stores. Sure. I intended to handle that case by a chain of callbacks that will massage the incoming data into the intended outgoing format. That can be done in place in many cases. But maybe we're talking about different things? I'm just talking about conversions from one pixel-format to another. Yeah, and I'm with you on that one. If you're talking about reading an image file from disk and writing it out in another image format you will ofcourse need some intermediate buffer. O.K., yes, that was what I was talking about - so we agree ... nice. Regarding LibGFP I can send you a draft for the external API that was made up by me and C.Egger in the meantime. Interested ? Sure, send it over. O.K. - I'll send it along together with a new design study for LibGBL (GGI BLitting) and LibBSE (now a wrapper around GBL and the yet-to-be-written LibOVL). For GBL and OVL to work nicely, we will need some way of allocating offscreen video memory. Any ideas on that ? Should that go into LibGGI or should we push it into an extension ? CU, ANdy -- Andreas Beck | Email : [EMAIL PROTECTED]
Re: targets and ?sources?
Andreas Beck [EMAIL PROTECTED] writes: It should also be able to convert images between different formats. That could be done by chaining a load and a save call appropriately. Not very good performance wise. You should really be able to do read-from-memory-into-register, convert, write-to-final-destination for each pixel (for cases where pixels don't affect eachother that is). Sure. This is how I meant it. It is defintely no good to have LoadImageToTempSpace(); SaveImageFromTempSpace(); I rather thought of something akin to while(write(handle,buffer,read(handle,buffer,bufsize))); But there you use 'buffer' as temporary storage, which is exactly what I want to avoid. Or do you intend some non-obvious magic? //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: targets and ?sources?
Andreas Beck [EMAIL PROTECTED] writes: while(write(handle,buffer,read(handle,buffer,bufsize))); But there you use 'buffer' as temporary storage, which is exactly what I want to avoid. Or do you intend some non-obvious magic? I mean a _small_ buffer for that. We will need _some_ kind of buffer anyway, when we want to pass data around. But the idea is, that like with a filecopy, you don't do malloc(filesize(bla));, but rather use a reasonably sized buffer as interim storage and the call read and write in a loop. I think that is the best compromise between speed (single pixels would use less memory, but it would crawl) and memory usage. Regarding LibGFP I can send you a draft for the external API that was made up by me and C.Egger in the meantime. Interested ? CU, ANdy -- = Andreas Beck| Email: [EMAIL PROTECTED] =
Re: targets and ?sources?
Andrew Apted [EMAIL PROTECTED] writes: magic: 3 0[5] == 'GIF88' # exists ??? No. -- Peter Bortas http://peter.bortas.org Idonex AB http://www.idonex.com
Re: targets and ?sources?
Andreas Beck writes: I think you should be able to add modules without recompiling the underlying system, so each module will need an init function which will update the table, like in the linux kernel. Even better: We make a "smart" module that tries to guess the image-type. It will then try to load the corresponding handler (using the equivalent of /etc/ggi/libggi.conf). Perhaps I should assimilate my "LibDataType" library into GGI, under a new name like LibGFFD (generic file format detection). Using suffixes and magic numbers, it can recognise over 400 file formats, including the following image formats: image/gif image/jpeg image/jpeg-hsi image/tiffimage/navy-interchange image/png image/pcx image/pcx-set image/bmp image/utah-rle image/portable-bitmap image/portable-graymap image/portable-pixmap image/portable-anymap image/xwindows-bitmap image/xwindows-pixmap image/ilbm image/djvu image/targa image/image-magick image/artisan image/phigs image/graphics-kernel-system image/computer-graphics-metafile image/fuzzy-bitmap image/facsimile image/image-file image/cmu-raster image/sun-rasterimage/sgi image/photocd image/quake-sprite image/mgr image/flexible-image-transport image/lisp-machine image/image-exchange image/xwindows-dump image/rgb image/gribimage/animator image/fax-qfx image/ipas-img image/portfolio image/pds image/windows-metafile image/atari-neo image/atari-degas image/atari-tiny image/spectrum-smooshed typeimage/computer-eyes image/black-and-white image/qv10-cam image/colorrix image/cineon-dpx image/autocad-slide image/photoshop image/very-ordinary-raster image/xara-web image/windows-icon image/amiga-icon image/applix-graphic image/xcf image/island-drawimage/acorn-draw image/fig image/hpgl image/edsun-ceg image/amiga-meta image/drawing-interchange Using LibGFFD, this new picture library could detect the filetype, and then look it up in the gpf.conf file to find which DLL to load to handle the image. Any interest in this approach ? Cheers, __ \/ Andrew Apted [EMAIL PROTECTED]
Re: targets and ?sources?
Hi ! After losing 2 weeks of work, I went to 2.3 and have never looked back. Except that AFAIK the bttv driver's more stable in 2.2.14 IIRC. You might want to use JFS or ReiserFS ... (is it possible to create a guaranteed no-swap memory area? Yes. Man mlock. And to tell how much physical memory is available so you can tune?) /proc ? CU, ANdy -- Andreas Beck | Email : [EMAIL PROTECTED]
libgpf (was: Re: targets and ?sources?)
On Mon, 7 Feb 2000, Andreas Beck wrote:
I'll try to give you something to play with below:
/*
* This is a design study for a Generic Picture Format library
*/
/* Startup/Shutdown:
*/
gpfInit(void);
gpfExit(void);
gpfPanic(const char *format,...);
/* Opening and Closing picture sources
*/
gpf_handle_t gpfOpen(const char *type,const char *location,const char *options, void
*locationdata, void *optiondata);
/* Open a file of a given type (NULL for autoselect), from "location".
* location should be in a recognized standard format which has semantics
* as determined by the library that handles type.
* Standard behaviour (especially that of the auto target) should be to
* accept filenames and URLs. Some special formats should be defined
* to allow for reading from internal sources, pipes and functions.
*/
gpfClose (gpf_handle_t handle);
/* Close a given stream, flush buffers and free ressources.
*/
gpfFlush(gpf_handle_t handle);
/* Flush buffers just as close would, but keep the file open.
* May not make sense on all targets.
*/
int gpfSelectImage(gpf_handle_t handle,int imagenumber); /* for multiimage Formats */
typedef struct {
int width,height;
pixelformat_t pixelformat; /* We can probably borrow from DirectBuffer here */
} gpf_imageinfo_t;
int gpfGetImageInfo(gpf_handle_t handle,gpf_imageinfo_t *info);
/* get the most important image data */
typedef void (*gpfIndicatorCallback)(int pos);
typedef int (*gpfReadCallback)(int x,int y, int width,int height, void *data, int
pixelwidth);
typedef int (*gpfWriteCallback)(int x,int y, int width,int height, void *data, int
pixelwidth);
gpfRead(gpf_handle_t handle,gpfReadCallback cbR, gpfIndicatorCallback cbI);
/* Try to read the selected image. the callback will be used like you would use
* write() and PutBox(); I.e. you call it with the rectangle you have data for
* and it returns the number of pixels it processed. This gives a small complication,
* if it doesn't accept whole lines, but that can be taken care of by a single
* glue function that handles the case by trying to first send the rest of
* incomplete lines.
*
* The reader-libs should use reasonably sized buffers, like one line for simple
* format, or 8 lines for JPG. Don't know yet what to do about interlaced or
* progressive formats.
*
* If the cbI callback function is not NULL, it will be called 100 times
* during the reading, allowing you to display a progress indicator.
*/
gpfWrite(gpf_handle_t handle, gpfWriteCallback cbW, gpfIndicatorCallback cbI);
/* Similar to gpfRead.
*/
CU, ANdy
--
= Andreas Beck| Email : [EMAIL PROTECTED] =
Christoph Egger
E-Mail: [EMAIL PROTECTED]
Re: targets and ?sources?
Hi ! Even better: We make a "smart" module that tries to guess the image-type. It will then try to load the corresponding handler (using the equivalent Perhaps I should assimilate my "LibDataType" library into GGI, under a new name like LibGFFD (generic file format detection). Using suffixes and magic numbers, it can recognise over 400 file formats, This sounds good. Will it use the /etc/magic database, or its internal methods ? Using LibGFFD, this new picture library could detect the filetype, and then look it up in the gpf.conf file to find which DLL to load to handle the image. Any interest in this approach ? Yeah - sounds good. Looks like we are striving to reinvent gnome :-) ... CU, ANdy -- Andreas Beck | Email : [EMAIL PROTECTED]
Re: targets and ?sources?
On Sat, Feb 05, 2000 at 04:46:58PM -0500, teunis wrote: On 5 Feb 2000, Marcus Sundberg wrote: [EMAIL PROTECTED] writes: The second library should be a simple glue-layer between the first library an LibGGI. The reason to make two libraries that a generic image loader/writer that is _not_ tied to any graphics/window system is badly needed, and the first library will be just that. On image grabbing: This is good, very good. Would work for stills, scanning, digital cameras, On -video- capture (ie stream of messages): No. Absolutely not. Frame grabbing has -terrible- problems with two things: 1. It goes very fast. Hard to capture 30fps at 640x480 straight into a raw buffer... ggitv gets 25fps in 640x480 by video-card-X-gfx-card (NO overlay). 2. Drivers aren't very stable... *sigh* [for bttv] which driver are you using (driver-version, hardware) ?? Anyways, you'd have to do a different interface for -video- capture than for image capture anyways. Mostly due to latency problems. I want that personally (mind you, I don't use GGI to -play- videos either other than to supply a frame to write to ... it doesn't fit the purpose) G'day, eh? :) - Teunis thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(-
Re: targets and ?sources?
DOHT! I didnt write that, that was, I think ?Marcuses? response... [EMAIL PROTECTED] writes: The second library should be a simple glue-layer between the first library an LibGGI. The reason to make two libraries that a generic image loader/writer that is _not_ tied to any graphics/window system is badly needed, and the first library will be just that. On image grabbing: This is good, very good. Would work for stills, scanning, digital cameras, On -video- capture (ie stream of messages): No. Absolutely not. Frame grabbing has -terrible- problems with two things: 1. It goes very fast. Hard to capture 30fps at 640x480 straight into a raw buffer... ggitv gets 25fps in 640x480 by video-card-X-gfx-card (NO overlay). 2. Drivers aren't very stable... *sigh* [for bttv] which driver are you using (driver-version, hardware) ?? thats all Jan Adam Scislowicz
targets and ?sources?
I just started thinking about my last post in a different way. Should we implement something like sources in ggi, wihch would allow frame grabbing, image loading, etc? I think this would also touch on GII some, and not just in the frame grabbing situation, I think with relative simplicity we could implement a progressive source for networked images using GII and GGI? Does anyone else like this idea? -Adam Scislowicz
Re: targets and ?sources?
[EMAIL PROTECTED] writes: I just started thinking about my last post in a different way. Should we implement something like sources in ggi, wihch would allow frame grabbing, image loading, etc? Yes, it should be implemented in ggi, just not in LibGGI. Image loading should ideally be written as two libraries: One library that does not use LibGGI and does not know about visuals. It should dynamicly load readers/writers for different image formats, and read images into/write imaghes from it's own simple structure (basicly just width, height, format and a pointer to the data). It should also be able to convert images between different formats. The second library should be a simple glue-layer between the first library an LibGGI. The reason to make two libraries that a generic image loader/writer that is _not_ tied to any graphics/window system is badly needed, and the first library will be just that. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: targets and ?sources?
On 5 Feb 2000, Marcus Sundberg wrote: [EMAIL PROTECTED] writes: I just started thinking about my last post in a different way. Should we implement something like sources in ggi, wihch would allow frame grabbing, image loading, etc? Yes, it should be implemented in ggi, just not in LibGGI. Image loading should ideally be written as two libraries: One library that does not use LibGGI and does not know about visuals. It should dynamicly load readers/writers for different image formats, and read images into/write imaghes from it's own simple structure (basicly just width, height, format and a pointer to the data). It should also be able to convert images between different formats. The second library should be a simple glue-layer between the first library an LibGGI. The reason to make two libraries that a generic image loader/writer that is _not_ tied to any graphics/window system is badly needed, and the first library will be just that. On image grabbing: This is good, very good. Would work for stills, scanning, digital cameras, On -video- capture (ie stream of messages): No. Absolutely not. Frame grabbing has -terrible- problems with two things: 1. It goes very fast. Hard to capture 30fps at 640x480 straight into a raw buffer... 2. Drivers aren't very stable... *sigh* [for bttv] Anyways, you'd have to do a different interface for -video- capture than for image capture anyways. Mostly due to latency problems. I want that personally (mind you, I don't use GGI to -play- videos either other than to supply a frame to write to ... it doesn't fit the purpose) G'day, eh? :) - Teunis
