Stelios, sorry for the duplicate, I keep forgetting which email I'm subscribed with here, and Google is of no help keeping it straight -- there's no way to filter a message to assign the reply address. -- Ben/AA7AS
On Sun, Mar 14, 2010 at 6:21 AM, Stelios Bounanos <[email protected]> wrote: > Please think very carefully before creating a public API to process > received images. We certainly don't want to deal with dynamically > loading shared objects at runtime, as this will require something like > libltdl to do portably. I was thinking of functions that were compiled in on a per-version basis, not run-time loadable functions. So the first version might have two or three of the most useful functions; the next version four or five; etc. It's still only sane to have a standard "make a process" definition. > IMO it's much better to just have an option specifying a program to be > called with the filename of the image saved in PNG format. This creates two files where no file needs to exist (the data is already in memory); it slows *everything* down (adjust brightness is now the hugely cumbersome [fldigi save file, brite load it, brite process it, brite save it, fldigi reload it]) so processes that were live, running in tiny fractions of a second, now thrash your disk to no good purpose at all, are no longer visibly interactive, and take much, much longer. These can be significant files. I *really* don't need two multi-megabyte temporary file writes to my drives just to adjust brightness or filter noise. > It's trivial to get to the RGB data and there are many > image processing libraries than can open PNG files directly. Nothing wrong with saving a PNG, and the program already does it, both automatically and on command. I'm a huge fan of PNG; my commercial image processing software was one of the first to support PNG when it came out, many years ago. Heck, we can even write MNG files, and that *really* puts us in a small minority! But it is a mistake to think that "PNG out, postprocess(PNG in, function,PNG out), PNG in" is even remotely similar to adding in-program noise removal, dynamic range controls, etc. These are extremely lightweight functions, too. The only likely weight to them at all will be the UI. _______________________________________________ fldigi-alpha mailing list [email protected] https://lists.berlios.de/mailman/listinfo/fldigi-alpha
