The one area where I'd say it needs improvement is the raw development. The output just isn't that great compared to Adobe Camera Raw or (my tool of choice) Capture One.

Many users don't know where or how or what to put in a bug report.

If some had a site that you could just write free-form prose others more experienced could convert that to actionable bug reports.

No, Photoshop has never had a good UI (neither has Illustrator).

The problem is that people who use Photoshop on a regular basis have memorised the keyboard shortcuts and steps needed to complete tasks. The Photoshop way of doing things, no matter how clunky or unintuitive, is now the natural way of doing things for them (and their frame of reference when trying out another app).

It's no different to a lot of other software e.g. the programmer who won't consider any other editor unless it has the same task flow and keyboard shortcuts they've spent so long committing to memory.

This puts rival apps in a difficult position. Should they copy the same clunky, unintuitive way of doing things to attract users? Or forge a different path? In the case of Photoshop, copying the UI and task flow means users can also take advantage of the gargantuan volume of existing Photoshop books, tutorials and training available.

The idea of an independant open source project focusing itself on producing a commercial quality UI seems a little ludicrous to me. This type of UI requires continued multi-disciplinary effort and process over a timeframe of years. And this is the exact weak spot of projects funded entirely/mostly on a volunteer/contribution basis.

This idea of a highly customizable toolkit (a la Emacs for graphics), in contrast, goes to the strengths of the open source model. Open source projects tend to be developer-heavy, and developers tend to like to build frameworks/abstractions... so a natural fit. Frameworks tend to be easier to use when the underlying code is available for various kinds of inspection, so the open source model fits there too. I'm not saying it'd necessarily be a cakewalk, but it seems like a closer fit to that OSS is really good at.

(Of course, frameworks are more complex and expensive to develop than single applications, so this idea has that going against it.)

Edit: or rather, create a SketchUp clone with good 2D projection/export (Blender isn't for casual use)

Someone as pragmatic as him, still working and taking/giving abuse at that "milemarker" of wealth? Huh.

The problem is that the current developer base of many FLOSS project don't understand that a) decent UI requires an expertise and b) knowing how their poor UIs are implemented doesn't count as expertise in UI development.

For example-- if I write to a FLOSS mailing list that the way they are using realloc leaves some stale pointers that can cause crashes, they very quickly fix the problem. But if a UI expert posts something about a similarly severe and easily fixed UI bug, they'll get at least 5 authoritative-sounding responses from people who know absolutely nothing about UI design.

Such a UI developer would definitely need a full-time salary to deal with that kind of social situation.

To it's credit, the project has, over that time, made some significant improvements to its UI. (Starting the GTK project to replace Lesstif/Motif and adding single-window mode come to mind immediately.)

The question is really this: what is the best way for the project to effectively use this contribution to improve it's product? Knowing what professional UX work costs, it's not surprising to me that they decided to direct this grant to supporting their existing developers and trying to bring in a few more with a Hackathon or two.

> gimp developers work on gimp because they like gimp

I'd say: GIMP has always been good enough for GIMP developers as its own world to explore--what is it, what can we make it become for the sake of GIMP. I remember the good old days (frankly I'm not sure if this still happens) when a mailing list suggestion like "look, Photoshop does X and GIMP sucks at X" would almost always result in a "hey, the source is open" comment from core devs. This drove some users absolutely crazy, because _if it was their project_, one of the core goals would be fitting the project to user expectations (probably rooted in Photoshop use-experiences) rather than setting a sort of psychological boundary around GIMP that is less permeable to that kind of encouragement to change for the sake of some externality like "a frustrated Photoshop pro" or "a mom who never knows where her toolbars go". There generally hasn't been a pressured response to that kind of pressure from the GIMP team except in slower, measured ways. This tells us that GIMP developers feel less pressure from that feedback (positive pressure or negative) than other developers on other projects might.

This kind of internally-protective outcome reminds me of a bumper sticker that I saw that said "Keep Portland Weird." I think there's a benefit to that line of thought. Maybe "Keep GIMP GIMP--while also working on meeting Photoshop-level expectations _whenever we feel like it_" is more representative. And this is completely separate from looking at GIMP as a low-quality project, or even a weird project. It's an awesome project _in its own way_ is what I'm saying. To understand it and its unique leverage points is to enjoy using GIMP.

> while blender developers work on blender to see what people can do with it

First, I don't know about individual developers, as this is more of a comment of "type and generality". But I think the project outcomes make it clear that Blender developers really enjoy the feeling of making a big impact in the world, and building bridges to the outside-of-Blender world, as opposed to more internal focus on bringing a special, unique thing into existence. (Every project will have a blend of both, but this is speaking in terms of project-type, where it helps to cast a project into one bucket or another in order to get at what makes them different.)

