Hacker News Reader

GIMP had some very serious progress lately (v 2.8) . I found myself using the Cage tool a lot, for example, and the new brush size selector is quite nice. As for the 8 bit stuff - you do know that they are transitioning to babl and GEGL, right?

I don't know much about those highly qualified graphics programmers - but every good project has a pace and a development plan - GIMP definitely has a roadmap in place, that can't and shouldn't be turned 180 degrees everytime someone comes with an idea; and I've seen quite a few people who see the rigors and the standards set in place as "abrasiveness"

Could you point us to some mailing list messages that would support the claim though? I don't follow the mailing list closely, mainly the news announcements.

> transitioning to babl and GEGL

The Gimp has been 'transitioning to GEGL' for how many years now? Something like six or seven years. And getting the data structures in place is only part of the challenge. How fast is this going to be for users? If the speed is to slow for users to efficiently get there work done at an intuitive pace then you have still failed.

From the initial GEGL integration attempts I saw the whole thing was hacked together with no clear thought to performance. And the performance was indeed quite abysmal.

GEGL supports acceleration via OpenCL, so it's unfair to claim they haven't thought of performance at all. And AFAIK most plugins are already ported to GEGL, and the core seems to be done. I do agree that it took a lot of time, but I find it surprising that the project made any progress at all - whitout a few developers hired full time, aren't we too entitled to ask for such advanced features, and have them shipped quick as well?

There are very few sustainable free/open source projects, which have corporate or some other kind of backing - GNOME (redhat), Linux (linux foundation) and Blender (blender institute) are the only one that come to my mind.

> aren't we too entitled to ask for such advanced features, and have them shipped quick as well?

It would be unreasonable to expect from unpaid volunteers if they has no ambition to do such work. Which is why I suggest that if you want to see advanced features and professional quality graphics software with a predictable cycle of development then you support the projects that actually try to create such programs.

Krita has a regular development cycle, a clear set of priorities and goals and funded development efforts that clearly lays out what features and improvement are going to be achieved with your hard earned money.

That has been an ENORMOUSLY successful improvement for both the programmers who can now get paid to work on there projects and the artists that now get quality continuously updated graphics software.

If Gimp or any other project deserve funding they have to step up and show the discipline and commitment to there project that successful projects like Krita have. I do not see that at this time so my recommendation is to support the projects that I listed in the OP.

> edit

As far as performance is concerned OpenCL or Cuda is not going to save you if your cpu bound memory architecture is not carefully thought for performance. This has always been a major problem for gimp for a long time. The higher bit depth and resolutions that are used now only exacerbate the situation. A general use case now could easily have tens of gigabytes worth of data that the user wants to manipulate delete and expand in real time. I have never seen this addressed in a serious proposal.

So because GIMP doesn't solve ALL of its problems it deserves nothing? I find this unreasonable. So it's not perfect - no software is - but it's very, very useful, and still deserves support from those who utilize and appreciate it.

btw: I do love Krita, and I'm not saying they deserve any less support in favor of GIMP, but Krita is a lousy choice for certain image-editing routines where GIMP excels. Krita much more tailored towards artists, and I'd rather it stay that way.

Backing helps but that's not the root cause of the project's problems.

The project has /always/ been unfriendly and abrasive. There's a reason why there aren't many contributors--the core team drove most of them away. I was a contributor in the early 2000s as a maintainer of the Print plugin (now gutenprint). I distanced myself from contributing because it was so painful and unpleasant. Same for GTK+. I went and worked on other stuff.

The other reason is technical. Why is the transition taking so long? Because the codebase is written in GObject-based C, and writing and refactoring this stuff is a nightmare. This also puts of a lot of potential contributors, and for good reason. Were it written in C++ or something else more amenable to ongoing maintenance and refactoring, it would have been possible to get this done much more quickly, and it would also have a vastly lower barrier to entry for potential contributors.

Moving to Qt is definitely possible; I've done it for other GTK+ projects. It can even be done incrementally; you could move the whole lot to use GTKmm widget by widget, and then once it's all C++ you can start the move to another toolkit. I'm not saying this because of any sort of Qt vs GTK+ zealotry, but rather because GObject-based C is inappropriate for sizeable codebases; the ability to maintain and refactor and contribute to a codebase matters, and this impedes all of them. Looking at the glacial progress of GIMP and other big GTK+ applications, as well as the bugs it causes, demonstrates this repeatedly. Plenty of other projects made the move and didn't look back, because once done it's vastly more productive to work with a C++ codebase, and with a significant increase in code quality. It's not 1997 any more.

The alternatives you suggest aren't GIMP replacements. I am into photography and, for better or worse, only GIMP provides tools for photographers and is an alternative to photoshop. Since Krita and Blender seem to be at a better funding position than GIMP, it only makes sense to donate to it.

