Re: [Gimp-developer] A few suggestions forThe Gimp
On 4/1/06, Richard Reddy wrote: a lot of text snipped > As director of photography for North American Women's Baseball League > (NAWBL), I know that searching and sorting images can be very > time-consuming work. Using Gimp you could automatically transfer image > metadata to tags. It would be very useful to do a search involving all the > images shot at f/2.8 or f/4.0? All the photos shot with a particular lens. > All the photos shot at ISO 100, or ISO 800. Photos of women who pitch, > play for a particular team, have a batting average over 300, et cetera. A > game? > All the photos on the same day. Can't see why graphics manipulation application should have all fo the above. Most modern trend is to have basic retouching tools, batch processing/browsing and tagging in a photos browser (e.g. Adobe Lightroom), because it's simply a more obvious and convinient way to go ;-) If you are planning to use GNU/Linux, I suggest you having a look at Digikam, F-Spot, KPhotoAlbum (ex-KimDaBa) and Album Shaper. Album Shaper is available for Windows as well. Most, if not all of them use databases, and they will have all organization/tagging features you need much faster than GIMP, if someone ever starts implementing these features in GIMP. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A few suggestions forThe Gimp
Hi Richard, As my englis his quite poor, i'm not sure i've understood, but i try. i have been teaching photoshop for several years. But in the same time, i was using Gimp and only Gimp at home. It is always hard to change. Of course, Gimp will lack some features, if you see it from Photoshop's point of view. But take it the other way, and Photoshop will have to be improved too. But i also feel sometimes that we can work much faster with Photoshop, but not always. And, in fact,I don't know if productivity is a good way to judge free software. I'm not sure. Here is what ia can tell 1. Image Browser : there are many image browser, even free. The question is why developping one for Gimp ? There are so many things to do, and most part of developper are really working on so many things. But may be i have something that could help you. If you run Linux and have Gqview installed, I have made a simple C script that allows you to run it from within Gimp (Simple). I'm beeing modifying Gqview for a better integration, but i've not reach that point i can publish it. The script could be esaily changed for another app, if it can help. it's not including the DB feature you tell about, but i take it somwhere. If one day i become a good developer. ;) 2. Your proposal seem to be : more complete theming. why not. I've already propose on Sven's website to have profiles on Gimp that could allow very important customization for each Gimp purpose (an UI for a photographer, is not a goos UI for a 3d Designer : see Bart's proposal http://www.neeneenee.de/blender/toolbar.png : it is typical from 3d softwares. But anybody can already add theme. Just have to do some. Tango is particularly working on it. Just wait and see. cheers Cedric ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A few suggestions forThe Gimp
Date: Sat, 1 Apr 2006 14:34:45 +0100 (BST) From: Alan Horkan <[EMAIL PROTECTED]> > CS browser is just one of those flat-file Microsoft thingies. > Why not incorporate a real relational database? So, my > suggestion is to dramatically improve workflow by developing a > MySQL database companion for Gimp, that allows users to search > and sort large image databases like mine (30,000 digital images). > Images could be tagged while they are being processed, or batch > tagged. Interesting idea. I suspect you would need to sponsor a developer if you really wanted it to happen though. > As director of photography for North American Women's Baseball > League (NAWBL), I know that searching and sorting images can be > very time-consuming work. Using Gimp you could automatically > transfer image metadata to tags. It would be very useful to do a > search involving all the images shot at f/2.8 or f/4.0? All the > photos shot with a particular lens. All the photos shot at ISO > 100, or ISO 800. Photos of Programs like Bibble Pro, Aperture (from Apple) and Adobe Lightroom sound better suited to these tasks of batch processing sets of photos and RAW files. These are seperate and distinct programs from the likes of Adobe Photoshop, Corel Paint, and Macromedia Fireworks. I wonder if trying to shoehorn even more functionality into the GIMP in a clean and organised way is really managable. Check out KPhotoAlbum (http://ktown.kde.org/kphotoalbum/), which previously was named KimDaBa (KDE Image Database). It uses an XML file rather than a relational database for its back end storage, but it has this kind of search capability (including user tagging, date ranges, and EXIF data in the current pre-release snapshot, via SQLite). It's very fast. I have about 12,000 images and there's very little delay on just about any operation. There has been some discussion about using an RDBMS backend for storage vs. the XML backend. My own calculations suggest that at least up to 50,000 or so images there's no need for anything more elaborate, and there are significant advantages to the textual XML storage. That said, merging image storage with image manipulation doesn't feel quite right to me. KPhotoAlbum was designed for one purpose -- to maintain large collections of images with excellent search capability. The GIMP is also designed for one purpose -- to create and edit images. These two functions seem completely orthogonal to me. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A few suggestions forThe Gimp
(As Carol mentioned the formattting in your mail was troublesome. I think maybe you need to change you line wrapping settings to less than 80 characters. Fortunately the email program I use can correct for that.) On Sat, 1 Apr 2006, Richard Reddy wrote: > Date: Sat, 1 Apr 2006 00:42:46 -0500 > From: Richard Reddy <[EMAIL PROTECTED]> > To: Gimp-developer@lists.XCF.Berkeley.EDU > Subject: [Gimp-developer] A few suggestions forThe Gimp > > Greetings Developers, > > I've been using Photoshop since version 1 of "Photostyler". Before > that, I dreamed of digital images while using an 8086 PC and CGI > graphics. Photoshop is a good application, but I feel a growing > distaste for proprietary software. This is one answer to the question of why so many users want the GIMP to behave more like Adobe Photoshop, they do not dislike Photoshop but they do dislike the limitations of proprietary software. (People have asked and I think it is worth highlighting an opinion from a long term Photoshop user like you.) > So, for 2006 my photography business migrates to the GNU/Linux box. I > thought. A mutual friend, Richard Stallman, said I should run them by > you, so here you are. Does he still pronounce the SLASH in GNU/Linux? > 1. A browser just like Photoshop. Gimp 1.0 had a built in browser called GUASH but (if I recall correctly) there were so many better thumbnail browsers out there and GUASH wasn't getting a whole lot of maintainance love and the integration benefits were minimal. > No, better not. The browser is junk--very clunky and hungry for system > resources. Okay ... so maybe it the current stategy is a good idea then. > CS browser is just one of those flat-file Microsoft thingies. Why not > incorporate a real relational database? So, my suggestion is to > dramatically improve workflow by developing a MySQL database companion > for Gimp, that allows users to search and sort large image databases > like mine (30,000 digital images). Images could be tagged while they > are being processed, or batch tagged. Interesting idea. I suspect you would need to sponsor a developer if you really wanted it to happen though. > As director of photography for North American Women's Baseball League > (NAWBL), I know that searching and sorting images can be very > time-consuming work. Using Gimp you could automatically transfer image > metadata to tags. It would be very useful to do a search involving all > the images shot at f/2.8 or f/4.0? All the photos shot with a > particular lens. All the photos shot at ISO 100, or ISO 800. Photos of Programs like Bibble Pro, Aperture (from Apple) and Adobe Lightroom sound better suited to these tasks of batch processing sets of photos and RAW files. These are seperate and distinct programs from the likes of Adobe Photoshop, Corel Paint, and Macromedia Fireworks. I wonder if trying to shoehorn even more functionality into the GIMP in a clean and organised way is really managable. > Such a database could be great learning tool for spirited amateurs. Incidentally are you familiar with Photo.net? > in the browser. Adobe cannot afford to package a powerful database > engine, because they would be paying license fees! I'm pretty sure Adobe could use MySQL just as easily as they already use Python. > 2. The much talked about user interface. Nobody will agree on one, any > more than they agree on the ten best photographs. Why not have > configuration options, that you could test, and pick a design you like? The cost of offering more interface and configuration options is maintainance. It is more than twice as much work to maintain two inferfaces. Just look at how upset some people have been getting over the differences between the GNU Image Manipulation program and GIMPShop (and previously Cinepaint). > Gimp looks pretty good on Fedora 5--because Fedora 5 has a beautiful > design for the desktop. Reminds me of Japanese art. So, this > suggestion is just to provide different skins--as many as people care to > develop or download. There are groups already interested in providing themes for GTK and Gnome applications. This doesn't usually happen within the developement of the GNU Image manipulation program. (I would be interested to see a fully featured theme with dark widgets like those which are so popular in 3D software and high end video production.) In response to your comments about one size not fitting all: I dont use multiple desktops, ever. Your suggestions about making even more use of mulitlple desktops sounds complicated. > It's a bitch to port MySQL and ODBC to windoze, in conjunction with a I'd be surprised if it wasn't already there. > MySQL database feature. Power is leveraged, by utilizing system leveraged utilizing where is Dave Neary :P (It is
Re: [Gimp-developer] A few suggestions forThe Gimp
hello, i cut a lot of really positive and good comments from this email. i am sorry to do that, but the format was difficult for this mail list. did you send mail in html format? maybe the line length was too long. at any rate, your email included wishing for an image browser based on the MySQL database. this is sort of an old url by now, but the original gimp news person wrote this about that: http://www.xach.com/aolserver/mysql-to-postgresql.html i will totally admit that i have no idea how much this applies to your wishes, but one thing about the original gimp news person; he really loved linux. there is another thread on another list right now about the xsane plug-in. i mention it here because this might be a very good approach to get what you want. and if it is written properly with a good base software, then all of the different art applications should/might be able to benefit from it. the xsane plug-in works this way. you install xsane and it sees if you have gimp installed and adds itself to the menu. there are always problems with this plug-in but it is dealing with hardware which is not as simple or predictable as pure software applications. it is difficult for me to imagine what it is that you want, especially given the way that photoshop doesn't work on linux. i tend to refuse to use wine to get access to apps that do things that already work (often better) here on linux. but if you could find clever and ambitious people who could possibly write this thing that you described and write it in a way that works with all of the gpl'd applications, we would be certainly getting somewhere and the total of all of these groups will probably make the giants beg for mercy, or something like that. maybe quiver and die. or even better, re-define themselves and provide a better challenge next time around. it would be a nice project for some new and motivated upstarts! thanks again for the positive feed back. microsoft tends to produce a whine that is so irritating at times that the desire to remove access to the software becomes very strong! and that is no way to live. carol ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] A few suggestions forThe Gimp
Greetings Developers, I've been using Photoshop since version 1 of "Photostyler". Before that, I dreamed of digital images while using an 8086 PC and CGI graphics. Photoshop is a good application, but I feel a growing distaste for proprietary software. So, for 2006 my photography business migrates to the GNU/Linux box. I see some room for improvement--user interface, color management, file system navigation. Let me give you a list, in order of importance, of the ten things that matter most in photography. 1 image content 2 image content 3 image content 4 image content 5 image content 6 image content 7 image content 8 image content 9 image content 10 other concerns Gimps problems are smaller than Photoshop's, in my view. They are a much smaller concern than image content. Really, content wins the day, a message I wish to communicate to fellow photographers who look for good images in fancy cameras, or the latest software releases. If we're all doing something together--like creating and using image software--don't miss the spirit of the enterprise by rolling out some elite criteria to judge the work of friends. Digital fine art is an oxymoron. Want fine art? Try a darkroom! What really makes digital work is content (and colors), because it certainly lacks dynamic range and resolution (and the beauty of silver-based papers). Visual art is all about feeling. So another good question is how do you feel about underwriting Adobe? They employ many nice people--and some gifted software engineers, but the company is just another greedy corporation, charging high prices, and hiding the code. Passing out those nondisclosure agreements, which now include impressions from previous lives and the kitchen sink. I selected Gimp because the whole project feels good. You create software for the same reasons I create photographs So, if Gimp has problems, I'll live with them (or participate in solving problems). Gimp is really a marvelous bit of engineering--the only problem I can see is perhaps the team underestimates what it can do. I do have a few suggestions developers might like. I'm sure you have no shortage of ideas, and limited consensus, so this is just food for thought. A mutual friend, Richard Stallman, said I should run them by you, so here you are. 1. A browser just like Photoshop. No, better not. The browser is junk--very clunky and hungry for system resources. CS browser is just one of those flat-file Microsoft thingies. Why not incorporate a real relational database? So, my suggestion is to dramatically improve workflow by developing a MySQL database companion for Gimp, that allows users to search and sort large image databases like mine (30,000 digital images). Images could be tagged while they are being processed, or batch tagged. As director of photography for North American Women's Baseball League (NAWBL), I know that searching and sorting images can be very time-consuming work. Using Gimp you could automatically transfer image metadata to tags. It would be very useful to do a search involving all the images shot at f/2.8 or f/4.0? All the photos shot with a particular lens. All the photos shot at ISO 100, or ISO 800. Photos of women who pitch, play for a particular team, have a batting average over 300, et cetera. A game? All the photos on the same day. This information could quite helpful for batch-processing images, as you might want to clean noise from high ISO files, sharpen images with narrow depth of field, et cetera. If you need to consult backup files for images lost in a crash, sorting by date is very helpful (speaking from experience). With metadata, and user criteria in the tags (associated to files that need not be opened to perform searches/sorting) it could be a very power tool for organization--something that graphic artists and photographers would value highly. Such a database could be great learning tool for spirited amateurs. What speeds to stop motion? What speeds for flowing water? How does digital perform at higher ISO? I recommend tagging all photos where contrast range in a scene exceeds the reach of a digital CCD. (happens a lot!) A relational database can be a very powerful tool, and since digital is such a productive medium, photographers really need one. There's no way on earth Adobe could build a product that competes with MySQL--the world's best database engine. Tools that improve the WORKFLOW of photographers and their clients would be worth considering. You can see Photoshop is making a small effort in CS, with sort routines in the browser. Adobe cannot afford to package a powerful database engine, because they would be paying license fees! But Gimp already has a wonderful neighbor, who works for free. 2. The much talked about user interface. Nobody will agree on one, any more than they agre