The former, a focus on the outside impact, results in something with which it's easy to objectively identify and praise, because it's more objectively "compatible" with more people and teams. A Maya team goes "we get this" partially because it works with them on a level. It crosses the objective barrier and works with people who prefer another set of keyboard shortcuts and window layouts. And so the Blender team gets more of that outside-in encouragement from a broader base, IMO.

And again, this doesn't make GIMP faulty, just different. The latter type of focus, the internal focus, asks "what do _we_ want to do, what interests _us_ as a team, what's next for _us_" and I believe that's always been a feature of GIMP's existence. When you understand GIMP you can talk to core developers. When you begin to push on it, and compare it to Photoshop, you become the problem much faster than you would in other communities, because you're not focused on what GIMP is. So the GIMP project might have this objective-world blind spot, as evidenced by a HN thread full of change requests :-) but it's a trade-off for a high level of internal, subjective quality which can be observed if you _look at GIMP for what it is_ and really figure it out. I mean, I use the software every day, and there are so many little things that make me miss it when I have to use something like PS.

> so they will not be able to spend this money effectively

Quite the opposite--I'm certain it will be spent effectively. No doubt about that at all.

What I'm saying is that it would probably not be realistic to hope that it is spent the exact same way that a Blender fan would really appreciate. And that's OK and even a good thing.

I'd put the (very fuzzy) estimate at something like 2 years of consistent (full time) effort from a team of, say, 5 people. That puts the cost of such a change closer to a million dollars.

I don't just mean technical inertia which is probably large given GIMP's size and long history, but also people inertia. UI tends to be the ultimate bikeshedding [1] blackhole. Few people have an opinion about how a denoising filter should be implemented. Several orders of magnitude more have feelings about the UI should look and the workflow should function.

[1] https://en.wikipedia.org/wiki/Law_of_triviality

I'd like to help contribute to some projects where I can lend a (non-development) hand, but being code-based projects, they don't feel set up to accept it.

GNOME in total last year only spent $110k on salaries with $300k in revenue (also they had $670k in the bank). Based on their past filings, they look pretty fiscally responsible.

Phase One's Capture One solves this by using "sessions" instead, which lets you keep any sort of workspace as a loose individual folder; with preset subfolders for raw files, output, trash, previews, etc. You still get the benefits of tagging and other bells and whistles of searchable libraries but with much easier grouping and portability.

While this really doesn't apply to casual editing, I think the performance benefits and flexibility of the session approach over LR's insistence on libraries cannot be overstated if your RAW files start to number in the thousands after a few months (event/wedding photographers, etc.).

It would help if you specify what you mean by library management. What it doesn't do, and is very clear, is handle things like renaming files. You are expected to have copied the files over to your hard drive and organized them into folders (in any way that you like).

Beyond that, it serves library management well enough. You import a folder, and it becomes a collection. You can tag it, do queries, etc. It works very well for me when I want to find all photos of, say, my cat - even though they are spread across many directories.

Why would you have to spend months to figure that out

A naive implementation might just have two buffers and a list of pixel changesets and no knowledge of how the changes were made. A more advanced implementation could track more information, work on a per layer basis, and support the recovery of vector text layers from rastered ones.

So I guess the answer is not by default, but it opens the door for it to be a thing.

Professionals will always go with a well-marketed and popular option and they don't care about paying 500-1000$ for an image editing program. They don't care (or know) about open source. But I expect better from HN crowd.

As for GIMP and its features, well, when Photoshop firdt mentioned about the new Content Aware feature, there was a collective orgasm, but GIMP had that feature (by sheer virtue of the scriptability and flexibility which is inherent in its design) in a script format at least a year or two before that.

I don't expect GIMP to win hearts of professionals and their shiny macbooks, but for a casual heavy job, GIMP is more than capable, and expect programmers to appreciate it for what the GIMP project has achieved. But all we get here is "but but Photoshop!"

What do you do instead? Are you using GIMP entirely through the scripting interface? How are you using a graphical image editor without looking at the user interface?

Wow, this is such a bold statement; do you have any evidence to support this? In my experience a very great majority of engineers use vim or emacs. In US, I've never been in a culture where emacs or vim is used by a minority. In my current work, which is a startup in Boston, everyone except 2 developers use emacs. I googled for evidence to support me, but I couldn't find any solid evidence neither supporting nor disputing me.

There are more Vim and Emacs users now than ever before, because there are now more computer programmers than ever before. There are just a lot more people that use other editors/IDEs. Just like there were more Visual Basic users than Emacs/Vim users in the 1990s. The Visual Basic/IDE people are irrelevant as far as Emacs/Vim/Unix/Free Software is concerned because they are unaware of what Free Software actually is (they do have a lot of misconceptions, ones that they really like to flame about on Internet forums), do not understand why they should ever contribute to Free Software, and even if they wanted to do so, they do not have the skills to contribute to Unix/Free Software. Just like all the Visual Basic chair warmers disappeared leaving behind their shitty cobbled-together software, so too will the current generation of people that do not have the capacity or interest to figure out Vim/Emacs/Unix, to be replaced by the next wave of popular garbage software. In another twenty years, more people than ever will still be using Vim/Emacs.