Note: I've donated to Krita, GIMP, digiKam and other software, animation projects and libregraphics meetings in the past.

> The Gimp project has been quite abrasive to the graphics research and software development communities for many years. The Gimp team 'knows better' then the highly qualified and experienced graphics programmers who offered to help the project bring there code base into the current standards for graphics.

Unfortunately groups of humans act that way sometimes. Wouldn't it make sense for the more qualified and experienced graphics programmers to simply fork it and make their own better product?

More experienced graphics programmers have careers working on commercial DCC(digital content creation) applications, Animation/Game studios, Academic positions or some other graphics related position.

A lot of people would like to work on a established project rather then bootstrap a new one. And many could not do that anyways because of NDA terms.

The climate is getting better but only because there is a new crop of applications that sprung up in the last few years that has more interest and understanding of who the graphics community is and how it works. And seems more interested in contributions by people who have highly specialized and deep expertise in graphics.

My general sense is that it has been more fruitful for people to work on specific projects privately or in there professional environment that solve there problems and then release those projects as OSS. Rather then try to wrangle the politics and project structure of some of the older established open source software.

Or maybe just help funding Gimp as its the only software i actually use. Next to many other people i know.

Can you comment on the substantial redesign of the GIMP that will be in the next major version?

I would not give a critique unless I did a thorough review of the current incarnation of re-architecture with some benchmarks on stressful average work flow that could be expected from a computer graphics artist or painter.

I will say that the Gimp 'core rewrite' has been a project in development since the early 2000's. I have never seen a clear design document explaining what this new core is suppose to achieve and for what uses Gimp expects to be used by professional level Artists workflows.

The last development that I was paying attention to was the decision to switch to GEGL for there core compositing and pixel engine. But it looked like it would simply be easier and probably better to start from scratch and build an entirely new software build around a 32bit image architecture rather then try and retrofit there 8bit custom build compositing system.

I will also note that they decided to invest there limited resources into upgrading the gui from GTK2 to GTK3 rather then focus that energy on the core. That shows rather skewed priority focus for a software that has some serious issues.

Thanks for your reply. You present some interesting points.

* Project management.

* Goal/benchmark definition.

* Human resource allocation.

I can't decide if what you say is truly so. One thing that I know, though, is that the old GIMP has been very useful to me for editing images (nothing fancy). I'm not an artist/painter but if I were, I'd start that with Krita instead of GIMP. In my mind, GIMP is more of a toolbox for doing the boring stuff like cropping/converting/annotating/correcting some random images and saving them in various formats. Gaining proper color management would be a good thing in my opinion, even if everything else stayed the same.

If Gimp works for you then use it. But I think you will find that even for simple image manipulation Krita is a faster easier to use editor at this point.

My concern is with Professional quality tools for artists. These tools already exist on Linux but they are predominately closed source. If Linux and OSS is going to be an option for Artists then the tools have to meet the same high quality standards that other professions that use Linux expect. But in graphics this is not the case and has not been the case for many years.

The best way to encourage the momentum for better tools is to support those projects that take the quality of there software seriously and have some urgency. The projects I have mentioned previously have demonstrated that they have that focus.

There's one artist that uses FLOSS to draw and make a living out of it, David Revoy.

He's using Krita as his main painting tool, but: "Gcolor2 is a colorpicker, Inkscape my favorite vector editor, Gimp for manipulating images and Shutter for taking advanced screenshots."

https://www.davidrevoy.com/article316/ubuntu-16-04-for-my-di...

I don't see why we shouldn't support the development of both programs. I personally like GIMP better, maybe just because I'm used with the interface, and I don't do paintings, only image manipulations.

I'm simply offering my opinion. If you want to donate to Gimp developers thats your choice.

Krita has a very refined process for development donations. They collect donations through a Professional funding site not a personal Patreon account and there is a clear time frame for development and a clear set of features that will be 'Finished' at the end of the development cycle.

They have successfully delivered with this model and the people who gave them money got what they paid for and will more then likely fund them again and other projects.

Can you say the same for gimp? No, someone might give some money to a Gimp developers Patreon making all sorts of promises that never get finished. The person who gave that money will probably never contribute again.

Thats a big problem for every OSS graphics project now. We have to give people who are willing to put down the money what they expected to get or they will stop funding.

Its important that the most professional, serious projects get promoted and funded to serve as a model for other projects to follow. And to grow the amount of users that feel comfortable giving there money.

You can see the same sort of professionalism with Blender and Natron development. And they also are producing quality software. If the project is fallowing this professional model then they deserve to be promoted IMO. But simply putting a bunch of promises on a personal Patreon and asking for money will do more harm then good to the larger OSS graphics community.

