What's Ahead For The GIMP?

Ur@eus writes "Hi, We have just interviewed Sven Neuman, lead developer on the Gimp. The interview covers the upcoming 1.2, 1.3 and 2.0 releases of the Gimp and how [they]will evolve further. You will find the interview here" Improved path support, GIMP/GNOME interaction and an improved rendering system are a few of the points that Sven addresses -- The GIMP has impressed for years and keeps getting better.

Comments

UI (menu structure)

[mattdm]

I don't mind the multiple windows so much, but the multi-level context menus drive me crazy. With photoshop, commonly used functions are in the same place every time -- I don't need to look, because my hand knows where to click. That doesn't work with the Gimp's UI.

--

KDE integration.

[Forge]

That's right. After that silliness with "Kimp" The KDE people hacked up an image manipulation tool of their own. It's called kImageShope and it integrates well with KDE and Koffice with that embedding and stuff. Needless to say it looks more like Photoshpe than it dose like the Gimp.

The really cool thing about it is that it will work with Gimp plugins without them being modified in any way. For those new to image manipulation on Linux most of the Gimp's power is in those awesome plugins.

So yes. For all practical purposes the Gimp will soon have KDE integration with all the power that implies ( click image in KWord and edit it in place. yada yada )

Wavelet/Multiresolution Drawing Support

[jetson123]

With ever increasing image resolutions, I think the GIMP needs wavelet or multiresolution drawing support.

That is, images are represented at multiple resolutions. When you edit it at low resolution (zoomed out), only the low resolution representation needs to be modified. When you zoom in and edit details, only a small part of the high resolution representation needs to be modified. Global color adjustements and many kinds of other global image processing operations can also be done very fast.

This kind of representation would allow the GIMP to work fast for nearly arbitrarily large images and arbitrarily fine detail, since processing speed is determined by the part of the image that is actually displayed and being modified. It is also a good match to the upcoming JPEG2000 standard.

But this kind of support needs to be built in from the ground up, since filters and tools need to be coded differently.

A good introduction to the subject is the book "Wavelets for Computer Graphics" by Stollnitz, DeRose, and Salesin.

When will Gimp quit being a gimp?

[Rader]

I've used Photoshop for years. The newspaper my parents own bought it many many years ago, and thus I've had my "free" copy to use since then. I continue to buy the latest upgrade for them, to get the key features we need.

However, this last "upgrade" was only 5.5 from 5.0 and had nothing new to offer (at least for us) In fact, the only really new thing to offer was another product they're "Kind-of" integrating, and won't actually be fully integrated till 6.0

With the recent story Slashdot ran about the Insider Mac web site running "secret" information about the new 6.0 release, there were a LOT of posts saying that 6.0 wouldn't have many new features either. Even saying that the only reason Adobe was so upset about the leak was that people would find out how featureless (and waste of money) the next release would be.

And with Adobe's marketing buzzwords like "Best Release Ever".... wait... I'm sorry. I just can't be as corny as them, so I won't list any more. --But they were good!!!!

So with Adobe running out of steam for interesting ideas... When will GIMP catch up? Can Gimp catch up? How many people are working on this thing. Is it just the original creator??? Will they have to hire a larger team when they hit the "releasable" 2.0?

I hear a lot of people saying the Photoshop will rule because of CMYK. However, I hear more and more people saying that the RGB is all they need. And it's true, if all you need is WEB-output!! And obviously web graphics are important now compared to the 80's when there was no such thing.

One last thing to point out. I'm amazed at what these graphic tools can do. But what is more amazing is that it takes 15,000 apes at Microsoft to release maggot feces (read: buggy shit), but yet it only takes Adobe an extremely small workforce. Adobe is practically at the TOP of the "Net-Income-Per-Number-Of-Employees" list.

So... If Adobe can push this kind of software with their "small" gropu, I'm sure Gimp can too. I can tell you what... that Adobe will never make a Linux version! If they had their way, it'd be MAC only. It still comes out Mac-platform first. (Not as bad as it used to be, though)

Rader

Re:A Sad Gimp Story

[BigSven]

Anyway, I sure would like to see multibyte support in the Gimp someday.

GIMP FreeType, our freetype plug-in is on its best way to support multibyte fonts.

I know this isn't exactly on topic...

[MaximumBob]

...but geez, that icon is scary. I was ok until I saw the eyes move. I actually jumped. Does it have to be animated?

Re:How to Fix the GIMP User Interface

[-Harlequin-]

>This is how to fix the UI for the GIMP.

Yep, that would go a long way towards fixing it. However we are up against something bigger here. As an artist (specialising in computer work) it is becoming painfully obvious that the entire open source movement is still largely "by techies, for techies". And as long as this remains the case, any software that requires expertise outside that narrow range (such as graphics apps, games, 3d animation, possibly even word processing) is crippled by the nature of the open source movement.

