Slashdot Mirror
The Future Of The GIMP
LinuxNews Team writes: "Sven Neumann and Michael Natterer prepared an RFC about GIMP. We learn that
there will be three branches in CVS: 1.2.x branch (stable GIMP), 1.3.x ( devel GIMP but
not many new features) and 1.9.x (VERY devel GIMP with whole new structure, GEGL and
GCim stuff). Looks like GIMP 1.2.0 is on its way to the users.
Check out the RFC."
REAL color graphics professionals use a paintbrush and a real palette.
The Cure of the ills of Democracy is more Democracy.
Erlang Developer and podcaster
Dude, they have the gimp for windows. Use that.
-I just work here... how am I supposed to know?
Good question if SlashDot is showing a bias. If MicroSoft happened to do some deal with another company and that other company did something illegal that only benefited that company (ie it did not help MicroSoft) would that story get posted here?
A while ago the KDE people ported the GIMP to Qt, calling it KIMP. Because of the GPL not allowing linking with non-GPLed libraries, they were unable to distribute it. But now that Qt is GPLed, they could do so. I wonder if KDE is still interested in having a KDE-ized version of the GIMP?
-- Ed Avis ed@membled.com
a port to the mac?!!! gimp is killer on win32 - give adobe something to _really_ worry about.....
As for the program itself, it's quite an improvement over the 1.0 series. The user interface is a little more consistent, and there's now a menu button in the top left of image windows, in case you don't like the RISC OS-like context menu. It's a lot quicker and easier to change things like the brush and fill pattern, and the new drawing tools are pretty handy. It seems to have a lot greater support for graphics tablets, something I haven't been able to test since I don't have a graphics tablet...
Anyway, it's well worth a download, and is a great set of improvements to an already great program.
Oh, and here's that Half-Life stuff. :-)
Ford Prefect
Tedious Bloggy Stuff - hooray?
What used to be a simple layer stack in GIMP 1.x, which is combined using layer modes (Normal, Combine, Difference, ...) will, with the help of GEGL, become a rendering pipeline which can be thought of as a tree of layers which is viewed from its root. The nodes of the tree are operators with an arbitrary number of inputs and outputs. These inputs and outputs access rectangular regions of pixel-data, the edges of the tree. Each edge (comparable to the layers we have now) can hold its data internally as pixels, vectors, text or whatever and only needs to provide a well-defined interface so it can be plugged into the rendering pipeline. A similar approach will be used for the operators: Simple functions like color corrections or blur filters as well as affine transformations and more complex effects are possible.
So, the rendering pipeline becomes much harder to explain in simple terms. This new model, however, yields great flexibility and power. You can have an image that contains both pixel-based portions and vector scalable portions. These objects can then be modified at any time. So, unlike current GIMP, text could be added and then later changed. This is truly useful for speeding up many uses that people have for the GIMP, but it also makes for more new uses.
--neutrino
History has the relation to truth that theology has to religion-i.e. none to speak of. - Lazarus Long
They haven't patented color. They've patented a very specific system of color definitions. You can use any color in the world you'd like without their permission or okay. But if you go to your local printer and leaf through their color swatch book and say "i'd like this plate to be this exact color", then you're generally using Pantone colors.
:-)
You generally only ever see pantone colors on print jobs of 1, 2 or 3 colors, because most of the specturm of colors can be recreated using 4 colors.
They fill a niche. I hope i explained it adequately... Maybe their website will offer a clearer explanation for you...
I don't mean to bag on the GIMP. It's cool, but:
Photoshop pros:
1) I have spent years learning Photoshop. Whatever I need to do to an image, I can do it in Photoshop really, really quickly.
When I use GIMP, I get frustrated alot "Damn it! In Photoshop I could just do x - y - z and I'd be done by now!"
This, I guess, is a problem any new software must overcome when it enters a marketplace already dominated by one program.
2) Photoshop has really nice text editing features, including being able to edit any text entered at any time.
3) Photoshop's history feature has become indispensible for me.
GIMP pros:
1) Free
2) Easy to write your own "plug ins"
3) runs on linux
Photoshop (and Diablo II) are pretty much the only reasons I ever use Windows at all. If there was a port of Photoshop for Linux, I would buy it in a heartbeat (even at $500+)
This begs the question: Can a free software program of this complexity ever hope to overtake the proprietary "Industry Standard" ?
IMHO, we can hope. GIMP is only at 1.2, and has been around a few scant years. Photoshop has been around 'forever' (any timespan over 5-8 years is forever in computer time) and is at 5.5 (going on 6?)
Given the pace of software advances in popular open spource projects, there is definitly hope that GIMP can overtake Photoshop at some point.
My office mate often touts GIMP. He (and myself) can be described as Linux zealots. But, when it really comes down to it, I use the best tool for the job. And often, that is Photoshop. (just as, often, the best tool is Linux)
I wish GIMP good luck, and I DO use it regularly, when it's a quick change and I don't want to re-boot to windows. I look forward to the day when I don't have to re-boot at all.
-geekd
> Or maybe GTK+ is already a distinct rpoduct from GNOME, thus we have no problem...
It always has been. "GTK" was the toolkit the GNOME developers came up with for GNOME. When it was broken out to become an independent toolkit, it became "GTK+".
GTK+ is "under heavy redesign", but that has nothing to do with The GIMP. They are simply upgrading it to support bi-directional text and lots of other goodies you expect in a modern GUI tookit.
GNOME is based on GTK+, but they aren't getting blindsided by any changes to GTK+ driven by The GIMP. You fear a chain of causality where there is none.
--
Sheesh, evil *and* a jerk. -- Jade
Does anyone know when The GIMP will support CYMK? This is the thing holding me back from replacing Photoshop 6.0 and my whole windows partition.
Fawking Trolls!
"Going to war without France is like going deer hunting without your accordion." - Jed Babbin
We use Gimp at work for our advertising work in magazines in the UK.
The lack of CMYK is a bit of a pain, but then again, I wouldn't have much of a clue about it anyway!
That means we work with 600dpi A4 images within the Gimp. We load them using the postscript filters provided by Ghostscript, which is the only program in the known universe that can load Postscript generated by Microsoft Publisher. We know for a fact that Quark can't.
We do this on a laptop running Mandrake 7.1. With 64 Megs of RAM, 2 Gig of partition and a 266MHz PII processor. (HP Omnibook 4100). We also use Gimp for Windows for photo work for the adverts (version 1.1.28 I think for the latest ads) which is generally very stable. It has bugs, but not having to pay £500 for Photoshop, plus the time required to learn it is significant for an internet company.
Yep, we don't use the best tools (Publisher is really bad, but we have it and it can be made to do most things). When a really good DTP program for Unix comes out that works, provides all the functionality (or a subset of) Quark and Publisher, then we will be migrating to that.
Anyway, UK readers might have seen the adverts for our company in magazines like Practical Internet, Surfed, MacUser (once, and once only), EWEB, Internet Money, Essential Internet and a few more. Oh, the company - we register domain names at firevision.co.uk. Expanding soon to even more services... [end mini-ad]. We don't think that the lack of CYMK support has affected the outcome that much at all - but we aren't laying out an entire magazine where things like this become a lot more important.
Maybe I should write an article on real business use of the Gimp...
Obviously you don't actually use the Gimp, because Gimp *can* write GIF images, it just can't use LZW compression in them.
AFAIK, Unisys hasn't patented GIFs, just the LZW compression system that is used in most GIFs. Gimp writes GIF fine, except since it doesn't use LZW, Gimp's GIFs are usually a fair bit larger than GIFs from Photoshop etc.
Sadly enough I can see this being possible, given sufficiently powerful edge-detection routines (clothing region detection, sub-clothing body feature determination for nipple and breast shapes etc.). *shakes head* If you want celebrity fake nudes though, why not just look for them on all the bajillions of sites devoted to that? Of course, what with NutScrape being the pig that it is, you'll expend the same amount of cpu cycles either way[1]. Or just become a millionaire and offer the object of your desire a few hundred thousand dollars for a weekend o' carnal fun. "The only difference between an actor and a whore is that the actor sells their mind too." ~ some person whose name I'm forgetting
[1] which naturally is going to lead some troll to propose building a beowulf cluster of 386s to use hot_grits.fu to render a naked N. Portman. Groan. Why do I think of these things?
--
News for Geeks in Austin, TX
Very much of the Free codebase seems to be coming into a "final rethink" state, after having left a "better attempt" state -- and before that was, of course, the "initial (serious) attempt" state. It is like the good old saying that software is expected to become useful at its 3.0 release.
., and because most of these projects begin with 0 instead of 1 (which is often nothing but a honest thing to do), I happen to believe that, even though the version numbers are still smaller, lots of code reaches a "symbolic 3.0 release". Still with me? OK! :-)
;-) So if there is anything of truth in this story, my comment is that it seems a useless and confusing move, don't do it... :-)
Now, because Free software often uses release versions in the sense of
A few examples:
Linux kernel: the Linux kernel has a history of major rewrites, but still a smaller history of API changes. One might argue that it had its "initial (serious" attempt" around 2.0, a first rethink around 2.2, and now yet another major rethink for 2.4, with Linus saying that they have now learned enough from the past to make the kernel structure workable, so it should be considered a "final rethink".
GNOME: 1.0/ 1.2 "initial (serious) attempt", 1.4 "better attempt" and 2.0 "final rethink" (yes, I _do_ realize that 1.4 as well as 2.0 are future music for now, but there's good thoughts being done about this already.
GTK+ follows about the same course, only it is a little bit further (has already got 2.0 alpha code). There is a good API rethink being done in 2.0.
And now the GIMP. I applaud all this work, because I realize how much courage it takes to make these radical steps, and how _good_ it is that this work is being done. A lot of open source projects have a tendency to become lazy bloatware by a lack of strong leadership (and competition...). Take for example the comments concerning XFree86 that are on the rise again. (Note: this is not to even _suggest_ that the XFree86 team doesn't do a good job. I believe it could have been done better, but that it requires very special leadership skills to take the right decisions in such matters.)
So, I wish you a lot of luck with the re-thinking!
(P.S.: I heard rumours about GIMP 2.0 to have a cross-platform GUI library thingy. After reading this I don't believe much about it at all anymore. Anyway, I think it would be an odd move for the GIMP to move away from the GIMP toolkit!
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Just start tracking the 1.1.x development series. I've been using the 1.1.2x series for a while now, and they've been exceedingly stable for me. I haven't tried 1.1.30 yet, but I'd imagine it works wonderfully. Of course, this requires a bit of work, too (compiling! Oh no! ;), but it's well worth it.
Translation: When is Adobe going to come out with Photoshop 6.0? We've run out of features to copy (CMYK support is too hard and it's not like Linux users need it to paste penguins on pictures of lingerie models) and the Open Source Movement certainly isn't coming up with any on its own.
So, when are we getting a story on the SEC investigation of the VA Systems IPO?
if you want pics of nude men, considering that about 230,000 men are users here. We can all take nude pics of ourselves and post them somewhere, maybe even a Men of Slashdot calender to raise money for Athlon's, or the kids or something.
I've been playing around with the design of a terrain engine. For those who don't know the basics of heightmap engines, the obvious thing to do is to have a grid of vertices. The height of the vertices is defined by a bitmap image, where each pixel's grayscale intensity represents the height of the vertex.
The result is that a grayscale image can be created in The Gimp, and the output sent to my (and many other) terrain engines after saving a file. This is an unsatisfactory amount of feedback.
I'd been doing some thinking about making a real terrain editor when it struck me that I would probably be recreating most of the tools and filters in The Gimp, but at a decidedly lower quality. I then realised that what I wanted to do is the opposite of plugins, additional filters, Perl-Fu and Script-Fu: I wanted to throw out the buffer where all the filters and tools are rendered to, and replace THAT with a plugin to the other end of The Gimp.
I am interested in replacing the framebuffer in The Gimp with a AF_UNIX socket which transmits the framebuffer data over to another app, which would be in this case, my terrain. I would be able to paint modifications onto my terrain with all of The Gimp's tools.
I'm pretty busy with my website these days, as we just went live, but I'm definately interested in looking into the code for The Gimp soon enough to see if this is feasible.
Does this tree-based rendering thingy mean that it would be possible to implement a tree of layers, instaed as it is now a stack of layers, that is, that layers could be grouped into "meta-layers", to which the same things (like opacioty, mode, colour balance, etc) could be applied as to real layers? I have missed this feature in gimp.
Perheaps it would allready be possible to implement (just a bit messy?). I don't know. I am a developer, but I have never looked at the gimp sources...
--The knowledge that you are an idiot, is what distinguishes you from one.
Where you can take an image of a foxy female, and then have the script-fu trace her clothing, remove them and replace them with the appropriate flesh tones.
You'd have to allow customization though, for nipple and aurolae size and color, as well as pubic hair color, shaping and or lack of.
Once this gets done, though, I then need many screencaps of a certain George Lucas movie.
Can you elucidate on this "whole new structure"? Or is not enough about it known yet? Taking a look at the information at
http://plugins.gimp.org/gimp2/doc_components.html it says:
libgimpwidgets: core-independent widgets used e.g. to build libui widgets (similar to gimp 1.x's libgimpui)
but I really cannot stand it when graphics programs change drastically and add "functionality" (on the level of the user interface) that replaces other things that I'm used to. For instance, I really liked PSP3. I really did. (OLD, old stuff we're talking about here.) But I coulddn't stand PSP4.
I'm reasonably sure the GIMP guys are smart enough not to change things around too drastically, but it's a concern of mine, since I really enjoy working with and playing with The GIMP as it is. I don't want to have to update to a newer form that I really don't like to get the latest neat things.
Just a concern of mine.
Angry IT woman in big clompy boots. And talking lint!.
Ok, let's say you're developing an OS. You have a clear mandate for what an OS does based on decades of examples.
On the other hand, if you're developing a photo-manipulation program, you don't have so clear a map. Once you've "done Photoshop", what else should photo-manipulation be? How does that apply to the extant (and future) UNIX(-like) desktops? How important is performance? How important is non-interactive use? How important is any new feature?
Here's where I think the GIMP should go in the next 2-3 years, but others will disagree....
- The UI and the photo-editing parts should be separated from eachother. The editing engine should be a library with a well-defined API between it and the UI so that others can slap a GNOME UI on it or a KDE UI or another Gtk+-only UI which uses a single window, etc.
- All plugins should be re-catagorized and many re-written to fit smoothly into the new catagories. Perl, C, Scheme... it should not matter to the user.
- Non-interactive use needs an overhaul. One of the most powerful features of the GIMP is being able to script your interaction with it, but most of what people want to do with this will require a single, stateful GIMP that can accept lots of requests at once (call it World Wide GIMP, if you will). This is not really what GIMP was designed for, so most people settle for using a library-based interaction with ImageMagick.
I know that this list of wants is 180 degrees off of what a lot of people want, but that's sort of my point. It's really hard to figure out what community to serve in the Open Source world....I wish the folks at GIMP the best. If I ever have any more spare time, I'll go back to helping them out.