GIMP and GEGL in 2018
gimp.org
gimp.org
The software could never be widely used in UK schools IMO. The bracketing of "I know it's a weird name, but I've used this programme for years, ..." is just too cringey for me when sharing in polite [or perhaps timid] company.
I know it's hard to get cross-language, cross-cultural names, ... I still don't know why they didn't go with Imp [nor what creature Wilbur (Wilber?) is supposed to be!].
Sorry, not wanting to start a flamewar but it should be mentioned IMO. Here's 2 threads where it's raised so we don't need to cover any of that ground again (both/all sides are represented I think; selective quotes):
1) https://arstechnica.com/civis/viewtopic.php?f=2&t=22973 'Here's a sign of immaturity: Naming a product "GIMP".'
2) https://www.reddit.com/r/opensource/comments/6cs6wk/small_gr... 'the GIMP's name has long been the classic example of how bad open source projects often are at branding and marketing'
I must say as a non-native, I didn't knew gimp before and was not offended. Googling in incognito mode, I can absolutely see why people might want to avoid that.
I've actually, conversationally, shared "gimp" with a couple of people in the past but I don't any more because I don't want to make them feel uncomfortable or think I'm making a joke at their expense. In a workplace I'm not sharing something that could get me facing a sexual harassment suit (it's not likely, but why risk it), or fired for offensive language (ditto).
This thread _is_ about marketing.
I'd have no problem talking with someone about "mongo-dee-bee" though, because I doubt they'd ever assume it was referencing that (now unused) slur.
The fact that Audacity or GIMP exists at all and was free was shocking to a lot of us. Programming audiovisual stuff competently took knowing the CPU on a machine-code level if you wanted to get a usable program (and wanted clients to be able to get something done in weeks, not months) and the idea of doing all that work for free would just get belly laughs from most folks.
There's a reason the highly optimized stuff still costs hard money, and it's not due to hubris.
Also the reason is "A small company misjudged how to-the-letter-of-the-law GPL developers were", perhaps with a sprinkle of "some people rather maim C than using anything else".
Edit: Seems like blender is indeed better funded: https://fund.blender.org/ Nothing crazy tough.
Marketing was also a factor. Years ago, Blender was similar to how OpenShot is now --- pretty much unknown to the general public, but it shows up in blog posts a lot, and those who use it think it has potential. As time went on and it became more featureful, the news about Blender changed from "This promising project is working on making a modeling suite..." to "This software can replace 3DS Max right now and it's completely free". GIMP's publicity has only gotten worse over the years as it suffers from perceived bit rot and an inability to add requested features over the course of a decade.
That doesn't mean Blender users need to do that to be productive, but it definitely gives actual users a stronger voice. I find free software generally doesn't work as well when there's a hard split between the developers and the users, unless those developers are incredibly empathetic, clever, and well funded. (Or just fully aware of the problem they're solving, but it's hard to find a large sample of people that can write a really good vector graphic editor, have a clue about UI design, and are also keenly aware of the problems people deal with when they're drawing a graphic novel).
You can see that process working well with Blender's open movie projects (https://www.blender.org/about/projects/). I haven't paid attention to them recently, but in the past they have been structured around building some new feature in Blender, such as improving the video editor and motion tracking experience (Tears of Steel), or rendering and sculpting (Sintel).
Meanwhile GIMP has a reputation of being written by software developers for software developers, and being actively hostile to suggestions from artists...
Actively hostile how?
> "How did you dare to hack on Gimp, doing this, without doing us the courtesy of asking for permission first!"
That is a bit of an overstatement.
"It would be nice if you talked to us first" != "How dare you do this without asking for our permission"
Yosh wasn't even demanding permission, just basic courtesy.
Source: https://marc.info/?l=gimp-developer&m=90221516928016&w=2
Free software projects don't usually have an abundance of contributors, as you very well know. So I kinda get why Yosh was disappointed, although I don't think he should've fretted that much.
Given how cheap and good Photoshop is I just can't imagine why you'd use Gimp. (Sorry Gimp. I love open source too, but... Photoshop.)
This is quite unlike most other open source projects in the libre graphics community (like GIMP, Inkscape, etc), which are run by a loosely organized group of people doing this primarily as their hobby or side-project. That some GIMP devs now get a bit of money is actually a quite recent development.
So over the lifetime of GIMP and Blender, Blender has had many more manhours (10x?) dedicated to it - and more product/market focus. Though developed very differently, both are quite successful open-source projects, and widely used.
Disclaimer: I got some commits in GEGL/GIMP.
EDIT: Krita, also mentioned here, is developed more in the style of Blender, with Boudewijn Rempt being the key facilitator.
One would assume that the desired features would have simply been offered as pull requests by the community, or, barring their acceptance, multiple competing forks would emerge filling the market need going unmet by the Gimp developers. Yet somehow there seems to be just as much 'vendor lock in' with FOSS as there is with proprietary software.
In a FOSS project fork, one needs to out-code the original project in terms of features delivered to users, out-market it to build brand recognition, and create enough network effects that potential contributors choose the fork instead of the original. And with the stamina to do this for a few years while shake out. Since there seldom is a lot of money to go around for funding this effort, it is very challenging.
OpenOffice -> LibreOffice was a relatively recent successful example, but it took many people a lot of work over many years. Node.js -> IO.JS -> Node.js was interesting in that they merged back together, with the combined momentum of the fork and original.
If memory serves the KDE guys did a port of GIMP to Qt but eventually dropped it due to all the teeth gnashing on the Gtk side.
I've been involved in KDE Community in the past 10-15 years and I'd never seen so much bad blood between developers of both communities publicly.
It shows that the flame wars that still continue to this day had a root.
https://www.gimp.org/docs/userfaq.html#arent-you-interested-...
No, we can't. Managing a campaign and its outcome is a full-time job. Should we first campaign to fund the campaign management? But then we need to campaign to campaign to manage campaign. And so on.
babl is a dynamic, any to any, pixel format translation library
GEGL (Generic Graphics Library) is a data flow based image processing framework, providing floating point processing and non-destructive image processing capabilities
Been waiting for those for years now.
Common, MAKE IT HAPPEN!
In a lot of ways gimp feels like it's perpetually stuck as a clone of Photoshop 4.0 or 5.0. If it can finally get adjustment layers that will help somewhat.
You can theoretically do almost everything in gimp that you can in photoshop, but since CS, photoshop has lots of functionality that makes things much easier (fewer steps), so the ergonomics of GIMP seem pretty bad in comparison now.
Adjustment layers are supposedly coming in 3.2. Who knows how many years that'll take though.
> Shape tool - Easily create circles, rectangles, N-side polygons, stars etc.
(That's in the future list, and not planned for any of the next three releases. Not fully sure I understand that priority call...)
Sad reality is, people expect more. There's something satisfying about being able to click a 'draw shape' icon on a tool bar and then click and drag to draw the shape on a canvas. That's an expectation that dates back to at least MacPaint in 1984, and it's a huge difference from drawing a shape using a rendering plugin buried under three menu levels.
GIMP is targeted for hi-end workflows. Your average matte painter or photographer doesn't usually need to draw a rounded-corners rectangle, but he sure needs adjustment layers. Hell, even the CHANDRA X-Ray observatory guys need adjustment layers for coloring their FITS files!
So that gets a priority.
What the 2018 report specifically says though is that most things from the 'Future' section can be done right now by a new interested developer. That includes drawing shapes.
I've used it on-again/off-again since version 0.54 (95-96), and it played a formative role in my own software career.
It's hard to progress anything without participation...
Sad, really, given the important role Gimp played back in the late 90's. Gimp was initially the G in GTK, and was closely related to the foundations of Gnome. (And Gnumeric.... which, to my understanding, has the same sorts of issues as Gimp.)
Back in the day I tried to port xournal to gtk3 and it was a nightmare because there was so much breakage between gtk2 and 3. So much so I gave up. By comparison porting my own stupid python scripts between major versions of qt was painless.
If you want to write a public API to access text layers and then patch the PSD plug-in for text layers support, you are welcome.
If you want to make the tool's options dock optionally horizontal and docked to the top (a-la Photoshop, Inkscape etc.), you are welcome.
If you want to improve OpenEXR support, you are welcome.
If you want to improve the text tool (easy text on path etc.), you are welcome.
There are hundreds of things GIMP could do better. We know that. We welcome contributions.
The only thing we don't feel good about is when people tell us to make GIMP look and work like Photoshop "because Photoshop". GIMP is not a clone of Photoshop. We need better reasons than that. Apart from this, you are welcome to come and propose changes.
Edit: to be fair, two other topics we don't exactly like are project name change and save/export :)
Perhaps GIMP would have more users and more contributors if it embraced a few things that have become de-facto standards in image manipulation.
I switched to Affinity a few years ago, and it was tough to "unlearn" photoshop, but it was worth it. (But it could have more painful if Affinity was as weird as GIMP)
Such as...?
I almost hate to write what I'm about to write, but...
When I needed to add some text and labeling to an image, it was easiest just to drop the $30 on a Pixelmator license. For dealing with RAW photos from a handful of cameras, it was $120 on a license for Adobe Lightroom. Both have generally served their purposes well. Some of those features I could've implemented myself, but some I couldn't, and none of that work fits into a schedule full of other obligations. (Technical and otherwise.)
I think the difficulty with open source end user app development is that it can ask a burden of its community that few people have the skills to bear up to and even fewer have the time or inclination to do so. From my point of view, this leaves me with a combination of gratitude for the people like yourself that actually do step up, but also a degree of frustration that there's no easy way to make the situation better.
At the end of the day, I think the strength of OSS application software is that, by virtue of being OSS, it's possible for it to be things that closed software cannot.
Like this, a really long time gap can pass between two stable versions even if the code has been under active development (remember the Linux 2.4 -> 2.6 transition?).
Of course it's a lot of speculation on my part, and no, I'm not advocating for time-based releases (they IMO make no sense for this type of project).
I wonder how much of the slow pace of development can be attributed to technical debt? As such an old project, I would imagine a great deal of the code involves old compromises that no longer make sense on modern PCs. With such limited available developer time it can be really demoralizing to have to deal with that stuff.
Moreover, with old APIs and languages you lose out on the productivity gains made by modern tech.
Unfortunately they picked Lua instead of developing their own language like Emacs did. Lua is pretty notorious for having an absolutely abysmal implementation and is very hacky itself. It's also unfortunate that the GIMP team didn't have the same hardline commitments as the GNU devs to code correctness (GNU will often delay project releases long past their expected drop dates just to make sure the code is maintainable and nothing is hacked together - see the year-long delay in the release of IceCat Quantum for a recent example of this). This situation got even worse when the devs decided to abandon the graphical toolkit the whole thing was written in in version 0.60 to invent their own, which didn't even include bindings for the scripting language they themselves were working in...it soon became quite a time commitment for any major feature to be implemented because the code base just wasn't designed with futureproofing in mind.
Eventually GTK grew out of scope for GIMP and became a GNOME project. Around this time large parts were rewritten again in glib when GIMP became a GNU thing. Add twenty years, and GIMP is essentially a giant steaming pile of hacks that never made sense in the first place, full of components that barely work on their own, much less together.
It's a sad state of affairs, especially considering the project had so much potential back in the day. It could have been the Emacs of photo editing, but poor planning from the get-go dashed that possibility.
Do you know of any blog posts or articles about this? I'd be curious to read more about what the problems with the implementation are.
There was never any Lua in GIMP, you made it up.
> Add twenty years, and GIMP is essentially a giant steaming pile of hacks that never made sense in the first place
Hold on. So GIMP had "potential back in the day" when it was in fact a pile of shit code, but today in the age of proper GIMP code, it's a "steaming pile of hacks"?
Is it? I've heard complaints about the language design, but never about its implementation. At least not the C API. It seems odd that a language "notorious for having an absolutely abysmal implementation" would be so widely used as a configuration/glue language.
The main alternative implementation, luajit, is considered to be nothing short of magical.
Unfortunately, and I don’t like going ad hominem, as the scripting language for GIMP is not, and has never been, Lua, I wouldn’t recommend taking anything said in that comment too seriously.
BTW the base scripting language for GIMP is a Scheme dialect called Script-Fu. I can’t comment on its implementation as I haven’t seen it.
Probably unknown to many here is that GIMP also has an API. Actually two, the C API and the PDB API (Python/Scheme/etc). This is used by third-party plugins that extend/customize GIMP for various purposes. Many of the existing plugins that people use are quite old, and often poorly/unmaintained. Keeping these plugins working is the main consideration for why the GTK+3 migration was not done in mainline until 2.10 was released, since GTK2->GTK3 is a breaking change in the C API.
Of course C, GObject and GTK+ are probably not what anyone today would choose today as the base of a graphical image manipulation application. Other UI frameworks would have a larger mindshare, and other programming languages might require less skill/care to code in. Allowing UI elements to be written in another language than C89 would probably make things more accessible to contributors, in my opinion. But a two-language split in an application has disadvantages also.
Preserving compatibility with existing projects that users have is also something that takes a good bit of resources and can restrict movement a bit. It was the last big piece to solve for getting GIMP 2.10 with high-bitdepth support ready. But breaking peoples project files tends to make users unhappy... To keep old files alive and rendering correctly there is a fair amount of legacy image processing code being kept around, but it is factored to not be that much of an issue.
I hope blender new release give people some ideas.
Suggesting CMYK is holding something back is literally suggesting that the individual wants discrete control over the inks in the machine, without considering the colour of the inks, the paper colour, the saturation level of the paper, etc.
Clean plates for spot printing? Fine. CMYK painting? No.
Late binding has been the path forever, and is the only way forward. As a result, anyone suggesting they need CMYK has a debilitating grasp of how printing works.
> (color space? doesn't matter! Pick any CMYK!)
You realize that “color space pick any” has an implicit connection to the actual physical inks and what colours they print? Good.
As in it is a clear beacon that you don’t understand a shred of what you are replying to. I’m sure your professional(!) print runs that you have done have taught you that, though.
It's pretty basic, I know GIMP have a reason to make it more complicated and painful, but I don't agree with it.
Using .PSD as the native format would be risky, its direction is set entirely by Adobe, there are dozens of different versions, and many Photoshop features which would be quite hard to support. And maybe some existing GIMP features would be hard in PSD too. For instance the non-destructive features in PS are mostly "adjustment layers", which might not be exactly the UI concept that GIMP wants to use for non-destructive editing.
But, GIMP does have a PSD file loader/saver. It is always in need of improvements, so any contributions would be very welcomed.
Then leave the legacy behavior in place. Telling your existing users that they aren't important enough compared to mythical new users is pretty poor behavior.
Never change anything, in other words.
Hobbling the save interface only serves to make the lighter weight workflows more difficult (because they're not glamorous for the GIMP devs) while doing zero to improve the more dev-favored workflows.
We do. All the time.
> For all the bleating about professional features, they sure miss big ones like CMYK support.
Which is being worked on.
It's fine for GIMP to have a native format. But it's quite another to try and force the world to use it by making all the other, rather more common, formats second-class citizens.
If you need a more simplistic tool, try Pinta.