Slashdot Mirror
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.
Please tell me they are considering using an internal LAB color model :) that's one of the key points about Photoshop that makes its images better than RGB stuff- LAB is a broader color gamut than RGB. My understanding is that Photoshop uses LAB as an intermediate stage when converting from any color model to any other (bar grayscale, or indexed).
Hi,
m l
You may be interested in a critique of the UI that I did:
http://www.snowdrift.org/computers/gimp-crit.ht
The response was not entirely hostile, but the fact remains that 'code it or go shut up' still rules. Programmers are not willing to see themselves as implementing a good idea they didn't think of, certainly not willing to implement a good idea they don't agree with.
This is why non-free software doesn't have too much to fear yet. Meanwhile I've started to join in with KImageShop in the hope I can talk them round to at least thinking hard about the UI with UI hats on and not programmer hats on.
-----
Erdas Imagine can easily pan, zoom and manipulate an image this size - yet GIMP on the same hardware (SGI O200) becomes virtually unuseable.
Imagine does this by storing several copies of the same image at different screen display resolutions in it's proprietary image format. If the same thing was done with gimp and XCF files, it would make my life a hell of a lot easier.
Nick
-- "It's a sad day for American capitalism when a man can't fly a midget on a kite over Central Park" - Jim Moran
--
Context menus are great -- if they're short. Long lists there (especially with multiple levels of submenus) really slow things down. A better way to do it would be to use the context menu for a few common features, and put the rest on a menubar. An even better way to do it (in my humble non-mac opinion) would be to make the right mouse button do something related to the tool selected (like draw in the background color?).
--
This has been around for yonks, for as long as I remember using the GIMP (pre 0.99). It's called Net-Fu. I don't know if it's being maintained anymore. It is in the directory at the GIMP site:
ftp://ftp.gimp.org/pub/gimp/net-fu/
Some sites using the GIMP/net-fu as a backend are:
http://www.onlinephotolab.com/
http://www.cooltext.com/
--
"Where, where is the town? Now, it's nothing but flowers!"
No, it's not. There are some simple algorithms to give you an close approximation, but that's not good enough for prepress work. The conversion needs to take account of the characteristics of the output device, such as the gamut, amount of ink bleed and so on. Yes, you can do it without worrying about these things, but the colours won't look as good in the final printed image.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
An extra bit of resolution could be achieved by shifting away the sign bit before truncation. (negative colors are not needed).
Better dithering algorithims are much more important to getting a good representation than throwing more bits at it. The vast majority of popular image file formats are 8-bit only, so a good converter to 8 bits is more important than handling 16 bits. A 16-bit file is likely to be run through a bad 16->8 converter, resulting in a *worse* result than if Gimp produced 16 bits.
A png-like standard that saves the exponent with reasonable compression would allow "lossless" storage.
Gimp-2.0 will be a total rewrite. This doesn't mean that we will not reuse any code from the current codebase, but we want to change the basic architecture and build the most advanced image processing system out there.
This sounds like a good plan to me. It would be really nice to be able to write scripts that run GIMP and execute efficiently. For example, if you're making images for a website, you probably want your "source" images to be in xcf (gzipped or bzipped probably), but the "published" images need to be in GIF, JPEG, or PNG. Having a script (or Makefile...) that would tell GIMP to produce the published images whenever the "source" images change would be incredibly useful. This is somewhat possible today, but GIMP has a very long startup time (so invoking it once for each image is not a good idea), plus it seems to be really unstable when running in batch mode.
Doing a "complete rewrite" will also make it easier for more developers to get involved. It's always hard to get into the code of something that's been around a while and has accumulated significant bloat. (I'm not saying that GIMP is particularly bloated, but all projects tend to "fatten" with time)
BTW, has anyone else tried to get involved in GIMP development? Whenever I went to the GIMP IRC channel to ask some GIMP development questions, people always seemed really reluctant to talk about development, and instead just wanted to talk about random subjects. Where's the place to talk about GIMP development?
Please check the reference that I gave before speculating. Non-lossy wavelet representations for editing are straightforward, and they are fast and useful. (They are also very different from having multiple layers at different resolutions, the strawman you shoot down.)
Menus that you don't have to look at are a good idea; linear menus are not the best choice--circular menus are. And people can even make selections pretty reliably in multilevel circular menus.
I'm not a graphics person or a programer but I do test and follow the mailling list of a lot of OSS software. (Wine, Kernel Notes, Hurd Etc)
I was wondering if one might be able to use photoshop plugins in the gimp if someone port like a wine wraper for certain files or even did something like what was done with xmps with the Windows DLL.
Free Unix? Free Windows. http://www.reactos.com
Pie menus! Pie menus! They need to incorporate the GTK pie menu widget into GTK and use it in GIMP! Sorry. Pie menus on the brain.
Personally, I'd like to see a set of trials and benchmarks betwen the GIMP and Photoshop. For best results, it'd be nice to see them compare on both high and low-end systems.
;)
I'd reccomend, for example:
Test suite #1: Linux System:
Redhat 6.2 default installation (no tweaks)
Window System:
Windows 98 Second Edition default installation (no tweaks)
Hardware:
Sawmill window manager (small and fast) PIII dual 650 MHZ w/ 512 MB Ram (to avoid AMD windows issues [if any]) A good Gforce2 vid card.
Test Suite #2:
Same as above but with a PII350 w/ 128 MB RAM.
True, we'd never know if it was Windows vs. Linux or Gimp vs. Photoshop, but it'd certainly be fun. I, of course, would expect the Gimp to come out on top but ya never know
Cheers,
DranoK
That is not dead which can eternal lie, and with strange eons even death may die.
Shh! Nobody knows I'm gay!
--Ben
Two pages: info and downloads. It's still sketchy on the stability side of things, but if you don't have several hundred dollars to shell out to Adobe, then it's all you've got.
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
This feature has been around in The GIMP for ages.
There is a windows port of GIMP that uses GTK+
;-)
located at: http://www.gimp.org/~tml/gimp/win32/
most of it works, except for some random crashes
- *Normality Is The Root of All Evil*
I would love to see something in gimp that lets you create vector layers. Some layers can be totally pixmap and some can be vector or even mixed? Also, a non linear history like PS would be wonderful... it might allow you to actually apply filters to vector bits but still be able to treat the object as a vector chunk. Make sense? You could then do filters on text and stuff, but still go back and edit the text content. I'm still missing the line tools as seen in photoshop, and some really cool dynamic selector tools would be great - maybe some sort of connect the dots style selector?
First I have to say that I am completely pro free software on the internet and I appreciate everything that the Gimp stands for but: I have tried many graphic programs including PSP and Photoshop as well as Gimp but there is something about gimp that is straight up awkward! I can't seem to get the feel of it. Knowing your software in very important when working with graphics.
A complete rewrite may fix these issues.
The second thing is that if I was to use Gimp there would be no reason for me not to use Linux which then causes a new issue; I don't know what it is maybe it's my settings but I can't work well with my mouse in a linux environment I think it has something to do with the refresh rate. Now why I use ImageMagick instead of gimp for web based is as simple as this.. ImageMagick gets to the point gimp on the other hand (as convenient as it may be for some people) has way to many advanced features which then makes it way more complicated than it needs to be or than I want it. Also the support for CMYK.
Movie News - "Entertainment news, bitch!"
I use Photoshop every day. It's a critical application for me, for pretty much any and all art tasks, both for fun and profit.
I pose the following as questions. Perhaps all of these are possible today in the open-source world.
In Windows and on Macs, if you leave the mouse alone, you can use the pen or puck to click. If you leave the pen or puck idle, you can move the mouse to click and drag around the filesystem quickly. You don't have to select anything to switch. (Some Windows laptops get confused between plugged mouse and touchpad, but pen tablets and mice have mastered this co-existance long ago.) You can't draw freehand with a mouse anywhere near as well as you can with a pen, and conversely, a pen is unwieldy when double-clicking small gui elements.
Pressure sensitivity is only the tip of the iceberg here, but it is a WORLD of difference over a fixed stroke. Press lightly, thin hairline. Press heavily, bold swath. All in one stroke. Modern pen tablets understand many variables and can forward them to any interested software: pressure, tilt, roll, and even a second round tip on the back of the pen for "erasing."
Not a flame. If Linux and GIMP cannot handle these (as well as the CMYK/halftoning/separation features needed by page printers), then the GIMP is sadly relegated to web banners, stock photography edits, and other simplistic work. ART needs an expressive tool set.
[
First, you might want to take him out of that box in the basement and get rid of the leather hood. I imagine the skin conditions attached to prolonged box-storage are pretty deplorable...
Don't get me wrong... Gimp is very cool. But- I't would be good if for future versions they concentrate on making it a little more l-user friendly. You know, maybe hiding away some of the advanced features unless you select a mode that gives you the world. It seems a bit overkill to do some simple tasks that I could do quickly in another application (sometimes). It's overall appearance is not bad, but it isn't great either. They should use gimp to generate some graphics to spruce up it's menu's and interface a little bit... IMNSHO.
Blender And Linux Fan
Someone needs to merge that 16 bit branch into the main source tree. 8 bits really isn't enough for, say, visual effects work - but being stuck out on a limb is a bit annoying when the main development is happening somewhere else. Please merge it back in someone!
--
-- SIGFPE
I don't think JPEG or PNG supports CMYK. I don't think you need CMYK for web graphics or game graphics.
Will I retire or break 10K?
Right click the image then click a menu and click the "dotted line" at the top of a menu you want to "stick" on screen.
Will I retire or break 10K?
Was it on1ine photo 1ab?
Will I retire or break 10K?
It's got a very steep learning curve, but that is no different than Photoshop. Most of what you don't know (well, what I didn't know) was what operations I wanted to apply, in other words: what I wanted to achieve in the first place. It is hard to wrap my mind around graphics design.
I would also expect that setting up a course in using the GIMP would be difficult because of this. Then again, I'm no course designer, so...
Bert Driehuis -- All I asked was a friggin' rotatin' chair. Throw me a bone here, people.
I look forward to the day when schools start offering Gimp classes instead of Photoshop classes.
it's green.
Implement photoshop plug-in compatibility and suddenly GIMP would have ten times as many features availible, from freeware on the net to extremely polished professional printshop stuff.
Don't implement photoshop plug-ins and people who have invested in them (be it money or learning-curve time) will not move to GIMP, and GIMP development will be slowed as people waste their time re-inventing wheels that are freely availible as plug-ins, leaving less time to improve the fundamentals.
It's so rare to get a useful and functioning plug-in standards for graphics. Use it, whatever the difficulty.
--
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 )
--= Isn't it surprising how badly I spell ?
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.
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
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.
...but geez, that icon is scary. I was ok until I saw the eyes move. I actually jumped. Does it have to be animated?
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.
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.
I'd rather have someone respond than be modded up.
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.
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! )
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.
Shine on, you crazy diamond.