Leaving this here for Photoshop converts
https://github.com/Diolinux/Photogimp
I use Affinity full time at the moment, but if they ever go paid, I’m running straight to GIMP.
i completely switched to Affinity suit some 3 years ago at work. I was so excited when the affinity4linux install script dropped. but performance makes it near useless. slow and stuttering.
here is for hoping gimp and inkscape can one day match.
We <3 GIMP
The page 404s
What is the upgrade?
Logo change!
I think that’s the new page : https://testing.gimp.org/news/2026/08/16/dev-update-august-2026/
@Hadriscus @phoenixz Just FYI, that’s from our testing page (note the subdomain), so it’ll give you a 404 again once we push it from drafts to the live site.
ah, the whole thing’s a draft. I understand now
I’ve recently tried using GIMP again and, as a past detractor, I’ve gotta say it’s improved significantly.
exactly. i’ve used photoshop professionally and tried gimp then.
gimp is not quite there yet, but the potential can now be seen.
Not to down on them too much but this comment is kind of funny in the context of a 30 year old program.
if you think about it, phones are where the “new” programs actually are.
Honestly so much better when they moved away from the “everything is a floating window” interface. I can find stuff now.
Related to that, Jacob Boerema has implemented PSD Descriptor import support. Most of our current PSD support has been based on the the public Adobe specification. This document was last updated in 2019 however, and modern PSDs use a relatively undocumented text format called Descriptors to store many features.
The battle tested strategy of only providing old standards to others, like MS does.
GIMP is shaping up to be (and actually already is IMO) the best editor out there for nondestructive work.
Does the UX still suck though?
First thing I always do is set icon scheme to have colors. I don’t know who thought monochrome for the tools was a good idea, but it takes me twice as long to find anything.
Nope. You just made the mistake of learning something else first and expecting other tools to match it
Expecting it to be the exact same and working in an expected way are different. Blender used to select with RMB instead of LMB like every other program in existence, is it really the users fault for finding that stupid?
Following expectations and having a “smooth” workflow is something to aim for unless the standard is really bad. No need to fix what ain’t broken
I mean, sort of? I picked up Affinity Photo from Photoshop pretty quick because the UX isn’t crap.
Again, no, because Affinity is more similar to photoshop.
What exactly, is the “crap” part of gimps UX? I never had an issue with it.
Then again I really liked it when all the elements are not in the same space, it is very similar to high production work using multi monitors and having the actual canvas the focus.
This is me with all CAD software 😭
My way into CAD software was 1. Dealing with DXF editors like QCAD. 2. Trying to tackle parametric CAD, I ran Onshape’s tutorials, they have pretty good technique tutorials, like how to draft a paperclip, that are applicable to most parametric CAD packages. Then learning how FreeCAD’s spreadsheet works.
FreeCAD has a full-on spreadsheet built in, now it’s feature poor compared to Excel or LOCalc but you can store and calculate dimensions there and then use them in the main drawing. Other software has features that accomplish this but it’s not as flexible and familiar as a spreadsheet. FreeCAD has some usability issues but everything else out there is either drawbackware or subscription.
This is true of pretty much all software. So many people expect to be able to pick up LibreOffice office and use it like they use MS office and then get immediately irritated the button doesn’t look exactly the same and give up.
Yeah butlike, I am using Calc, and I use the arrows, and it just, moves the view instead of which cell is selected, which feels really backwards.
I don’t recall that to be normal.
I had to check because that sounded crazy. So maybe your scroll lock key is on? If so Excel does the same thing.
I got irritated by the differences, but I was more irritated by Microslop, so it was the lesser of two irritants. I mostly figured it out eventually. Finding H2 is always at the bottom of the entire style list though for some fucking reason like there’s no excuse for that kind of mild irritation
You could always move it and submit a pull request. That is one of the beauties of open source!
Y’know what maybe I will. Fuelled by the power of irritation I’ll try and fix it. If anyone’s reading this in a few months and the header tags are in a logical order; you’re welcome
you’re right, but i need people to understand that this is simply not a workable solution for most people. the simple fact is if we want the average person to adopt more open source alternatives, it needs to improve usability even without their help. it’s not really enough to only cater to us power user nerds with “good enough,” and it doesn’t win hearts and minds to handwave complaints and tell people to come back with a patch.
We are talking about software built by, in many cases, volunteers. The only way it will get better, or good enough for the average person, is if those who can help do so. The only real alternative in practice is open source the way IBM, Google, and Oracle do it, and they wouldn’t do that anyway if the volunteers didn’t exist.
I remember a guy telling me back in 2015 or so that Gimp was designed for having 2 monitors. At first I tought it made no sense but some yers after I got the chance to try and it way more comfortable to put all toollboxes in a separate monitor.
which part do you dislike? maybe because it fits my mental model very well, but i find the ui to be very intuitive overall. keyboard shortcuts are also pretty simple…
and there’s some user made config that makes its ui and keybinds work like adobe photoshop if thats what youre used to
Very interesting, thanks for the update.
edit: I also love how the article credits every individual contributor for the new features they made, a very nice way to celebrate the group effort
For the file format, would have been JSON instead XML not the better format? Its lighter and easier to parse and write, meaning more performant than XML.
I found a Stack Overflow thread where people discuss this and actually test it. Further down the page is a 2026 test. The results are it’s basically the same, very little practical difference in normal usage. If you’re auto saving a file every 30 seconds you will not notice any difference between XML and JSON.
Personally, I like XML more for data files like this. I would not reach for JSON as my first thought for deserealizing a complex object hierarchy. Stuff like, a polygon can have a drawing of type vector which can have n paths which each have exactly 2 points… easy to store and validate in XML. Quite messy and complicated in JSON.
<Drawing type="polygon"> <Line color="#fed1aa"> <Point x="6" y="7" /> <Point x="69" y="420" /> </Line> </Drawing>IMHO: XML is superior as a document storage format. JSON is superior as a data transfer format.
XML is not really superior to JSON as an image editing file format. EDIT: XML is better, if you want to keep a readable source format with markup. But that is not what a format for an image editing tool like GIMP should be needed for in my opinion.
No, they are both not really suitable for that. But I don’t see where the link in the OP implies they plan to store binary image data in XML, they’re probably going to store that in a binary format and use XML to describe relationships and other metadata.
@schnurrito @thingsiplay Yes, the XML is for file structure descriptions not binary data.
The GEGL buffers we use for image data in GIMP can be synced across files, so this new format will allow us to quickly auto-save the image/layer/etc to file as you make edits. Still in-progress work, but it’s really cool.
I’m gunna disagree with you XML comes with validators and versioning as part of the XML spec. You can validate XML files against XSD descriptors that can be published and even referenced by the XML file.
The only downside of XML over json is that XML is verbose AF.
Strict validators, versioning, checking, and definitions is EXACTLY what you want in a storage format.
ODF is also XML. It makes sense here.
More information for you: https://en.wikipedia.org/wiki/XML_Schema_(W3C)
JSON comes with builtin data formats that XML lacks, that’s why you have such overhead with additional validation. Everything in XML is treated as strings, and there are lot of stuff like entities that is totally unneeded for a file format like in GIMP. XML Schema is needed because the format is extremely complicated unlike JSON, if you have no other validation. GIMP itself has validation builtin already.
You have it mostly backwards. XML has like 40+ types that are all standardized. JSON only has the basic JS types. XML is a superset of JSON when it comes to types.
How would you represent a double float, or binary data, or a datatime in JSON. You would have to use strings in JSON. In XML you would use the xsd:double, xsd:binary, and xsd:dateTime.
JSON only works if you think in JavaScript. For languages with more complete / complex data systems it does not do unless you resort to the string thing.
For your information:
Easier to read: https://www.ibm.com/docs/en/jfsm/1.1.2.1?topic=queries-xsd-data-types
The official spec: https://www.w3.org/TR/xmlschema-2/
As for validation I think “right tool for the right job” is the best approach here. How do you know your validator is validating correctly? That’s the beauty of XML. Validation is part of the spec. XML is more complicated, but only because it’s more capable than json. Just like protobuf is more complicated than JSON. It’s also more complicated and not centered on JSON types.
JSON items don’t have attributes, which sometimes makes queries outside of a specific path or across domains difficult or impossible.
“But if you take the time to design your objects correctly…”
Or they could just choose the format that already does what is needed instead of worrying about building and maintaining serialization layers to shoehorn in a functionality that they could get for free by picking the correct format in the first place.
Also why are we having this argument? XML isn’t going away, REST already beat SOAP, and JSON is harder to read. Compressed XML is only about 10% larger than compressed JSON, and we’re talking about the metadata of a layered image file so that’s like 16kb vs 15kb.
As explained, its not about the compressed size only. I am talking about uncompressed data that is live patched.
Performance doesn’t matter unless you are dealing with gigabytes of xml. And ease of parsing/writing is irrelevant when it’s done under the hood by the program.
Performance matters a lot, because program can autosave in quick sessions after simple steps. Even more important if multiple images are edited or loaded. While this is not the biggest improvement, it is still something to keep in mind. Performance should always be a priority. Programs will keep expanding and add bloat over time, so its good to have a format like that in mind.
You should always measure first before blindly following dogmas. I doubt that the choice of serialization format is what dominates processor time in this case.
You should always measure first before blindly following dogmas.
Then you follow it by doubting it without measuring:
I doubt that the choice of serialization format is what dominates processor time in this case.
Also note I was not just speaking of today, but with future additions and changes. You can’t measure the future, but you can plan ahead and build upon a good foundation, that the small format can be used for extending it in future. That’s the idea. Also to test what you suggest they have to build the entire system years and waste lot of time and effort.
Are they going to upgrade the name as well?
Yeah I think they’re going for something more straightforward that describes exactly what it’s about
Brushes, Design, Shapes & Multimedia
To avoid confusion: BDSM, the FOSS formerly known as GIMP
I would not feel comfortable looking this up on a work computer.
Did you feel comfortable searching to learn how to use GIMP?
Or: Graphics, Images, Media & Print
Or else it will be a sub-module.
This would really mess up search results
Yeah, now I’m just gonna get screenshots of this app.
That would produce so many priceless weirded out faces when you tell someone you love GIMP and use that acronym and they don’t know what you are referring to.
nice one
gimp /gĭmp/
noun
A narrow flat braid or rounded cord of fabric used for trimming.
A limp or a limping gait.
A person who limps.I suppose the association with limping is a bit unfortunate. Although GIMP is an acronym.
The fact that a particular sub-culture has its own slang meaning for the word is irrelevant.
Why should they change the name just for the vanity of Americans who have a dual meaning for the word, and make it difficult for the whole rest of the world to find tutorials and documentation going back decades?
Don’t be silly. There’s no better name than GIMP.
Green Is My Pepper!
That’s a US defaultism issue
Why? It describes succinctly what the app does.
Is anyone interested in having GIMP with another name doing the work to make that happen?
There was a fork some time ago with that intention, but I think they ended up ceasing the project
GYMP? 💪✨🤭
