incremental dodge/burn/airbrush?
Hi There, I'm loving the gimp and its getting ever so close to making me abandon photoshop. The #1 issue I see right now is the desire for incremental dodge/burn/airbrush tools the way they work in Photoshop. Any plans to implement such a mode? Thanks, Larry Morgan [EMAIL PROTECTED]
Gimp-Savvy.com
What do folks think of adding either of these two resources to the Gimp? /Xtns/Web Browser/Gimp-Savvy.com --> http://gimp-savvy.com/ /Xtns/Web Browser/Grokking the GIMP --> http://gimp-savvy.com/BOOK/ Best regards, Carey Bunks Dr. Carey Bunks Senior Scientist BBN Corp. 70 Fawcett St, 15/2A Cambridge, MA 02138 tel: 617-873-3028 fax: 617-873-2918 email: [EMAIL PROTECTED]
Re: new stuff for gimprc
On 13-Apr-2000 Sven Neumann wrote: [many snips] >> (undo-levels 15) > > The current number of undo-levels is fine, IMHO. At least the 15 you proposed > are a bit too large. Might go well for web-designers (small images) with a > large tile-cache, but... > > Let's see what other people have to say on this subject before we change a > nything... Some good ideas that I (as more of a user than a developer) second (or third). Another idea might be some more questions when you first install. Ie: in the midst of the messages which say which directories have been created sucessfully (more on this in a second) maybe a couple of questions (wizard?) with something like "how much memory do you want to allocate to the gimp" (along with some suggestions), "do you want global paint options on or off" (along with an explanation) and so on. This I think would make things much easier on newbies who might not understand terms such as "tile cache size" and so on. As for the messages that are displayed on first start up, how many of these are needed? If there are errors yes, definatly, but do you need to show them a screen of "x created successfully" messages? If you are concerned with silently making $HOME/.xxx directories (which 99% of the *nix programs out there do anyway), maybe just keep the "we will create the directores..." message. My 0x02 regards arcterex, gimp user at large -- Alan <[EMAIL PROTECTED]> -=||=- http://arcterex.ufies.org You look like a million dollars. All green and wrinkled.
Re: new stuff for gimprc
Sven Neumann wrote: > > We will have to hardcode this into the session managment as there is no > sessionrc distributed with the gimp. I'll add some code that opens those > dialogs if no sessionrc is found. Hmmm, I vaguely remember that exactly > this has already been done, but appearantly it does not work. Yes, I've added it to session_init() and the code still looks ok but it seems to do just nothing :( It worked at least when I hacked it and I don't remember when it didn't work anymore. --Mitch
Re: new stuff for gimprc
Hi, > I propose that we make a few changes to the default gimprc (either the > system-wide or user one, whichever the options fit best). The changes should be done in app/gimprc.c. The systemwide gimprc should be changed too to reflect those changes. > The main thing is that session management should be turned ON. OK, I second that. > and there should be a default session w/ the toolbox, layers, option, > and brushes dialogs. We will have to hardcode this into the session managment as there is no sessionrc distributed with the gimp. I'll add some code that opens those dialogs if no sessionrc is found. Hmmm, I vaguely remember that exactly this has already been done, but appearantly it does not work. > Some other, nice (imo), proposed changes to gimprc: > - > (global-paint-options no) Yep! > (info-window-follows-mouse yes) Why not. > (undo-levels 15) The current number of undo-levels is fine, IMHO. At least the 15 you proposed are a bit too large. Might go well for web-designers (small images) with a large tile-cache, but... Let's see what other people have to say on this subject before we change a nything... Salut, Sven
Re: getting around the GIF problem.
On Tue, Apr 11, 2000 at 09:13:40PM -0700, Karl Williams wrote: >I would like to mention that there is another format that your organization >might want to take an interest in. It is called ILBM , InterLeaved Bit Map, The perhaps main problem with IFF/ILBM is that it simply isn't widely-supported. The reason people still use GIF is that it is supported in nearly every web browser today. People are (slowly) moving away from GIF, to PNG. I'd suppose PNG has _much_ better compression ratios than IFF/ILBM, simply because computers have become much quicker since the A500 days. >I should mention >the downside, that pictures that I have ported over are 5 bit (32 colors) >converted over to GIF, thats the capacity of ILBMs - becuase of the nature >of the Amiga computer in its low resolution state. The AGA chipset lifted this limitation, BTW. >Becuase I cant use GIF in my own programs becuase of the Unisys licence >problem. I have to develop a program that reads ILBM the format. Its >already >been an undertaking project - so far. I plan to release my libraries as >public domain. While IFF/ILBM format could be useful (especially for interchanging graphics files with the Amiga), I doubt it would be very useful for general use. For that, we already have PNG. GIMP uses a library called libpng (which is free as in GPL'ed), which doesn't have any patent restrictions or royalty fees either. The bottom line: We already have PNG, which supports 8-, 24- and 32-bit modes (alpha), so we would probably not gain anything _big_ by implementing IFF/ILBM. However, nothing is lost either, and I remember looking _very_ hard for such a program a couple of years ago :-) /* Steinar */