A while back, I had the time to contribute to the movement. I couldn't find any projects that were looking for such help. Perhaps this was because you had to be a techie to know where to look to find such a project, or perhaps it was because many techies simply don't realise how crucial the non-programming parts are if you're trying to make a fully functional product that can compare to normal commercial software.

Hell, remember when /. reported that id Software had fired one of their developers, Paul Steed, allegely out of spite? I saw _multiple_ replies stating "Uh - Paul Steed isn't a developer, he does 3d models and art". What?!?
If this thinking is symptomatic of a significant portion of linux developers, linux ain't going anywhere beyond servers and enthusiest machines anytime soon. Windows shall forever reign supreme.

Programming is only one part of good software, and now that everyone is an artist (because they can operate GIMP or PS), everyone is a designer (because they can write html), everyone is a UI developer (because they can write code), we're going to have to deal with the fact that these beliefs are simply false. Flawless html doesn't make flawless design, flawless programming doesn't make a useful UI, flawless pixel manupulation doesn't ensure flawless communication of a concept. These are different skills, and the sooner this is widely understood and accomodated, the sooner open source becomes a genuine alternative.

GIMP v. Photoshop

[cvd6262]

Other people have pointed out that as good as GIMP gets, it's not Photoshop. The good thing about Photoshop is that you don't have to be a comp.sci major to use it, but the great thing about photoshop is that if you understand how it works, you can do some amazing things. GIMP just isn't there yet.

CMYK support would be a big thing. Asides from it's print advantages (most printing is not done RGB), CMYK allows for some effective touch up. Took the pictures in a photosensitive area of a clean room (you know, the yellow light)? Convert the image to CMYK, chuck the yellow, adjust the cyan and, poof! No more yellow. The image looks normal.

However many features you give and/or take with GIMP, the reason I still will use Photoshop is just how it feels. It's sad, but GIMP may never get to that point due to the platform it's being developed on. I started using Photoshop seven years ago, and I use GIMP to play around on my Linux box, but I just don't see the two converging. Maybe that's a good thing.

How to Fix the GIMP User Interface

[LionKimbro]

I am disheartened to read that attention is not being paid to the GIMP UI.

The GIMP has 1st class, state of the art capabilities, but it's user interface is terrible.

Believe me; I Love the GIMP, but I just had my first fight ever with my girlfriend of 3-months; it started when she said, "I don't ever use the GIMP; I will only use Corel Photoworks (or whatever it was). The $500 I paid for it was worth every penny." After sitting down with my girlfriend for about an hour with the GIMP, I had to agree that the UI was bad.

Unfortunately, I cannot "just go into the GIMP source code and fix it", the problem is larger than one lone volunteer can solve.

The UI is a traditional Achilles Heel of Free and Open Source Software. Fortunately, there is a traditional solution to the problem as well, namely embedded scripting languages and extensive customizability.

The GIMP will take off when the UI is fully customizable; Making the UI maximally customizable should become the GIMPs next great goal.

1. Artists are craftsmen and want to be able to get their tools just right. They want their particular brush, their particular colours, their particular keystrokes, their particular default layout, just right. I don't know how many times I have heard artists say, "I wish it was just organized like this," or, "Why did they put that there?"
2. A subset of artists will have coding abilities, and the time to work with the GIMP. After the programmers have made it easy for the artists to easily customize things, the artists will be able to customize the work environment to be usable.
3. The artists will customize the GIMP in many ways and upload their customizations to themes.org. The good customizations will float to the top, the bad ones will sink to the bottom. Great customizations will be included with the GIMP.

This is how to fix the UI for the GIMP.

This is how ALL OpenSource UIs have been fixed- By giving the users an easy way to customize their environment.

Okay, that's enough for now... =^_^= . o O ( Phew! )

A Sad Gimp Story

[Kismet]

I recently started to work at a large International Software development firm. Our client was developing a business-to-business procurement solution that was to be global in every aspect. The program would be web-enabled.

Development was to be Microsoft-centric. Coming from a strong Unix background, I decided to use whatever familiar Unix tools I could to get the job done in record time. Central to my strategy was Perl-Fu for Gimp. I would use it to automate the localization of the images in the product.

It worked fabulously until Korean came along. I abruptly learned that the Gimp is incapable of rendering multibyte fonts. I suppose I should have checked that feature before I started, but the point is that I ended up having the company buy a copy of Macromedia Fireworks and scripting the enxtensions in JavaScript on Microsoft. What a pity.

Anyway, I sure would like to see multibyte support in the Gimp someday.

CMYK Color

[linuxonceleron]

To keep people from saying "Photoshop rules until GIMP has good press-ready CMYK" I think that the GIMP should be able to do CMYK color conversions. Also is there any way to interface the GIMP's plugins/script-fu to a web server to use as CGIs? On the fly generated images would be mucho cool.

Re:CMYK Color

[Pinball Wizard]

a couple of the other replies mentioned net-fu.

There is a great book you should pick up, Programming Web Graphics with Perl and GNU software, from O'reilly. This goes into detail about scripting the Gimp with Perl. You also learn about ImageMagick and other image scripting utilities.