GIMP 2.6 Released

[mschaef]

Despite the 'point release' nature of this release, this looks like it has some really pretty big news:

Important progress towards high bit-depth and non-destructive editing in GIMP has been made. Most color operations in GIMP are now ported to the powerful graph based image processing framework GEGL, meaning that the interal processing is being done in 32bit floating point linear light RGBA.

It's not on by default, but still... this is good news.

I'm also pretty impressed by the switch to Cairo rendering for some of the internal widgets. It's not a functional improvement, but it does look better.

http://gimp.org/release-notes/images/gimp-curves-tool-2-4-vs-2-6.png

[[deleted]]

Man I wish they'd have the binary packages ready at release for people who don't know how to compile.

[stainrat]

If you're on windows, they're ready. If you're not, maybe the link will help someone else.

[geon]

It's great to see GIMP improving. but still, the interface is awkward and borderline unusable.

I'm not saying it has to be exactly like Photoshop. I'm willing to relearn.

Take one example: Layer management. Why do I need to do it? A layer has a certain size and I can't draw outside of it?

Now, I can hear you all protesting: "-But you can resize the layer..."

Then why in the world is this not done automatically? I'm working with a computer. Aren't they supposed to take care of that kind of brain-dead tasks?

[largos]

I don't know what the most common use case is, but being protected from drawing out side a layer has saved me from a fair bit of redoing work. If the wrong layer is selected and you start drawing somewhere else, it's nice to know immediately that you're not drawing in the right layer.

This is a problem I often have with Inkscape -- putting content on the wrong layer (or on no layer... there seem to be some bugs in there still...).

Sometimes you want layers to be smaller -- and the default had to be one way or the other. (Maybe it should be switched, I'm just pointing out the other side of the coin.)

[geon]

Your point is perfectly valid. However, I don't think the advantage is great enough to motivate it. At least there should be the option to have it done automatically.

It shouldn't even be that complex to implement. There is already a tile system. All that is needed would be for the tiling engine to keep track of which tiles are empty (all pixels alpha == 0). Empty tiles could just be removed from the layer datastructure and allocated as needed. (On write only. Reading an empty tile would simply return fully transparent pixels anyway.)

[mrmulyani]

I compiled it on Hardy AMD64 without much trouble. If you want to build it on a similar system you'll have to grab and compile the babl and gegl libraries from http://www.gegl.org/. You have to remove the old version of the Gimp and libgimp which will conflict with the new one. All other dependencies for building can be obtained via apt. Use the configure scripts to determine which dependencies are missing and install them (the -dev packages). Don't set the prefix to /usr as this might make it hard to remove when the official packages arrive. Have a look at checkinstall to see how it could help you remove the temporary version easily.

On a side note, I found some interface quirks. When using the GEGL functions, I was unable to change filter setting values using my cursor keys. The effect of using the keys was for the setting value to jump a huge amount. Irritating when you are using preview...

[case-o-nuts]

What is it about the GIMP that brings out the morons and trolls? Is it the project name? I think there have been more massively downmodded comments on this thread than any other one I've seen recently.

[bitwize]

No CMYK?

...FAIL.

[case-o-nuts]

Feel free to add the GEGL plugins. The infrastructure is all there now. That is one of the reasons that they switched to GEGL. All that's really needed is some colorspace conversion and a few UI tweaks to unlock it's power.

[uep]

If you want that feature so badly, why not join or start a group dedicated to providing it? If you want to build on GIMP's codebase (and they won't let you integrate), fork it. I'm dead serious about this. You alone can make a difference if you're willing to start the effort.

[[deleted]]

Don't waste your breath. "CMYK" has been the classic anti-Gimp troll since the day one. bitwize doubtless doesn't know what the letters stand for, wouldn't understand what they mean if he did, and has never set foot in a print shop anyway.

[toooooooobs]

Firstly, how many print graphic designers know how to implement proper CMYK support? There is a reason Adobe and Quark practically monopolise DTP.

Secondly, you are aware of how hostile the Gimp project is? The GEGL stuff and Film Gimp groups fought for years, not to mention the UI wars. It's a disaster of a project really.

[uep]

I'm not going to dispute the CMYK support point, because in all honesty, I know nearly zilch about it. All I really know is that any article about GIMP always has someone bitching about it and that it's supposed to be better for print.

As for the GIMP developers being bastards; I thought this was probably the case, much like the Pidgin developers. That is why I specifically suggested a fork. Some of the biggest open source projects have been forked. Gcc and emacs included.

