Interview with Gimp Maintainer 89
palpatine writes "Linux.com has an interview with Manish Singh (yosh), the chief maintainer of the Gimp project. "
Yosh mentions that they are in a feature freeze now
(and here is the list of frozen features) for Gimp v1.2. Tons of cool stuff to lust after.
Re:gimp needs photoshop plugin support (Score:2)
Re:Time to shrinkwrap GIMP. (Score:1)
I just downloaded and installed GIMP for Win32 (9,244,720 bytes), and I've been having some problems with it. It's not finished yet--don't shrink-wrap it yet! I'm not sure if the problems are GIMP problems or GTK problems or personal problems (although it runs wonderfully on the RedHat incarnation of this machine).
More specifically, the problem I'm having is it won't load past the "extension_script_fu" phase of startup (it did once, crashed, and now I have to use the Task Manager to end the task). Any ideas?
darren
Re:using Photoshop (Score:1)
For starters try The Gimp Manual [gimp.org] which in my opinion is quite well done. It might be considered a little outdated, but it's a great intro to the gimp.
MDI (Score:1)
invalueable as it allows one to quickly rearrange all windows
(tile or cascade) and if I open ten Gimps I can have ten image
categories neatly packed in their own respective parent windows.
Is there any plan to provide an optional (of course) MDI support?
Re:Gimp Is cool and there's a win32 version (Score:1)
Christoph
A suggestion, was Re:Professional Color Matching? (Score:1)
Moderate me up!
Tha KIMP.. heee.. (Score:1)
Personally, I always thought the entire point of the free software movement set into motion by the GNU Project (of which GIMP is a part, unless a lack of sleep has starved my brain of oxygen) because of a desire for freedom. Is freedom of choice no longer a recognized part of those freedoms? I personally think that it's good that as many programs as possible get ported to as many platforms as possible.
Reflecting upon the breaks between the various UNIX systems prior to Microsoft's emergence as a giant with its domination of the OS market with Windoze, I don't believe that it would be such a good idea to limit our choice of platforms today as it was yesterday.
While I might prefer, say, Red Hat Linux, I don't think it's a good thing if software is only developed for Linux. It really frightens me when I see a lot of software developed solely for Linux using Intel-compatible chips. I certainly don't want to be tied down to Intel. Ugh. After all, maybe I'll want to go with Apple and their crazy (and it seems crazy fast) new and soon to be released products.
In short, porting is a good thing. People should do more of it. After all, if you give up just a single freedom, especially something so basic as the freedom of choice, other freedoms are sure to follow soon thereafter. Don't kid yourself, all of them are essential.
Re:using Photoshop (Score:1)
I'm really worried buy this argumentation
I constantly hear from people that they can't learn another software, it's too hard to learn it again, and so on, either about Gimp/Photoshop or (it's my domain) musical software.
You have all to realise that the concepts are really the same, it's just a matter of passing one week with the program to know where the things are.
Sometimes I feel like you are all so old that your neuronal network is completly blocked on a scheme :)
And it never hurts to let your neurons exercise and learn to use another device... sometimes I think of it as a survival guide. Being able to use any software help not to be blocked when you're not on your own system and you have some work to finish..
does film work mean non-linear editing? (Score:1)
I'd really love to see an open source premiere type tool. Is that what this means?
I'd love to see an NLE on linux, but I think getting capture card drivers to work well would probably be pretty hard.
GIMP in schools. (Score:2)
Andrew G. Feinberg
Re:Is it that simple... (Score:1)
Capture card drivers would be particularly important for an NLE, though, because programs like Premiere use a DV or MPEG camera's hardware codec to speed things up considerably during editing. In other words, you need to have your camera plugged in via the firewire while you're editing, even if you're not capturing anything. My PII-350 can't display DV in full resolution in real time using a software codec, I need the camera's hardware codec to make it work.
In the MS world, broken premiere drivers are a big problem -- the app tend to crash a lot if you buy a cheap board (with crummy drivers).
Maybe open source drivers would solve the problem... it would be cool to find out.
It would also be very cool if real hollywood money started pouring into linux development.
Re:Professional Color Matching? (Score:2)
I wonder where you may have heard such rumblings...really. I'm a graphic designer and, although the GIMP is not bad, it doesn't approach Photoshop 5 when it comes to functionality. GIMP is closer to Photoshop 3. The text tool is a dog, among other things.
The GIMP is a good tool, but I won't call it professional yet. Remember that most graphic designers are not the kind of people who like putting their hands down the OS. Look at how many of them are using MACs!
I'm sure the GIMP will keep improving (I hope so), but sometimes you have to face the hard reality of the facts: out of Photoshop, Fireworks, Freehand or Illustrator, there's nothing much a professional graphic designer will work with, me included. Maybe e-picture on BeOS...
Now, I' d love to see all my favorite apps ported to Linux or BeOS, so I won't have to boot NT anymore...although it works_well_for_what_I_do, without crashing (yes, it's possible). Maybe it'll all happen with the Corel/Debian distro...
Keep on the good work!
Just my
Reluctant Realeases. (Score:2)
The GIMP is definitely one of the jewels in the open source crown, but the distance between stable realeases is a worrying factor. As with the 2.2 Kernel the 1.2 GIMP seems to have taken a very long time in deveopment.
Linus has pointed out the increased activity in bug fixing and less on features adding to current Kernel builds to reduce release time cycles. This is a very good thing. As what is the point of having excellent and reveloutionary features when the users cannot get a hold of a stable product to utilise ? The GIMP is a prime target for such a criticism.
As mentioned in the article (though a little short) 0.99 took a long time to mature. Condsidering the complexity and simply the number of features that were integrated into the product this is quite understandable. Though a cleaner and more functional interface (a common complaint from profesional users) would have been desired over some of the more esotoric features.
The feature list for 1.2 is simply mind-boggling. That a team of open source developers could achieve so much in a 0.2 realease. It shows the effective and effecient and creative nature of open source projects. Though this realease could easily be a 1.4 realease. And if so, we could have had a 1.2 realease 2 months back. Most users i know would be most happy with the ability to use atleast half of thee new feautures in a stable realease 2 months back rather then wait on for this long. Finally i must stress that i fully support the GIMP projects as it clearly shows to the world the productivity of open source and "free" software and any complaints i have made are from a satisfie user.
Re:Text Anti-aliasing (Score:1)
Re:Professional Color Matching? (Score:1)
Just a note... with the newer gimps (1.1.x) there is a "Dynatext" (or something like that) tool. It basically allows you to add text and then re-edit it later, change it's properties and what have you. This is a much better way of doing things IMHO.
Taking GIMP further (Score:3)
Although I'm not a professional photographer or the like, I still want to organize and manage my images in a professional manner. In my job as a programmer, I use RCS and directory hierarchies to organize and care for my code -- why shouldn't I treat my images with as much care?
I have needs that GIMP doesn't meet by itself. For example, I want to organize my images. Not just into folders, but according to varying criteria, such as date taken, subject, exhibit (whether an image has been used in a web site or document), etc.
Also, I want to track different versions of my images. I typically keep several versions: the raw scan, the first touch-up (after scratch removal, color correction, and other tweaks), a cropped version (because I might crop differently for different uses), and several scalings: the full original, a 640x480 web-site size, and a thumbnail. I want a tool that helps me manage all these versions, track where they've been used, and jump among them (or call them up in GIMP).
Organizing images is an area that's coming along nicely, with the development of gPhoto [gphoto.org] and Photodex [compupic.com], but these tools only address that one area of concern. And to be truly useful, they need to be well-integrated with the GIMP, so that one can edit an image with a double-click.
I have heard that Photodex will eventually have integration with the GIMP, but that appears to be some way away. Photodex also has the problem that it isn't open source, and probably won't ever be.
GPhoto shows great promise, but it appears to have some overlaps with the GIMP. For example, it has its own color correction dialog [gphoto.org]. I'd prefer to see gPhoto integrated with the GIMP for image editing, rather than trying to provide its own. GPhoto has great digital camera support so far, its greatest strength. Good digicam management is another need for a complete image management tool suite.
What about version control? No one out there seems to be thinking at all about this. Maybe because it's a wacko idea -- but I for one would find it useful.
Version control of images needn't be difficult. Of course, you couldn't do it the same way RCS does it, with content diffs. Storage requirements would get way out of hand; just saving the individual versions would require less.
A better idea, one that could be accomplished with the help of the GIMP, would be to record all the mousing, keystrokes, and dialog interaction that goes into the editing of an image; these are the "diffs". This data could be stored far more compactly than storing all the image versions. You could play back the edits on the original raw scan to produce any intermediate or final version. If it takes too long to play back from the original, you could store full binary versions of significant intermediate versions.
None of this is intended to slam the GIMP, Photodex or gPhoto. Just some ramblings on where I'd like to see image management go in the open-source world.
--JT
a little script fu / recording history (Score:1)
its just kinda procedural. not much different
than changing a line or two in a script-fu.
something that records "history" was discussed
on the list dont know how/ where that went.
(the idea was more like mayas script editor
window than photoshops history thingy)
TWAIN (Score:1)
does TWAIN plugin mean SANE is now not needed?
Re:Version control (Score:2)
My point is that a complete image-maintenance environment needs to go beyond the GIMP. It needs to integrate the GIMP, and a good organizer, and a history/version control tool, and probably several other tools that I haven't thought of yet. Trying to cram all this into the GIMP will lead to Emacs-like bloat. Instead, I'd rather try to seek a framework that allows the tools to work well together, but still enables them to work separately.
--JT
Re:MDI (Score:1)
The MDI handling is provided by . Learn how to use the windowmanager.
Personnaly I found enlightenment very suitable for my use of the GIMP, I give the gimp a whole virtual desktop, 2 screen wide.
On the left I have my working area, with all the pix I need, all the zooms, and dialogs, and on the right screen I put a 1:1 screen of the picture I'm working on. (removing the guides and selections with ctrl-shift-t and ctrl-t.
I then just constantly switch between the screens.
Another possible setup: in Enlightenment you can bring a desktop part above the current desktop, by sliding it. If you are low on space, you can put the gimp dialogs and tools' windows in another desktop, and just slide it when you need too.
cool (Score:1)
(looks like the preview window is too small to be useful, but that's fixable...)
--
Re:Kimp (Score:1)
Re:using Photoshop (Score:1)
Re:using Photoshop (Score:1)
indexing lots of images (Score:1)
Basically he's written a bunch tcl scripts to do his indexing/searching for him. The results are impressive and clean, dunno about the implementation.
-matt
Re:MDI (Score:1)
autoarrange windows within one desktop
(that is, tile in desktop #1 but not in #2)?
Can I script how it arranges things?
Does E with 10 desktops crawl (I have a K6-2 450,
with an old ATI card)?
Movie editing (Score:1)
Gimp Is cool and there's a win32 version (Score:2)
Is it that simple... (Score:2)
I for one would love to see motion video editing capabilities in a free software package. GIMP rules; might as well carry that ruling-ness into the motion video arena.
I sorta wonder whether it might be smarter to make a motion-video-only program that shares a lot of code with GIMP, sort of like how Adobe has Photoshop and whatever-their-motion-video-product-is-called.
Professional Color Matching? (Score:2)
Is it possible for someone like Corel or Red Hat to step forward with the license fees or a patent-free implementation? I've heard rumblings that this is the only major feature preventing a lot of professional graphics people switching to GIMP from Photoshop.
I'd appreciate any information/URLs as I'm not that familiar with who holds the patents and/or licenses.
using Photoshop (Score:2)
Influence of film companies (Score:1)
Where are the Gimp companies/business models? (Score:2)
If the software development world really is going to change radically towards open source development, these sorts of businesses have to start popping up.
Re:using Photoshop (Score:2)
(someone's review of some GIMP tutorial book) [slashdot.org]
"Taking over"? (Score:2)
It's not as if they're taking away from other areas, because if they weren't doing these things they likely wouldn't be contributing at all.
Again, I can't see how it's anything but a win/win situation. Free Software development is not a zero-sum game.
Berlin-- http://www.berlin-consortium.org [berlin-consortium.org]
Re:Professional Color Matching? (Score:2)
there's a link in there to a page that contains info on the applicable patents. in fact, the interviewer asks pretty much the question that youre asking.
Time to shrinkwrap GIMP. (Score:1)
Someone should shrinkwrap GIMP for Windoze and get it on the shelf. Charge about $49.95 and put it right next to Photoshop.
Re:Professional Color Matching? (Score:2)
Anyway, while it should be possible to come up with a new, unpatented color-matching system, I'd imagine there would be two problems:
- It would be very VERY costly to develop (esp. if it's to be on par with Pantone), and
- Then you have to convince almost every graphic designer in the world to switch. (Compatibility is good, but 100% is unlikely, methinks)
The solution I've heard mentioned is for someone to produce a non-free [binary?] Gimp plug-in. I think this will happen someday, once the app has matured enough to raise eyebrows among professional artists. (Still need CYMK support!)
Re:Professional Color Matching? (Score:1)
Re:Win32?? (Score:2)
Re:Influence of film companies (Score:1)
Good read (Score:1)
--
Scott Miga
Re:Influence of film companies (Score:1)
I wouldn't call that "taking over" a project by a long shot. I know others have commented on this already, but I thought I'd add a bit more. This is, IMHO, the very reason why Open Source is desired. If a graphical company wants a feature that doesn't exist in a commercial product, what are they to do? The best they could hope for was to pay the company enough the be willing to add the feature for them. Or, they can write a similar product that does what they want. However, with open source, they can add the feature they want as a lot less cost then the alternatives. Other companies who want different features can add those. All companies have the freedom to add what they need that others haven't needed yet, and everyone benefits.
This is why more and more companies will be supporting open-source projects to meet their software needs. The fact that in this case 2 studios hired to 2 lead developers is of little consequence. Good for them, I say. It's not going to stop any features from being developed that someone needs. If another company has need for a different feature, they'll hire someone too, and develop that feature.
Now I know that Linux Torvalds decided not to work for a Linux company. I praise him for that, and I think it was the best decision. But I don't think it's the decision that *everyone* has to make. Each person has to decide themselves what the best decision is.
-Brent--
Gimp user interface (Score:3)
I've seen various people say things about the Gimp's interface, like: "I don't like it", or "I'm used to Photoshop, so learning a new interface is a pain". Anyway, this idea bubbled up in my brain as I was walking home yesterday:
One of the projects in the Gnome Software Map [gnome.org] is libglade [daa.com.au], a library which allows an app to load a user interface definition from Glade [pn.org] (the GTK user interface designer) at runtime, thus enabling user interfaces to be changed and used without a recompile.
My idea was, if the Gimp's interface was designed in Glade, and loaded via libglade, surely it would be possible for people to customise it to their heart's content, and enterprising souls could design and release custom interfaces, eg Photoshop clones, for those who need a tool that "just works" and don't have time to fiddle.
(when I was coding on the Amiga [ar.com.au], I originally used an editor called CygnusEd. Then I replace it with one called GoldEd, which had an extremely customisable interface, so I could make all the menus, hotkeys, etc. the same as CygnusEd. This was fantastic, but obviously a lot of work for the programmer - surely something like libglade could allow our major applications such flexibility without demanding too much effort from the developers at all?)
What does anyone think?
Re:TWAIN (Score:1)
Re:MDI... yes! :) (Score:1)
yes you can rearrange things automatically, it supports scripting for window manipulation trough IPC messages. There's a shell, eesh which accepts command like iconify, moving, resizing, provide informations about windows and so on... you can then do your scripts in whatever languages that please you (there are examples in perl in the latest (cvs) release) (and it has an autoarrange feature)
You can also makes it remember where you place your applications windows (location, size, desktop)
I don't think more desktops will make you're window manager crawl, the question here is more about memory than cpu speed. (and I think I saw a screenshot at e.themes.org [themes.org] of a screen with 64 desktops :)
E is useable on a lot of cpu, I used it fairly well on a p100 with an old cirrus (5434) card. :)
I don't know about the MDI fonctionnalities of the windows's applications but all this sounds good to me :)
win32 gimp simply not ready (Score:1)
Re:Time to shrinkwrap GIMP. (Score:1)
That would put it in direct competition with Paint Shop Pro 6.
GIMP needs to be faster with large images (not that PSP is fast with them), and, most importantly, allow for effect/transformation layers etc.
What would be useful is something like Adamation's ImageElements [adamation.com] where you have diagramatically represented effects applied to layer objects.
John
Re:Film support (Score:1)
Multiprecision image support is useful for more than just film. Why did you support 24-bit audio in your software, if CD players are only 16 bits?
"Real" digital video, for instance, uses 10-bit sampling, not 8 bit. (I'm not even talking about high definition, either, just 4:2:2 NTSC)
And of course, s/film/print work/.
Not to mention that in scientific imaging 12 or 16 bits per channel is pretty usual. Heck, flatbed scanners do 12 bits per channel; it would be nice to be able to scan it all into the Gimp and nicely compress it into 8 bits later.
> BTW film costs about $1000 for 30 minutes of stock.
For 16mm stock that's about right including processing; 35mm is scads more. Of course if you're a broke student with the appropriate friends you can usually scavenge up short ends for a lot less than that
Re:Time to shrinkwrap GIMP. (Score:1)
--
Scott Miga
Re:Where are the Gimp companies/business models? (Score:2)
Their web site looks rather stale (over a year since the last obvious update) but they're exactly the kind of business that you're talking about.
Matthew.
Text Anti-aliasing (Score:1)
gimp needs photoshop plugin support (Score:1)
aww naw (Score:1)
Gimp on Win32 (Score:2)
What I want to see (Score:2)
--
Re:"Taking over"? (Score:1)
Re:Gimp on Win32 (Score:3)
People don't write code because The Masses(tm) need it. People write code because whatever program they (or their friends) need doesn't exist, or because the project cool and an interesting challenge, or because someone is paying them to write code, or because they are showing off, or just because they can.
It's all wonderfully banal, and it works fine.
-Mars
macgimp (Score:1)
Re:Text Anti-aliasing (Score:2)
I now use TT fonts for most of my X apps. Netscape looks much better now. Especially since I have fonts like MS Comic Sans that novice web designers love to throw in.
Color Matching info (Score:4)
There are basically two types of color matching that are relevant. The first is Pantone spot colors [pantone.com], and the second is ICC [color.org]. The latter is generally what you'd use when preparing photos and related images for CMYK offset printing. ICC is gaining ground, and is used as the color matching standard in such emerging technologies as SVG [dmoz.org].
Pantone is basically a named collection of colors. The cool thing about Pantone is that you can communicate Pantone colors to professional printers, and they know how to match it. Let's say for example that you're doing a business card, and you want your logo to be in black and a nice deep blue. By specifying Pantone 280, you can be assured that the printers will produce the same nice deep blue that you intended. Incidentally, it's not hard to find a Pantone palette for Gimp if you're skilled at Web searching.
Pantone colors are far less useful when dealing with natural images. The Pantone palette is only a few thousand colors, while the standard for scanned images is sixteen million. These are all the colors between "nice deep blue" and "slightly deeper blue than that". That's where ICC comes in.
ICC basically specifies a transformation from a source color space (say, a calibrated RGB such as sRGB [srgb.com]) to a destination color space (say, CMYK values for your particular printing press). In theory, this allows exact color matches between scanned, displayed, and printed images, but in practice things are a lot more complicated because (a) people don't perceive color the same way from an emissive display such as a CRT and reflected color from paper, and (b) not all devices can reproduce the same range of colors. Category (b) is especially tricky because the only way to ensure an exact color match is to use a lowest-common-denominator set of colors. As you can imagine, that's not a good idea. It doesn't look very good. In any case, ICC goes at least partway to solving these things.
Now we get to the patent problem. It appears that Electronics for Imaging [efi.com] has some patents [levien.com] that cover the generic idea of colorimetric matching between scan, display, and print. These patents have recently been upheld in court, so they'd appear to be pretty strong. I don't see a way around them.
As far as I know, these patents only apply in the United States. There is some very interesting development of color management code going on outside the US. Perhaps in 2003, when the most important of the EFI patents expires, this means that color management will be free for all to use.
Hope this clears things up.
Version control (Score:2)
PS: Eeek, I'm so happy my server (sven.gimp.org) survided the
Re:Movie editing (Score:1)
output, but it does mpeg and gif89. there
are a couple of other such things availble too.
freshmeat can probably help you find them.
Re:What I want to see (Score:1)
That's almost the only beef I have with The GIMP as well. I would like (as in photoshop) the tool to use the same shape as it's icon. (ie. the blur tool would be teardrop shaped when in use).
It may be that I'm just used to that, but I find it easier to work with.
does anyone know if that's in the works ?
---
used to use photoshop (Score:1)
your dealing with print, the gimp is definately
worth the time it takes to learn. i almost never
touch photoshop anymore. the gimp is just alot
more flexible in its design. mostly cause its
so easy to write plug ins for...
Re:What I want to see (Score:1)
Re:Film support (Score:1)
the way gimp16 handles memmory is also (potentially) faster when you have big images, and
enough ram to deal. being able to use the
shared memmory segment with other applications is
a nice thing too.
Re:http://www.windows200test.com/ (Score:1)
"Drestin Black 8/28/1999 12:57:54 PM
Gee - 12 days since the last time the beta TCP/IP stack crashed (and that was fixed overnight). Stable as a rock. Serving up non-stop no matter
what people try. Cant get in and can do a denial of service. Windows 2000 is more stable and robust than Linux - this is proof. "
MTBF=12 days ?
LOL that's 11% downtime a year!
over 30 crashes a year.
Gimp progress (Score:3)
The fast unsharp mask is amazing. Try sucking in a photo of some forest scene or people. Use Image -> Equalize and then use Filters -> Enhance -> Unsharp Mask. You will see detail you couldn't see when you were taking the picture!
1.2 is going to really rock. Suck it out of CVS if you want to see the latest, and/or work on the code. There's a great CVS tutorial for accessing the Gimp here:
CVS Tutorial [xach.com].
Also you can find Gimp News here [xach.com].
Also, as a shameless plug, you could find out how to write plugins in Perl from my recent Perl Journal article. You can find out more about the Perl Journal [itknowledge.com] at http://www.itknowledge.com/tpj/ It's kind of a funny article, since in it I plug my company, and I no longer work there
Another thing (Score:2)
This might be doable in script-fu....
--
Re:aww naw (Score:2)
Putting out a competing product in a comercial setting adds options for the end user, gets the word out about Gimp, and makes someone some change... Nothing is lost for the comsumer, only to the $500 mad overpriced drawing programs. And I personally have no problem with this
Re:"Taking over"? (Score:1)
Color Matching (Score:1)
Seriously though, would it be possible to integrate such code into the main source tree of would it have to stay as a patch ?
Of course the actual alorithms are quite tough in themselves, but it seems the legal problem is bigger.
Don't forget the OS/2 version! (Score:1)
Film support (Score:1)