Slashdot Mirror
GIMP's Next-generation Imaging Core Demonstrated
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.
They need to get this integrated before http://www.koffice.org/krita/ runs them over :)
- barkholt
Maybe now he can give The Gimp a decent UI instead of the trash it's had for the last 10 years
With a lot of open source projects, your thinking would be embraced to make a great product. See Firefox, for instance. The problem is that the GIMP developers just don't give a flying crap about it what-so-ever, so give up now. Photoshop Elements is only $90, does everything GIMP does but better, and is about 10 times easier to use.
Comment of the year
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.
[
Yes, the color management is an issue (unless we were to make a gimp-non-US), but not a technical one - until the USA stops travelling down the copyright/patent path of infofascism, the gimp team can't _legally_ implement certain features. Sigh.
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.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
"Ask any Gimp developer why this is such a bitch and they'll tell you something like: The Gimp is an image manipulation program, not a drawing program, go use Inkscape or something if you want to draw circles."
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.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
But its a fork. If we have to fork The Gimp every time we wanna do something that the current people with power over the source code repository don't like, all we're going to do is fragment the userbase. That divides our community, causes wastage, and disgruntles developers.
How we know is more important than what we know.
Yes, good point. Forking isn't always the best way, but it does demonstrate the power of determined people to turn open source products into exactly what they want or think other people want--for whatever that's worth. I mean, next thing you know, we'll be forking Firefox because of its logo. Hmm bad example...
Uhhh... do you also think Photoshop should be rewritten from the ground up to use QT so it can run on Linux and BSD?
I see your "the customer is always right" cliche and raise you one "use the right tool for the right job".
Learning HOW to think is more important than learning WHAT to think.
Schwab
Editor, A1-AAA AmeriCaptions
Please mod parent up. Please use the right tool for the right job. If all you want to do is create circles stick with MSPaint or MSOffice/OpenOffice or Inkscape (highly recommended). If you want to do Photoshop stuff, use GIMP. If you want to disagree - fine. If you want to understand see http://gimp.org/about/ and read the threads about what the developers were trying to accomplish. Drawing circles was never on the list. Peace
"The difference between stupidity and genius is that genius has its limits." -- Albert Einstein
Balderdash. It's got nothing to do with the success or failure of OSS. Rather, it's a general problem that plagues the application software industry and lowers the productivity of the hundreds of thousands of people out there using the wrong tool for the job. Look, you might be able to pry a crate open with the other end of a clawhammer, but it's a hell of a lot less effective than a crowbar: you're going to break a heavier sweat because you've got less leverage, the prying end is the wrong shape, and you're probably going to bust the crate to pieces with the hammer; use the right tool and you're done in a shorter amount of time, have exerted a hell of a lot loss effort, and you can reuse the crate. Similarly, you can use a butter knife instead of a flathead screwdriver, because they're vaguely alike, but there's no arguing that one approach is right (efficient, won't strip the screw) and the other is 100% hamfisted and should only be done in the case of an emergency situation where the appropriate tool isn't available.
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.
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.
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 main problem. Put simply, it's too low-level for a useful GUI toolkit. This is made particularly clear by it being written completely in C.
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.
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.
Look stupid saying it like that, but Color management seems important enough for professional to pay for Photoshop (500$-ish) instead of the much cheaper Photoshop Element (50$-ish)
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.
The question is why would you want this guy to use GIMP? If he refuses to a product based solely on name without even bothering to learn anything about it he will probably hurt the community more then helping it.
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.
evil is as evil does
You, like The Gimp developers, have absolutely no concept of UI design. Providing simple tools for common tasks and leaving complex tools for advanced users is a fundamental element of good UI design. Sigh.
How we know is more important than what we know.
I think firefox is a special case because an increase in share in the browser market will discourage people from writing IE only web sites. The photo editing industry does not have a similar situation. Whether GIMP has one user or a million only makes a difference in so far as those users help or hurt the community. I say a community of 10,000 active helping users is better then a community of one million whining ones.
evil is as evil does
That's the usual argument given by The Gimp developers. Drawing a circle is a perfectly reasonable thing to expect a bitmap manipulation program to do. Especially seeing as every other bitmap manipulation program does it.
How we know is more important than what we know.
Sometimes in arguments such as these the truth is not halfway between the two sides - sometimes one side is just wrong. In this case, the cross-platform side is just wrong. Why? Because the number of people who use many different applications all on one platform is a couple of orders of magnitude larger than the number of people who use the same application on more than one platform. This being the case, it is far more important for application GUIs to be consistent across applications on a single platform than it is for the GUI for any one application to be consistent *across* platforms.
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.
A proper GUI. Repeat after me, "a proper GUI". I've tried using GIMP in the past, first on Linux, then on Windows, every time that it seemed to show some advance, and the GUI didn't seem to change, if at all.
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.
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*
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.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
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.
I use Paint Shop Pro 9 and I sometimes have to use both things, shape drawing tools and photo manipulation tools in the same file.
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.
We are Turing O-Machines. The Oracle is out there.
Well, since The Gimp's developers are commited to keeping the program free, if one of those technologies is available only under an NDA or other restrictive license, they effectively can't use it.
Everyone is born right-handed; only the greatest overcome it
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/). 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) and many other fine applications.
O. Wyss
PS. You are free to rate this as flame bait but that won't help Gimp.
See http://wyoguide.sf.net/papers/Cross-platform.html
I too like the GIMP interface in many places, and use it exclusively for retouching my photographs (professionally published, as for instance in the Spaish edition of Rolling Stone). I export my results to a Photoshop .psd file, including a layer with the untouched photo for the editors to have a reference of what came out of the camera, and I send it to the photo editors. I don't miss CMYK or colour matching because, you know, they have that at the magazine.
;)
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
http://barrapunto.com/ - News for nerds, en español
However, the Unix way of using small tools that perform one single function only works so well because you have easy communication between those tools. Imagine you could not pipe one program's output into another program - every single nontrivial task would require you to juggle temporary files.
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.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)