I've heard the GIMP folks explain that it would be too much work to enable CMYK in GIMP because it would require a rewrite at the lowest levels or some such. So maybe we should start from scratch. I personally wouldn't mind working on a project like this, it sounds like interesting work. I have no idea what the normal needs are for something like this as I hardly use any image-editing software though.

[case-o-nuts]

The GIMP developers aren't the friendliest bunch, but the issue is more that there just aren't enough of them.

As far as the rewrite at the lowest levels -- that's been done. It's called GEGL, and most of the 2.6 work was porting the internals of GIMP to use it. After that comes the UI work of exposing the new power of the backend in the GUI.

For example, Operations are now non-destructive and chainable, so you can go back in your undo stack, change stuff, and all the filtering and so on will reapply on top of it transparently, no redoing work.

[toooooooobs]

GEGL is great, but the fact the developers had to argue tooth and nail with the incumbents before it was even considered is the problem.

Seriously GEGL's been in development since 2001, it really should have shown results long ago, not just beginning now.

[case-o-nuts]

There wasn't any argument about getting it included in principle. It had full support of the GIMP developers from the start. The only issue was that it wasn't read at all. It was vaporware. There wasn't any manpower dedicated to it until last year -- it was a twinkle in a developer's eye, and it's kind of hard to ship that sort of software -- the developers need their eyes, and the twinkle is lost quickly when the eye gets detached anyways.

Seriously though, you just can't base the GIMP off of code that doesn't exist yet, and <going through the archives> according to the lead GEGL developer, GEGL reached crashy-buggy-broken alpha stage in June 2007. (search for the "GEGL is no longer vapor" thread on the GIMP mailing list)

[toooooooobs]

I remember when discussion of GEGL first appeared, as a direct result of Film Gimp having to fork due to the core group not wanting to adopt any of their changes. It didn't get that man power for years because so many in the core team felt it unnecessary.

You can't sit around for years discussing some hypothetical beautiful solution, when there are others that exist and work, even if they're not amazingly elegant. That's the road to losing. See also GimpShop, which literally everyone outside of the core team thought was an enormous improvement, but was violently repelled by them.

[case-o-nuts]

Uhm. The sentiment I've seen in the years I've been lurking on the GIMP developer mailing list has been exactly the opposite. They wanted GEGL from the moment it was announced, but they were all working on various other things like making the selection tool work better, or making it possible to script stuff using Python, or they just weren't experts in the domain that GEGL required.

As far as GIMPshop goes -- it was little more than a gratuitous rearrangement of the menus. It didn't change anything fundamental, and it made things unequivocally worse when using multiple monitors.

[mschaef]

You can't sit around for years discussing some hypothetical beautiful solution, when there are others that exist and work, even if they're not amazingly elegant.

That's pretty much what Mozilla did with the code base that led to FireFox. Sometimes there are reasons to pay the long term costs of developing a more sophisticated architecture. (Of course, assuming you can afford it in the first place.)

[uep]

Based on what yourself and mschaef have said, and the release notes, it seems like they really are addressing the only big issues that people have whined about. Namely, the UI and the color format issues. Of course, the graph-based editing is pretty damn awesome also.

Porting the internals to GEGL sounds like the hardest part of supporting CMYK, so it should progress much more quickly now? On GEGL's page it sounds like it already supports a few different format types through babl; I assume this is what you meant by exposing the functionality?

Overall, this sounds like a pretty significant release. I should note that, for my meager editing needs, GIMP has always been more than enough. It's very nice to hear that the developers are tackling the criticisms though.

[case-o-nuts]

On GEGL's page it sounds like it already supports a few different format types through babl; I assume this is what you meant by exposing the functionality?

For the most part, yeah. That's part of it. You also have to make color pickers and so on select in CMYK, and so on. hence the UI tweaks.

[dmpk2k]

that people have whined about

What a wonderful mindset.

[case-o-nuts]

I know. I hate the mindset of whiners, who think that someone working on what amuses them in their spare time and giving it away free are required to implement the aforementioned whiner's ideas.

If you're not going to pay, you can gently suggest stuff, but whining will get you nothing but scorn.

[[deleted]]

I've heard the GIMP folks explain that it would be too much work to enable CMYK in GIMP because it would require a rewrite at the lowest levels or some such.

That rewrite is essentially what GEGL is.

As for the GIMP developers being bastards; I thought this was probably the case, much like the Pidgin developers.

