It's pretty ridiculous since GIMP is 22 years old and GEGL is 18 years old.
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.
Inkscape has scripting as well, so maybe a lot of that cumber can be automated. I've never looked into it, but you can be sure a lot of google results will take the form of "can i automate [x] with inkscape?"
Or you can script GIMP to do it directly. GIMP in fact already includes a script for drawing shapes under Filters->Render->gfig. The UI could stand to be improved but the feature is basically already there.
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.
My understanding is there are very few people contributing to GIMP development. The only regular GIMP-related anything I see on planet.gnome.org comes from the ZeMarmot project.
It's hard to progress anything without participation...
This is my understanding, as well. I don't know why it happened that way, but contributor mindshare really moved away from Gimp years and years ago. Other similar projects have been released and surpassed Gimp in feature compatibility in the time since Gimp has been released.
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.)
I had heard the same thing, but the article linked here seems to indicate a very healthy attitude towards cooperation. I wonder how much of our impression is appropriate at this point. Possibly the project is suffering from bad press than no longer applies? Here's to hoping, anyway!
The whole gtk ecosystem smells off. I don't know why but projects that pick qt are by and large friendlier, better maintained and more successful.
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.
I get the impression that a lot of offers for contributing to the GIMP would be offers to bring the UI in line with Photoshop. I hope they're not instead scaring off potentially good contributors, because it's a lovely piece of software and there are a lot of buses out there for there to be only three developers.
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 :)
Yes, but the number one thing wrong with GIMP is that it is hard to use, "because Photoshop" is what everybody knows.
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)
I was about to say 'draw a shape with a toolbar button'... but after looking at historical Photoshop toolboxes, it doesn't appear to have had that feature either. :-) (Pixelmator, however, does...)
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.
IMO it's also the release model, which follows the even (stable) and odd (unstable) version numbers. When 2.10 was released there had been lots of unstable versions prior to that, but as they're marked unstable (and can be) distributions will never pick them up.
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).
Caveat: I have never looked at the source for the Gimp.
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.
This is definitely one of the bigger issues. Early on, GIMP adopted the Emacs development style of building a solid core of functionality in C combined with a REPL for a scripting language within which other features can be developed.
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.
> Unfortunately they picked Lua instead of developing their own language like Emacs did.
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"?
>Lua is pretty notorious for having an absolutely abysmal implementation and is very hacky itself.
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.
No it’s not. The reference Lua implementation is considered, quite correctly, to be a well written piece of cross platform C.
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.
For an 20+ year old desktop application written in C, GIMP has a a very good code-base. This is thanks to it always being a priority of the developers. The migration to GEGL for image processing and preparation for GTK+3 forced a lot of updates across the application (and was a lot of work).
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.
In professional creative software, you save to the project format (xcf in GIMP's case) and export (or render) to a "flat" format. Graphics, video, audio, it is roughly the same behaviour.
That's a good point. I understand the importance of having a default format that can preserve every bit of data Gimp is capable of creating. But it makes a lot of sense to have one dialog that can save in both formats, especially since the dialogs support choosing the format automatically based on the extension.
In professional creative software you're not using XCF. Maybe GIMP should change that too? Archaic UI changes to chase some ideal sort of user that doesn't current exist at the expense of your current users is not great.
Unfortunately there are no widely adopted open standards that seem suitable?
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.
> Unfortunately there are no widely adopted open standards that seem suitable?
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.
Or, you know, listen to your existing users. For all the bleating about professional features, they sure miss big ones like CMYK support.
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.
The number of times I've wanted to save as XCF in the last 21 years... has been zero.
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.
Anyone that says they need CMYK doesn’t understand printing. At all.
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.
Remarkably some professional(!) printers don't want to do late binding, instead telling clients to supply "CMYK PDFs" (color space? doesn't matter! Pick any CMYK!).
You realize that late binding means supplying the CMYK based on a conversion from RGB? Good.
> (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.
GEGL (Generic Graphics Library) is a data flow based image processing framework, providing floating point processing and non-destructive image processing capabilities
For those complaining about slow progress of the GIMP (I'm guilty as well) remember it's a part time project where most of the work is done by 3 people (from reading this post). One thing about "free" is that everybody wants it and almost nobody actually wants to DO it. I wonder how many projects that take donations actually do reasonably in terms of paying developers - I doubt it's very many.
User facing open source software projects do take a lot of time to make new progress or even just refine what's there. When the primary audience is non-technical users, that provides a lot of surface area for people to complain without a comparatively large set of users who would likely transition from using to contributing. From watching things over the years in the open source audio domain I agree that donations/other-funding-mechanisms are really hard to get right in this space.
You also have to account for the amount of work it once took, and the mindset that creates. It's another domain entirely as a result.
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.
Unless you count all Windows frameworks as just Windows that seems like a stretch.
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".
Yes and I'm referring to Win32, WinForms, WPF, UWP/WinUI, Cocoa and Qt are very likely more widely deployed. Though even the last place of the commonly used frameworks is still relatively widely used.
I'm unsure how blender is organized but they seem to compete with the proprietary competition on a much higher level. Does blender have so many more developers working on it than Gimp?
At some point in the last 5-8 years Blender went from being "the gimp of 3D" no one seemed to really want to use (like Gimp) given the alternatives to actually being a competitor. I'm not sure what happened but it's on the list of things to discuss if I ever sit down with an industry veteran in the modeling space...
What happened is Blender followed a linear development trajectory, constantly adding new features and fixing bugs at a reasonable pace. GIMP, on the other hand, adds a handful of features once every year and a half.
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.
What happened was the interface was insanely improved from the unnavigable mess of the early 2000's, sculpting was added, and a host of other features brought Blender to parity with its non-free brethren.
One thing which helps Blender is that its target audience is better equipped to write code, or at least think about code enough to connect with the "project" side of open source software.
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).
One of the things that happened is the Blender team hired a bunch of professional artists to make real commercial quality movies using blender, and when the artists had a complaint, the developers were in the same room to get the issue fixed in real time.
Meanwhile GIMP has a reputation of being written by software developers for software developers, and being actively hostile to suggestions from artists...
> Meanwhile GIMP has a reputation of being written by software developers for software developers, and being actively hostile to suggestions from artists...
TBH my anecdotes are probably somewhat out-of-date; last time I was looking into this was back when single-window mode was a controversial idea, being rejected for years, with users who requested it being told "it's not our fault that your window manager sucks, just switch to a window manager which handles multi-window mode elegantly" (which at the time excluded users of windows, osx, and most mainstream linux distros :P)
That was a turning point for us as well. We had a sprint at the blender institute in Amsterdam and had invited artists to come as well. And we sat down a whole Saturday, taping them while they were painting and complaining. Us developers, we weren't allowed to chat back, we were just there to look and listen. Very illuminating, and fun for the artists.
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.
I wonder if some of it has to do with the fact that you can get Photoshop for $10/month, whereas 3D programs are still super expensive. I used Blender well over a decade ago because I couldn't afford Maya or Max.
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.)
Blender has always been ran with a strong priority of being/becoming a software that is used by many professionals world-wide, and Ton Roosendaal has been there since day 1 to push for this. They have actively sought to find ways to hire many people to work on Blender - from code, documentation, management and outreach/marketing.
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.
Gimp is an interesting case study in the assumptions behind free software and the free market.
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.
I think 'barriers to entry' or might be a better term. Some barriers are quite natural/inherent (hard to pay devs in open-source), while others might have technical solutions (it used to be hard to package&deliver cross-platform desktop apps).
There has been plenty of forks of GIMP, but none really picked up steam. It has been forked over the name, over the UI not being close enough to Photoshop and over core features like high-bitdepth support.
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.
> There has been plenty of forks of GIMP, but none really picked up steam. It has been forked over the name, over the UI not being close enough to Photoshop and over core features like high-bitdepth support.
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.
It was just a tech demo for a conference, but yeah, the reception was not friendly, to say the least, along the lines of "How did you dare to hack on Gimp, doing this, without doing us the courtesy of asking for permission first!" I wasn't there, back then, but gosh, people were young! See https://marc.info/?l=gimp-developer&m=90221516927992&w=2
Indeed, probably not many. But one of those that seems like it is doing quite well and is in a similar space is Krita. They have a healthy number of contributors, fund developers, and are making good progress quickly on a powerful application that works very well and has a lot of polish.
They could have run Kickstarter campaign like Krita did. Surely it would allow to hire more people in the team. But seems they don't want that for some unknown reason.
You can make a campaign to hire full-time developers from the outside then. It is just less money available for personal donations rather using collective campaign for one organization. See Krita as an example.
> You can make a campaign to hire full-time developers from the outside then.
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.
I wonder how actually useful all these cool features without the most basic thing - updated toolkit. GTK+ 2 is being washed out of Linux distributions like Qt4 before.
I still think the name is a critical failure that inhibits adoption, though it's probably too late now to do anything. Look up about masks in The GIMP, for example ... https://www.google.com/search?q=gimp%20masks for me in a fresh private browser window this search brings up "fetishwear" sponsored links. The secondary meaning, the primary one from my childhood [en-gb native]: "gimp" would be like calling someone a "spastic".
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):
So words that are just close to other words that are deemed offensive should not be used? I'll avoid mentioning the well publicized political cases over the last decade or so and just ask, should we use the word "pluck"? Should those with the surname "Kuntz" or "Cockburn" have to change their name? Is the offense created by similar spelling or similar pronunciation, or both?
We're talking about marketing here, and if something leaves you with an odd feeling, it's no good 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.
We're taking about freely sharing things by name, if there's a chance my boss is going to fire me just for mentioning the name of your product then I'm going to just avoid recommending it.
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).
I’m not offended, just explaining why some might be. It’s amazing I got voted down for just making a statement explaining something that isn’t even my view.
And in the past in en-gb too, quite similar in gravity to "gimp" and "retard"; interestingly I'd completely missed that connection though; I think "monger" was the normal version in my high-school.
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.
115 comments
[ 2.4 ms ] story [ 166 ms ] threadI hope blender new release give people some ideas.
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.
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.
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.
http://gegl.org/babl/
babl is a dynamic, any to any, pixel format translation library
http://www.gegl.org
GEGL (Generic Graphics Library) is a data flow based image processing framework, providing floating point processing and non-destructive image processing capabilities
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://krita.org/en/
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.
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.