> someone might give some money to a Gimp developers Patreon making all sorts of promises that never get finished

https://git.gnome.org/browse/gimp/log/?qt=author&q=pippin

https://git.gnome.org/browse/gimp/log/?h=pippin%2Flinear-is-...

https://git.gnome.org/browse/gegl/log/?qt=author&q=pippin

https://git.gnome.org/browse/babl/log/?qt=author&q=pippin

Commits speak louder than baseless accusations.

http://wiki.gimp.org/wiki/Roadmap

I don't see the port to GTK3 as being such high priority. It's not even on the roadmap to 2.10; The roadmap seem sane to me.

I don't think the program was intented specifically for painters, but it did include the MyPaint brush engine. And I find the program easier to use with every new version.

http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_visio...

The only thing I can truly complain is the slow speed at which the versions are being released - but then again - the program never crashed on me - which speaks of the high quality of the code behind it - and quality takes time. I think the blame for the speed lies in the lack of developers resources.

But this time I can address this issue: I commited $8/month, and I'm promoting the campaign heavily.

Well, generic_user here makes here a typical mistake of thinking that performance is the topmost priority during development. Whereas the usual development pattern is "write first, optimize later".

Also, thank you for your support. We do appreciate it!

I can't believe you're saying this. Quality and performance must be the topmost priorities in any graphics application. That's something you have to design your architecture around, not a thing you can optimize later. Poor performance and poor quality are no gos for any artist serious about work. Having an application that is too slow to be used or mangles the quality of your work is as bad as not working at all. Actually, you can't say it works if it can't provide a reasonable performance to get the job done! How can performance not be a priority?

It's not that performance it's not a priority, it's just that it you can achieve it later by optimizations. "Premature optimization is the root of all evil" said once a wise man (was it Dijkstra?);

Anyway, GIMP is getting faster - with 2.9 you can already use GPU accelerated operations and plugins, if that is your concern.

What you don't want is a program that crashes all the time, or one that is so convoluted (because "performance"), that nobody is able to develop it further, since nobody can wrap his head around of all the implication of a modification.

No, it's not about premature optimization but designing towards performance. It's always a balancing act but the earlier you make the right choices the better. There are mandatory questions during the design process, before writing a single line of code. "Is it going to be fast enough?" is one of them and you can't answer it by saying "I'll figure out how to optimize it later" or "computer power will eventually catch up".

Oh, and btw. Stop using the "GPU accelerated" argument as it was a silver bullet. GPU is not a crutch to make slow operations barely usable, it should be used as an extra performance boost for operations that already work.

> No, it's not about premature optimization but designing towards performance.

So we, in fact, completely agree.

GPU is quite the silver bullet, IMHO. It's a chip specifically designed for graphics, it's a Graphical Processing Unit. You can't expect the performance of a general purpose unit to be even anywhere close.

There are cases where coding for performance from the get-go is the way to go - think the_silver_searcher vs ack; there are cases where "computer power will eventually catch up" - the GNU coreutils did just that, they where coded for a system where a large amount of RAM was available(even if at the moment, in the '70's it wasn't), and removed many limitation that the proprietary tools had at those times.

But in a large program, that aims to grow even larger as features add up, performance is not your primary concern. If you have good abstractions, and you optimize at pixel conversion layer by 50% (say babl), all those optimization will add up. If you write your code in assembler, for speed's sake, you'll never surpass the complexity of MS Paint.

I worked on a web application that was a bit over 100k lines of code (at least the subsystems I had access to) - some bad architetural decisions made progress stall, and features were delayed by as much as half a year. Every change at deeper levels broke all kind of things at the UI level. Those were some shitty days, trust me.

> I would not give a critique unless I did a thorough review

But you made up an argument about driving off experienced developers. So what's actually stopping you from making more stuff up?

> I will say that the Gimp 'core rewrite' has been a project in development since the early 2000's.

Nope. It started around 2006 at small steps.

> I have never seen a clear design document explaining what this new core is suppose to achieve

So you've never visited gegl.org?

> and for what uses Gimp expects to be used by professional level Artists workflows.

So you've never visited gui.gimp.org?

> I will also note that they decided to invest there limited resources into upgrading the gui from GTK2 to GTK3 rather then focus that energy on the core.

Wrong. 2.10 is all about rewriting the core. We need GTK+3, because GTK+2 has tablet support is broken on Windows.

> The Gimp team 'knows better' then the highly qualified and experienced graphics programmers who offered to help the project bring there code base into the current standards for graphics.

Name one such programmer.

> Any further development of Gimp will more then likely be an upgrade to the latest version of the GTK+ toolkit slapped on top of the same outdated 8bit early 1990's architecture

8bit has been gone since 2012. Wake up and smells the floats :)