GIMP's Next-generation Imaging Core Demonstrated 482
brendan0powers writes "GIMP developer Øvind Kolås gave a public demonstration of the Generic Graphical Library (GEGL) on Friday at the Piksel 06 festival in Bergen, Norway. GEGL has long been slated to replace the core image processing framework of the GIMP, bringing with it entirely new data models and operations — but development had languished to the point where many critics had written the project off entirely." Linux.com and Slashdot are both part of OSTG.
Krita (Score:5, Insightful)
Maybe now the UI (Score:1, Insightful)
Re:The difference between The Gimp and Excel.. (Score:3, Insightful)
GIMP needs fresh developers (Score:5, Insightful)
I see this as a confirmation of the stagnant GIMP developer pool, led by a few who are not interested in growing that community at all.
If the GIMP team would foster new blood, help new hackers learn the large and intimidatingly complex codebase, give any other reply besides a gruff "you want it, you code it" response to any artist who dreams of a good core feature, give specific progress feedback about modern image demands like 32bits-per-channel, CMYK, or fully functional ICC, then maybe we'd see a real alternative to Photoshop in the OSS world, not a Photoshop 1993 clone.
The only other path is "fork it," but with any complex project, it's very tough to fork away from the few experts.
It's clear the GIMP captains still see GIMP as a pet project, just as some major tech news sites see themselves as a pet blog, and refuse to take on the responsibility of being a leader or even trying to become a leader.
Re:Maybe now the UI (Score:5, Insightful)
Maybe now he can give The Gimp a decent UI instead of the trash it's had for the last 10 years
In the first place, the GIMP's UI has changed a great deal in the last few years, so much so that it doesn't make much sense to call it one UI. Second, the GIMP's current UI is very powerful and very usable. Personally, I prefer it to Photoshop's UI, mainly for the ease with which it can be customized to fit exactly the thing I need to do right now. Then, later, when I'm doing something different, I can flip a couple of hotkey assignments, tear off a different menu or two, and have a UI that is perfectly suited to what I need at that moment. For those who know it well, the GIMP's UI rocks. Much like PS, actually. The biggest difference is that there are a lot more people who know Photoshop's UI well.
Re:It's about time (Score:2, Insightful)
But the main problem with adoption is the name. Nobody who has seen "Pulp Fiction" (an american film) can take the GIMP entirely seriously. A simple name change would massively increase adoption in pro circles, if you ask me. Yes, arty people are that picky.
Re:The difference between The Gimp and Excel.. (Score:5, Insightful)
Ever tried to do basic drawing in The Gimp? Like, say, drawing a circle?
First, there's a much easier way to draw a circle than the one you linked to. To draw a circle: use the ellipse select tool, holding down the shift key, then use Edit->Stroke Selection. Done. You can adjust the width, color, pattern, etc. of the circle on the Stroke Selection tool that pops up.
Second, if even that seems like too much effort, well, I'm with the developers on this one: The GIMP is a photo manipulation tool, not a drawing tool. As a fairly heavy GIMP user, I don't want the interface cluttered up with additional drawing-related tools, not when (a) there's a perfectly good, if non-obvious, way to accomplish the task and (b) it's not the tool's primary job.
That's how software should be made, with a focus on what the user wants out of the software.
Which user? You can't be everything to everyone. In this case, people editing photos very rarely have any need for drawing circles, and it's a bad idea to clutter the UI up with stuff that they aren't going to use much anyway.
Re:The difference between The Gimp and Excel.. (Score:5, Insightful)
That's the sort of answer that, if used frequently, could kill OSS. If the aim is to replace commercial software with 'free' software, then the 'customer is always right' motto still applies.
Re:Gimpshop! (Score:3, Insightful)
Yes, it is forked up (Score:3, Insightful)
Re:It's about time (Score:2, Insightful)
Uhhh... do you also think Photoshop should be rewritten from the ground up to use QT so it can run on Linux and BSD?
Re:The difference between The Gimp and Excel.. (Score:5, Insightful)
Re:The difference between The Gimp and Excel.. (Score:5, Insightful)
Oh, for the Good Old Days... (Score:3, Insightful)
Schwab
Re:The difference between The Gimp and Excel.. (Score:3, Insightful)
Re:The difference between The Gimp and Excel.. (Score:2, Insightful)
The primary motivation in having a huge, over-reaching featureset in a proprietary application seems to be to justify the (usually) ungodly charge for the end user license. This doesn't work so great, however, because it means the developers have to create said feature and try to integrate it into the package. This means their employers either have to compensate them accordingly so that the extra features work really well, or be satisfied that the feature is there enough to list in on the box or in marketing materials; as such, the price either goes up or the company allows itself to take a loss in not charging extra or shipping a product with sub-par features. In any event it's a real bitch to integrate limited functionality for a particular task that goes beyond the scope of the application without it seeming half-assed, incomplete, or confusing the real purpose of the application. This is why you see people doing things like using Photoshop for page layout or Excel in lieu of a database; the results speak for themselves.
This whole Swiss Army Knife approach for *complex applications* needs to be nipped in the bud, and that's in both proprietary and free solutions. Anything less is accepting the approach simply because of precedent and ignoring evidence to the contrary.
Re:Maybe now the UI (Score:3, Insightful)
Re:The difference between The Gimp and Excel.. (Score:3, Insightful)
It's a difference in philosophy.
The philosophy you describe is the "bloatware" philosophy, where a single tool (program) tries to do everything. What happens is the program starts off not being able to do anything, it then grows to do something well. As circle drawing and shopping list features are added it grows to become unwieldy. Eventually it becomes unmaintainable and falls into decay, at which point someone starts a new project to write a "simpler tool". This bloats and the cycle repeats again forever. It's ideal if your aim as a developer or company is is to keep yourself in a job and make money for life.
The Unix approach is that one tool does a single job and does it well. For example: tar bundles mutiple files into one, compress makes files smaller and gimp does photo editing. Indeed under the Unix philosophy, gimp should really be seen as a graphical user interface wrapped around a bunch of other tools. One tool might do thresholding, another might do convolutional filtering and so on. The idea with the "one tool one job" philosophy is that each tool gets written once and is simple to maintain and upgrade. Whenever that job needs to be done a program calls the relevant tool rather than trying to do a mediocre job itself.
The unix approach is IMO the better. It leads to less needlessly replicated effort and gives higher quality results. Modularisation is one of the fundamental tools of computer science, used to reduce complexity to the point where a persoan can handle it.
Asking gimp to draw pictures is a bit like asking a plumber to paint your house and expecting a first class job of it. It's just not gimp's job to be a drawing package. If you want a drawing/photoediting tool maybe the right way is to write a new supertool, which does its work by calling gimp and inkscape, rather than trying to make gimp and inkscape do each other's job? You as the customer gets what you what, and gimp continues to do its job well.
Note: The customer might be allowed to demand a result, but I contend that the customer has no right to dictate the method of arriving at the result. That is for the experts. For example, if the customer wants a drawing and photoediting program the customer has no right to demand that the solution be provided by modifying gimp to do the job.
Re:It's about time (Score:2, Insightful)
Yes you're right... Let's see, an new name... A descriptive name maybe... "Image Manipulation"? Yeah, that's good. And it's software, so obviously "Program". We really should highlight that it's open source, so we'll stick a "GNU" infront of it (as you are want to do with GPL licensed software). That's it! The "GNU Image Manipulation Program"! I love it!
Seriously though, it's not the name, dude. I mean, do you think people aren't using Linux because it has a strange name? Open source tools aren't used because there are some suspicions of it and a large part because of inertia. The vast majority of office-workers use MS Office so OOo won't get adopted by many, the vast majority of graphics people use Photosho so GIMP won't get adopted by many, and the vast majority of desktop users use Windows so Linux won't be adopted by many. It's as simple as that
The one field where open-source is vastly superior, even to the desktop user, is browsers. And even in that field it's going slow as hell, Firefox is still only at 15% or so. Inertia is a powerful force.
GTK+ is the problem. (Score:1, Insightful)
Yes, there are many higher-level language bindings to GTK+. But most of them retain the C pseduo-OO model, even when a mapping to more abstract language features would be appropriate. This is often done due to time constraints. For those few bindings that do manage to make use of such features, as in the case of gtkmm, we end up with poor runtime performance and excessive memory consumption.
GIMP badly needs to be reimplemented in a much higher-level language. But languages like Perl, Python, Ruby, C# and Java won't suffice. It's likely that they would have to resort to a high-performance, compiled, functional language such as Standard ML or OCaml in order to produce a product capable of competing with the best commercial offerings. A functional language should be used to allow for conceptual clarity and automated memory management, while native-code compilers are employed to make effective use of the CPU.
The whole of GTK+ would also need to be reimplemented directly in a language like OCaml or Standard ML. But it would be done in a way that most effectively uses the features of the chosen language. OCaml makes for a good choice, as it offers object-oriented capabilities and true inheritance, features which are currently emulated (poorly) in the C implementation of GTK+.
The second best option would likely be to use Objective-C. As Apple has shown, it proves to be a high-performance language suitable for building extremely complex and powerful GUIs. A reimplementation of GTK+ in Objective-C, taking full advantage of Objective-C's features, may help them get past the current stumbling block of insufficient abstraction.
Re:GIMP needs fresh developers (Score:3, Insightful)
Re:It's about time (Score:5, Insightful)
Linux is a vastly superior name than GIMP. The word GIMP could easily offend some. Linux is a made up word. I've installed GIMP on many a windows users machine as a free image editor, and depending on who it is I feel uncomfortable calling it by name. Sure, it's probably not the biggest reason for the lack of popularity, but I don't think it's insignificant. libcaca is another one. Cool library, but seriously, libcaca? And the Do Whatever the Fuck You Want License? The name has honestly made me less interested in the library, as lame and irrational as that is. I don't paint my walls dissonant colors; I don't want my apps with unsightly names.
Re:It's about time (Score:3, Insightful)
Graphic professional are color matching paranoid. A problem between a color of a design and the output from the output company cost lots of money and finding what is wrong in the flow requires the same sort of approach as finding a bug in an application.
What is also missing is maybe that Adobe build its tools closely with their professional customers while Gimp looks like developed by developer for enthousiast/developer. I just imagine that the situation would be the same if some graphic professional created a uber-powerful new programming language for other graphic pro, with a completely different syntax that also just happen to miss only one essential feature for pro developers (can't think of one good example but let's take 'no debugger' or 'no string manipulation function'): whatever the intrinsic merit of the product, it would have more difficulties to take off in dev circles.
Re:It's about time (Score:3, Insightful)
Think about it. This guy will whine non stop at the developers. He will yell and scream at people for not helping him enough. He will fill the IRC channels with vitriol and he will not lift a finger to help anybody, will not file a bug report, will not write one line code, will not write one line of documentation, will not submit one icon or even an idea towards making anything better.
I honestly don't see why the GIMP community needs people like him. This is not a product, nobody is making money. Is the loss of a guy who laughs at the name and refuses to use the product a loss or a gain?
I say it's a gain, I say it's a huge gain because the guy is going to end up being a drain on the morale and the productivity of everybody else.
Re:The difference between The Gimp and Excel.. (Score:3, Insightful)
Re:Maybe now the UI (Score:2, Insightful)
I personally prefer to the fact that I can access all the windows I need the same way -- from the task bar, or by alt-tabbing. Once I'm in an MDI application, I have to change to its window-switching method, and identify what documents I have open in a different way. If I've got a maximized document in most MDI applications, I have to minimize it or go to a menu to see what else is open.
Excel 2003 actually has the worst of both worlds. It's an MDI application that pretends to be an SDI application, with its default maximized documents. Each document shows up in the task bar, but if you do the logical thing and close the current window (instead of the subtle and nonstandard 'document close' button below it), it closes the whole application instead!
I have a dislike for permanent floating palettes, particularly when working with images. In MDI apps I tend to work maximized, as the document frame clutters the already limited space. This means palettes are floating on top of the page I'm trying to draw on -- and unless I'm zoomed in, I often can't pan the page past them. I have to keep moving palettes around, or close them entirely (and then have to go menu hunting when I want them back). The GIMP lets me bring the document in front of the palettes when working.
There are however plenty of legitimate complaints about the GIMP GUI, but they don't seem to be the ones people usually make. It's insistence in popping up operation windows (scaling, cropping, filters etc) in front of the image, for example. I've already got a Tool Settings palette docked under the main palette; they aren't modal prompts, so why can't these things be shown there? (It looks like the development version is looking at this, but they've made some other annoying decisions, like overloading ctrl, alt & shift during selection. I'll be providing some feedback on that front...)
Re:It's about time (Score:3, Insightful)
Re:The difference between The Gimp and Excel.. (Score:3, Insightful)
Re:It's about time (Score:3, Insightful)
In the big picture, this is why foss apps and oses still languish - foss advocates don't actually bother to count these numbers because they don't rely on large numbers of users actually *paying* for their product. Commercial software developers pay close attention to these numbers because they won't have anything to pay their mortgages and their kids' orthodontia bills with if they don't.
Re:It's about time (Score:3, Insightful)
It's misplaced options everywhere, needless mini-windows everywhere (instead of combining several within one), the whole retarted concept GUI (sorry guys, but outside the UNIX window manager world, that simply *does* *not* *work*), the non-standard file and print dialogs (GTK on Windows was always a kludge and never an integrated concept, for samples of this, see Eclipse and Firefox), etc etc etc. Never mind the fact that the UI doesn't even look the same as other apps. Basically, it's little problems anywhere and everywhere that come together to form a big big problem.
And now I'm bracing for the impact of a thousand replies stating that 1) it's meant to be learnt / 2) use a proper window manager / 3) the options are there if I want to find them (why should I "find them"? they're supposed to "be found"), and all of the other mantras that will kept being chanted over and over again.
Oh and by the way, even though I don't think it's a problem per se, the "GIMP" name isn't also the best choice. If anything, it's not catchy or easily remembered.
As a final note: I would absolutely LOVE if the GIMP became a proper, standard, polished, full-bodied app. I use several OSS apps by choice and I love those, but unfortunately the UI (or lack of) problem common with many free/OSS apps is definitely present.
Re:It's about time (Score:1, Insightful)
Names like that vary much from place to place. I don't know what libcaca is, and I imagine you're objecting to its meaning in Spanish. But in Swahili, it means "brother". *shrug*
Re:The difference between The Gimp and Excel.. (Score:3, Insightful)
Can you cut and paste from Inkscape into the GIMP?
No?
Then STFU about "the right tool", because the right tool or set of tools that gives you the combination of features you need doesn't exist in the Linux world. And until that changes, people are right to ask for easy-to-use drawing functionality in the GIMP.
And even if it were possible to cut and paste between Inkscape and GIMP, there's another reason they're right to want easy-to-use drawing functionality in the GIMP: because it's not uncommon that you'll need to perform some drawing on a photo or other complex image, and using another program for that isn't possible because the nature of the drawing operation requires that the drawing dimensions be taken from the photo itself. That's trivial to do if the drawing functions are in your image manipulation program, and difficult to do if they're not.
Re:It's about time (Score:3, Insightful)
No.
The Pantone Color System is a system of ink formulas, based on about 12 Pantone inks with patented chemical formulas. You can mix any Pantone color with the Pantone primary colors plus CMYK. But you cannot mix any Pantone color with CMYK. For example, there is no way to achieve an intense orange like Pantone Orange 21 with CMYK, because it is beyond the gamut of CMYK inks. That's why Pantone Orange 21 is a primary color in their ink set. There are clones of the Pantone inks, but they aren't quite the same formula, so they don't always mix to the same colors. Nobody's going to risk an expensive print campaign with hundreds of thousands of dollars of printing on imitation Pantone inks.
But if you want to use a system that is solely based on CMYK, you can use a non-Pantone scheme. Guess what? Most pro designers that don't use the Pantone CMYK specs use TruMatch, and they buy the TruMatch swatch books, oh my god, another licensed color scheme, they're making money selling a list of colors! Yes, designers prefer using a commercially licensed color system like TruMatch because it is a standard, every designer either has the swatch book, or can walk into any art store and buy one if they need one.
These are the realities of professional design and print work. If GIMP cannot pay for licenses for the standard tools of the trade, they will never gain acceptance. Professional designers use Photoshop because it uses the conventional, widely accepted systems like Pantone and TruMatch. Professionals lead the market, and if you can't gain acceptance with professionals, you have only amateurs as your market. Good luck with that.
Total Bullshit (Score:3, Insightful)
The shape drawing tools adds what... One button to the toolbar? And are easy and intuitive to use.
Having said that, I like the way you describe Gimp doing the same task, as long as I can edit the circle properties at any time afterwards, like stroke width and color.
Re:It's about time (Score:3, Insightful)
Gimp's problem are ideological (Score:5, Insightful)
I don't think the developers really want to know, else they would have responded long before since I've already told it several times. While the graphic drawing power of Gimp isn't disputed, Gimp sports the most uncommon GUI an application could have. This (and only this) GUI leaves a bad taste in the users mind so they start looking for other minor annoyances one finds in any application if looked for. Yet since most users a pre justice because of the bad taste they won't forgive any other annoyance.
This is all known in the Gimp community yet they don't want to acknowledge this simple fact but prefer to discard this as a flame bait. So it's now wonder Gimp gets flamed at all the time, rightfully or not. On the other side it's incredible easy for Gimp to drop off this flaming, they simply should change their GUI to the one outlined in wyoGuide (http://wyoguide.sourceforge.net/ [sourceforge.net]). All it needs is some willingness on the Gimp side and a little work. It might be that wyoGuide isn't the best but it certainly is good enough for Xara (http://wyoguide.sourceforge.net/projectlist.php [sourceforge.net]) and many other fine applications.
O. Wyss
PS. You are free to rate this as flame bait but that won't help Gimp.
Re:Gimp UI and how it could be even better (Score:4, Insightful)
However, it would be good to have a completely tweakable interface. I have already commented somewhere that right now many 3D modeling apps are configurable to work like other apps, and that you have a vi mode for Emacs and Emacs bindings for vi, and nobody finds it strange that people like it that way. Problem is, vi and Emacs are used by coders, and coders can build their damn interface themselves. Most users of GIMP (and certainly most advanced graphics manipulators) can't. But they are right in saying they work better the way they do. Users are not idiots, and they know how they work better. What we need is not really "reskinning the Gimp, and more", but just the ability to tweak what really matters to you.
Not all features are equally important, or used equally frequently. Right now one can reassign shortcuts and move menus around, but modificator keys (keys that act as a "shift" to active tools) are still hard-coded, or were last time I looked. (Caveat: I haven't tried to configure it in a Photoshop way in a long time, as I am already used to the GIMP's UI, so I don't miss Photoshop's that much).
The thing I would love to have in GIMP is the space-alt-ctrl trio of modificators to invoke the hand tool and the zoom-in and zoom-out tools while in any mode. This is so powerful a way of working that I am almost religious about it, despite having retrained my muscular memory not to hit the spacebar with my thumb every time I want to readjust the working area. Also, later versions of Photoshop has evolved really nifty docked option palletes for tools (like the search feature in Firefox) that I haven't really used (as I am now a GIMP user), but they look fantastic.
Finally, some of us liked the MDI interface behaviour: sometimes, when you are editing photos, it is all you are doing (see below for single-app computing), and the focus behaviour of Photoshop is much saner than the Gimp's in many places. I know this is not the Gimp but the X11/WindowManager combo that provides window management; maybe what some users need is a PhotoGimpWM.
Contrary to popular Slashdot opinion, some of us who ask for certain Photoshoppy-features in Gimp don't want a clone of Photoshop. What want is the ability to really customise the way we work in a Photoshop-like app (and, like it or not, Gimp is Photoshop-like, see below) in the features that matter to us. Other people would like a Gimp preference option that adds a complete "behaviour" of the most-used and learned photo editor in the world. Think PhotoGimp on steroids, and if I were a coder working on the Gimp (sadly I am only a punter), this would be my first feature to add for propietary-software refugees' sake. Free Software being coded by volunteers, we can't make them do what we want... but that doesn't make our needs and wishes irrelevant or wrong. Just unenforceable
I have worked in TV with people using the Quantel series of graphical pallettes (concretely the superb HAL), and their gestural interface had nothing to do with Photoshop and Gimp's WIMP paradigm. However I would love the Gimp to have support for its dedicated clicker [note] for my left hand while I work with the pen in my right hand. I wouldn't mind to try the HAL's gestural interface either: it seems like a right timesaver, although I don't know how it would fare in a multi-purpose computer running other programs at the same time. In non-windowed environments where the only thing running is the graphics editor, however, gestural interfaces to be the right thing for bringing up pallett
Re:The difference between The Gimp and Excel.. (Score:3, Insightful)
However, that's the situation with graphics editing. The GIMP has no vector editing capabilities worth mentioning, but it's good for raster images. Inkscape does vectors but not it's not good for raster stuff. The Unix way would be to combine them, of course.
There is no direct communication between the programs, but if there was copy and paste support between them we'd at least have something resembling easy communication. But in fact if you want to create a somewhat complex vector/raster image you have to do all raster editing in the GIMP, then save the stuff to (a) temporary file(s), then import the file(s) in Inkscape. You can't tell how a vector edit looks in the image until you have exported that "layer" to Inkscape. That's not the flexibility of a Unix shell, that's using no pipes and one command per line - in other words, completely inadequate. Thus, there is no decent way to use the GIMP if you want the image to have a vector component.