Re: Thanks (Re: Gimp splash images)
On Wed, Jan 12, 2000 at 03:15:55PM -0800, Tuomas Kuosmanen wrote: On Wed, Jan 12, 2000 at 10:24:09PM +, Austin Donnelly wrote: On Sunday, 9 Jan 2000, Marc Lehmann wrote: On Sun, Jan 09, 2000 at 05:08:26PM +0100, "Guillermo S. Romero / Familia Romero" [EMAIL PROTECTED] wrote: that means quality loss (original where 256 colors only?), and I am looking Yes, quality loss in many cases... for the PPM, not derivatives. In the files dir I saw a message saying that You can get the ppm files by checking out the relevant cvs revision of that file (tigert's page even mentions the revision numbers) I vote for releasing gimp 1.2 with Tigert's 1.4 "floating balloon" splash screen. I was thinking of that too. People seem to like that one. the baloon, the rocket, or the new one are my faves for 1.2. I really like the newest one. Nice work. Adrian
Re: Photo Archive Pre-Announcement
On Sun, May 07, 2000 at 10:15:36PM -0700, Kevin Turner wrote: Neat stuff. Now to bug you for wish list stuff ;- Is the photo credit for this image stored anywhere? Hmmm, might be cool to have the ability to at least provide all the info in a href="http://purl.org/dc/"Dublin Core/a or similar metadata standards. Some way to make use of EXIF style data may be cool too, as I suspect a fair amount of online submissions may be coming from digital cameras. Can I donate my photo(s) to your archive? hmm, yes? Are descriptions/keywords stored in meta-data chunks of the image files themselves? oooh, that would be neat. Some indicies (e.g. those used by libraries) have a finite and discreet set of keywords used for subject indexing. That isn't true here, is it? I would suggest a set of required key words, and then for the rest, anything goes. Required stuff could be like "color/bw", "portrait/landscape/whatever", "scanned/digicam", "natural light/flash", "still photo/time lapse/multiexposure", "people/nopeople", etc. Can I search on other things in addition to keywords? (e.g. "I want an image that's larger than 640x480 and is stored in a lossless format.") indeed. Silly feature requests: wavelet based "these images are sorta the same" categorization since its a directory of images, perhaps exporting it via some standard directory system (like say LDAP...), with approriate schema of course. Adrian
Re: Feature idea: rotate brush while following a path
On Mon, May 29, 2000 at 09:03:11AM -0400, Tom Rathborne wrote: Raphael: On Mon, May 29, 2000 at 02:28:33PM +0200, Raphael Quinet wrote: Well, it looks like I will not be able to attend the GIMP Developers Conference at the end of this week (too bad - I really wanted to be there), so here is an idea that could be discussed: there could be an option to rotate a brush automatically according to the local tangent of the path that the brush is following. To make it even nicer, the user should be able to specify what is "local": how many pixels should be taken into account for calculating the angle. If I recall correctly, DeluxePaint IV on the Amiga (or DeluxePaint Animation on the PC) and an animbrush auto-gen facility which let you turn your static brush into an animated brush by rotating it and storing all the frames. Maybe I did that by hand - I don't remember now. Anyways, this would end up being a _lot_ of data to have in your image hose so I agree that rotating the brush automagically to match the local tangent is a good idea. I think this is something I would like to see as well. The simplest approach would be increase the "angular" resolution of Pipes, and then just generate a pipe by rotating the brush shape. The primary reason I would like to see this, is to make it possible to create a "gimpressionist" style painting tool. The plugin currenty works by taking a single brush shape, rotating it X number of times, and then painting to the image with whatever rotated brush fits closest to any edges it finds in the image. No reason we cant do that with a painting tool ;- I think the ideal solution is pretty much a 2.0 thing, and that is generalizing all the paint tools and storing "patches" that represent various tools. Tools like DeepPaint seem to get a lot of distance out of this, and we could do it as well. What other transformations could be added? How about: blur, colour rotation, scaling... Oooh, here's an interesting question: what happens when you're using the smear tool with a brush which gets smaller the faster you go? Is the smeared data shrunk along with the brush? That could look really really cool. Or the opacity changes as you paint, or the brush rotates with pen pressure, or the spinning brush gets its color from a gradient based on pen tilt, or ... ;- Generilizing all this stuff will offer a ton of flexibily, and storing "patches" of it will make users happy. Of course all these transformations should be available on-the-fly, and it would be nice to be able to load an image hose and then just "add" another dimension to it - a dynamic version of the image hose save dialog. To some small degree, we can already do this, at least with respect to tablet pressure. You can load an Image pipe which changes based on brush direction and speed, and then alter its opacity or size based on tablet pressure. Granted, not as flexible as we'd like, but its kind of cool anyway, and demonstrates its doable. Adrian
Re: [gimp-devel] Gimptool in Gimp 1.0.4
On Tue, Aug 01, 2000 at 09:34:10AM -0400, Zachary Beane wrote: This was a legitimate screw-up in one version of Red Hat, IIRC. They did not include the gimptool script in either gimp or gimp-devel RPMs. This became an issue on IRC for several people, until we finally figured it out. 6.0 had no gimp-tool 6.1 has it in gimp-devel 6.2 has it in gimp-devel pinstripe has it in gimp-devel Adrian
Re: RFC: The future of The GIMP
On Tue, Dec 12, 2000 at 05:59:56PM +0100, Fernando Herrera wrote: Tue, Dec 12, 2000 at 04:40:54PM +0100, Michael Natterer escribió: o Think about a new way to handle plug-in distribution As more and more plug-ins go into the main gimp distribution (and a lot of plug-ins are wating to be included), it becomes difficult to maintain them all. Core developers are busy enough with the core application and shouldn't have to fiddle with all those plug-ins. If we can think of a better model for plug-in maintainance and distribution, we should try to implement it in this branch. What about using a distribution system like helix-updater (or newer RedCarpet)? We can use a machine (i.e: plugins.gimp.org) where gimp itself (or gimp-udater) retrieves a xml list from(http), with all the plugins stored in the "system". The "system" can store a lot of precompiled plugins, with version numbers, priority for upgrading , etc Also a good interface for maintaners, to upload new versions is required and maybe a main coordinator yeah, indeed. I've put a little bit of investigation into this, but never pushed it too far. Just a matter of doing it seems. We have folks involved with Red Hat Network, Helix Updater, Eazel Services, rpmfind, and apt-get on this list and involved with the project, somehow I think we can figure something out ;- Adrian
Re: RFC: unified system of PaintObjects (long)
On Fri, Feb 09, 2001 at 02:28:57PM +0100, Jens Lautenbacher wrote: Tuomas "\"spectrolite\"" Kuosmanen [EMAIL PROTECTED] writes: On 09 Feb 2001 11:32:16 +0100, Jens Lautenbacher wrote: Hi all, This mail comes from some discussions I had with Sven around the time just before 1.2.0, the recent discussion about textures and natural painting and a chat on IRC yesterday with Sven. [ SNIP ] [ WARNING: This mail contains some scary ideas ] [ SNIP ] Another thing is I really wouldnt want to *lock* the parameters to the brush file. It would be nice if the options dialog had a checkbox to "[x] use default values" but unchecking that would make it possible to remap the XInput modifiers to different things. It would also be good if one could then save this new resulted brush in a new file. Yes, one thing that would be really needed is a good interface for the multidimensional providers. Actually all of them could be edited with the same interface, and just on save time you would decide if it should be saved as a texture, brush or pattern (or anything else we want to come up with) The ideas that were tossed around circa a year ago was a "mixing board" type of interface where you build up combinations and relations. To some degree, there are alot of parallels to analog synths as well, where you have this dozen input sources, and a dozen filters, and a dosen places to hook them to. Lots of power there. Of course, this is far from a intuitive interface. If your've ever played with an old analog synth and spent 20 minutes making it go "swoooshkkkakckakkcacacaaaoo" before, and then actually try to make useful sounds with it, you knwo what I mean. For 99% of users, the best interface would probabaly just be a list of "presets" of already written and saved "patches". I belive this is how Deep Paint, works for example... So would this mean one could have something like multilayer XCF files as patterns, that "dig in" the layerstack if one uses more pressure? This would be pretty awesome. The "Tommer" example comes to mind first: Have something like this: Layer 1: skin pattern Layer 2: some red goo Layer 3: some tissue layers Layer 4: guts and stuff Layer 5: rib bones or something exactly. and it is actually quite a good and funny example. heh, indeed. what you said were good examples how this stuff gives new possibilities from the user perspective. But the main motivation for such a work should be clean, elegant source code first... Adrian