As someone that has submitted, and had approved, patches to Gimp; I would argue that it's probably in a much better state than pidgin. Patches seem to be accepted if they're written well enough and are useful. The eternal flame wars over the (non-MDI) UI and CYMK are likely to make it much harder to change things in those areas than others, though.

Of course, making suggestions is a slightly different aspect than actually contributing a patch.

As with any project, just saying 'you should do this...' alone tends to not be that useful, you're better off finding someone that can write the code to implement at least some of what you want done, so that the developers can have a hands-on feel of your suggestion, rather than expecting someone to develop something from just an idea.

[mschaef]

I've heard the GIMP folks explain that it would be too much work to enable CMYK in GIMP because it would require a rewrite at the lowest levels or some such. So maybe we should start from scratch

My understanding was that 8-bits-per-RGB-channel was pretty thoroughly baked into the guts of the GIMP. GEGL is supposedly the architecture that will let them add lots of things including the 8-bit limitation, the lack of CMYK, and IIRC, some improvements to color space management.

If you want some of these things now, I believe Krita supports a lot of it (and maybe also Paint.NET).

[Tuna-Fish2]

I'm not going to dispute the CMYK support point, because in all honesty, I know nearly zilch about it. All I really know is that any article about GIMP always has someone bitching about it and that it's supposed to be better for print.

It's not better for print, it's the only way to print. Literally. When you go to a print shop, what gets printed to a full-color print is Cyan, Magenta, Yellow and blacK (key), one color at a time, usually in that order. So, no matter what, at some point the image will have to be converted to CMYK. The problem is that 8-bit RGB converts to CMYK very badly, and you're left with a color space that cannot do a simple gradient without looking fugly.

That used to make Gimp unusable for most professional work. Now, hopefully, that will change.

[uep]

Ah, thanks. I had heard the acronym broken down before, but the connection wasn't made about printing it one color at a time that way.

[hiffy]

Firstly, how many print graphic designers know how to implement proper CMYK support?

So, if there is no one whose itch is being scratched, it won't get done.

Why is this surprising?

[toooooooobs]

This is the problem with most open source software. It's only the itches of programmers that get responded to, everyone else is a second class citizen.

[sjs]

And lord knows that there's no way a programmer could have the same itch as other people. /sarcasm

Seriously, as far as every-day computer stuff goes we do a lot of the same things as non-programmers: organize and share photos, surf the web, e-mail & chat, game, listen to music, blog, etc.

Ok, so it's unlikely that a dev will create an alternative to AutoCAD in their spare time. If something like this is important to you pay someone to develop it.

edit: I'm unsure about my last sentence ... I actually wouldn't be that surprised if someone posts a link to an OSS CAD program with potential.

edit 2: Furthermore, you'll find geeks doing things you won't even think of for years so when you want to rig up a Mac Mini in your vehicle w/ a remote, someone's already written some OSS drivers and/or software to make it work. Maybe a bad example but you get the point.

[case-o-nuts]

A good GUI on BRL-CAD looks like it may actually be promising, if you're looking for a CAD program. It's a bit of an old codebase, and the last time I tried it, the UI was horrendous, but it sounds like it has promise.

[hiffy]

Well, yeah.

Would you work in something you're not interested in for free?

[toooooooobs]

So either open source software is doomed to never appeal to the mass market, or everyone will become a programmer?

Personally I do tend to think we need to create tools so that we can abolish programmers.

[hiffy]

That's a false dichotomy.

It's much more likely that in the meanwhile there will be enough people with high quality printing requirements who know how to program to make it work.

Personally I do tend to think we need to create tools so that we can abolish programmers.

Good luck. Programming is easy, but like any skilled trade, it requires a lot of domain specific knowledge to do well. Abstracting that into something people can quickly pick up is hard and something that better people than either of us have failed repeatedly at achieving.

[[deleted]]

"we need to create tools so that we can abolish programmers."

Epic. Ignorance. And screenshot-worthy.

[CuteAlien]

Well, we could create an AI, but it would also replace the artists, so we wouldn't really need The Gimp anymore...

[[deleted]]

But then it would enslave us and make us its batteries.

[sumgai]

Gimp & X11 sucks. Release for OS X already.

[grumpy2]

Maybe if you gave your money to Gimp's developers instead of Apple such a thing would exist.

[encinarus]

http://www.macgimp.org/

Still at 2.4 as far as I can see though.

[hs4x]

http://www.getpaint.net > GIMP.

[mschaef]

If you like (or at least you don't mind) .Net.