My impression is that Lightroom is really designed for you to go "all in" and let it organize everything.

If you live in SV it might be like $210k or something absurd.

Disallowing saving follows the principle of least surprise, because when an application reports a successful save, users would expect the application state they see to actually be saved.

There are web-based photoshop clones that offer better usability than GIMP. I shiver in disgust saying this out loud but it's true at this point. They're slow, more minimalist in terms of features but they don't have buttons that overlap or scroll bars popping up out of nowhere. The GIMP UI is an unusable mess. It's the UI equivalent of "programmer art".

Having just woken up, deprived of my morning caffeine, this sentence sent my brain for a real loop :)

It's not aesthetics. You make it sound trivial. People aren't talking about things like how the icons are designed. They mean the workflow.

This is the fatal error. Humans are the ones using that tool. What you call aesthetics is functionality.

We’re not talking about making it prettier we’re talking about making it more usable.

On top of that, it’s an image editing tool. It’s a tool that people use for the purpose of creating visual, often-times “aesthetic” works, and yet the UI is not important? Well then more humans making the decision to use it is not important.

In my opinion, GIMP is the evidence that these efforts are misplaced, and focus should be the UI (at least after core functionality exists). No point is a fancy pants program that nobody actually wants to use.

The Photoshop thing, on the other hand, on the rare occasions I am forced to venture there, strikes me as a confusing mess that I'm always happy to leave behind as soon as possible. Plus of course it requires one kind or another of strange proprietary OS in order to function.

When x is standard workflow for many of the other such programs (and things like word processors) and it isn't such in Gimp, that very thing drives people away. Most artists aren't going to care what the software engineers want in the program: Instead, they are going to care about things like this. When added up, it just makes for a frustrating experience. It doesn't really matter what the technicalities are if you are the artist.

Yes, you do lose some information depending on the format. Heck, I notice loss simply looking at an image on different screens. The fact is, though, that folks actually need to save in different formats. Sure, I keep my layers and information in tact while working, but folks also need to be able to share their work, print it, and things like that. For that sort of thing, you need the different formats. The exact format depends on what one is doing: PNG works for facebook and instagram. Some sites have file size limits, and with some printing you have a bit more leeway.

I'm not even a photoshop fan myself: I chose my software based on both if it was easily integrated with a Wacom pen display and how well it mimicked traditional artwork flow and styles. Hence my use of Corel. Photoshop is basically a renting program now, and I generally welcome alternatives. Gimp has always been somewhat frustrating because of little stuff like this.

As a user, I think about "saving" as a process to persist my work. If there might be technical fine-grained issues, show me a warning sign in the save dialog, but don't come up with a process that "makes me think".

Where do I start?

  - sometimes when I start it it doesn't display toolbox
  - when I open the toolbox it is (sometimes) a vertical line of buttons (single column) instead of 5 columns that I begged it countless times to be
  - setting the size of pencil is completely unintuitive - I usually click in what appears to be input field, only to discover it is not (but instead some meter that sets size to some huge number)
  - saving the set size is something that should be done automatically, but I haven't found a convenient way to do it

Note that I love Gimp and use it often, but UX is not its strong point.

Floating point pixel values should be supported as of GIMP 2.10, though.

It can:

1.) handle hyperspectral images

2.) handle images with 32-bit floating-point pixels

3.) handle gigantic images, streaming from disk as necessary

4.) record edits as a macro, which can be replayed on other images

Unfortunately, I'm not aware of, and a little searching didn't uncover, any capability for handling complex pixel values. This could be (poorly) implemented with 2-channel images and some user macros for specially manipulating them.

[0] https://imagej.net/Welcome

[1] http://fiji.sc/

Googling "complex-valued pixels" didn't bring up anything, but I'm interested in finding out more about that. What pixel-related information do the real/imaginary parts represent? What sort of applications does that have?

Their window/toolbox system sucks though. I have a hard time placing all windows where they need to be and even opening some of them. It's probably my biggest complaint right now.

Everything is counterintutive, starting from shortcuts, to menus, etc. etc., and since it's GTK2 it looks minuscule on hidpi screens.

I did the search, found lots of stuff readily available, shared my exact search phrase so it could be replicated and explained my reasoning for sharing the search phrase instead of a link. And now two people are busting my chops for actually being helpful.

I bet no one would have said a damn thing had I simply not bothered to reply and, in this case, not bothering to reply would have been the jerk thing to do because it would have been unhelpful to someone actually sincerely needing help and it would have been done on a bad faith assumption.

Geez.