Gimp 2.10.32 on Apple Silicon (2022)
gimp.orgI hadn’t touched Gimp in five years or more but last month I had to slice up some large images for easier printing and Gimp rescued the project. I found it easy to use, mostly intuitive, the install was easy, the UI was snappy, and all of the features I needed were available. I have to give a big thanks to their dev team for providing this software and saving me from the Adobe nightmare.
I have been a loyal Gimp user since early days. I never found the MacOS experience to match that of the Linux or Windows environments.
Pixelmator has been a suitable and far superior replacement. It might not be Photoshop level capabilities but it more than covers my requirements.
I just use photopea in the browser these days. It's pretty much exactly Photoshop, at least for my non-advanced purposes.
Affinity tools are great.
Totally agreed. Specifically, I can never get the “ants” that should show up when you select something. It’s an ongoing bug that was just never fixed. So I just have to remember that a thing is selected. Quite irritating.
I've had the ants working in my install since 2.10.28
Just updated and it seems to be fixed. I wish I could amend my complaint.
The "ants" got fixed sometime in the past few months, I believe, and thank goodness: it really did make GIMP almost impossible to use for anything complicated enough to need GIMP. (But they've been working on my M1 Mac for a while now.)
This is my experience entirely.
I've been using GIMP for most of my life, but a lot of little things are off on Macs. My GIMP experience translates nicely to Pixelmator
I'm still waiting for GIMP 3. At this rate I'm not convinced it'll ever come out. GIMP kinda looks like a discontinued project these days.
FWIW, the Intel version has always worked okay (well, as okay as GIMP can feel) on Apple Silicon. It's blurry and low res and old-feeling, but compiling for ARM can't fix that.
In 2016, I identified and wrote about the lack of retina support for Gimp here https://artplusmarketing.com/gimp-and-inkscape-on-retina-mac... . I know Inkscape got retina support since then, but as I understood it, Gimp was waiting for better Mac GTK support or something. Does anyone know if Gimp has fixed the retina issues I wrote about years ago yet?
You'll want GIMP 3.0 which updates the app to GTK 3. 2.10 still uses GTK 2.
Meanwhile GIMP 3 is progressing[1] slowly but steadily.
[1] https://gitlab.gnome.org/GNOME/gimp/-/milestones/3#tab-issue...
I wonder why Gimp doesn't get more backing like Blender to increase the pace of development. Not enough interest from big backers? Surely many would benefit from dumping Adobe if alternatives could be on par.
Its internal dev-people world is different and doesn't take direct critique as opportunity (or compliment e.g. I want to contribute with my better-outcome-vision) in the same way some other projects do.
Not good or bad (unless you love one way more), more like comparatively differing in that way
Just comparing to how fast some projects like OBS evolve for example both in features and ease of use, Gimp feels very slow and unfortunately not focused on usability.
Krita kind of leads the pack in the "FOSS image editing development fund" category with 17k/month. It's not the same primary use case but there is enough overlap in what it can do that I'd say GIMP is neither in the lead enough or differentiated enough to garner significant support easily.
Krita is indeed pretty popular for artists at least and yeah, there is an overlap. But still, Blender seems to have way more massive backing in general.
I think the difference is the amount of competition. Blender's alternative is Autodesk. Meanwhile there are plenty of alternatives to Gimp as seen in these comments.
There are lots and lots of alternatives, and gimp is worse than every single one of those.
I love that this project provides a torrent download. Nice and fast for me and I feel like I'm less of a burden on their mirrors.
agreed. it downloaded faster than it took to 'install' the full version to 'applications' folder. leaving a seed running for a while to help out...
It also runs on VisionFive 2 (RISC-V proper), for what it's worth.
Why is the Gimp website so useless. I wanted to see if they still have the strange UI with floating windows but couldn't find a screenshot of the actual software on the site.
The strange UI is GTK and it hasn't been floating windows but instead a MDI (single window for controls and images in tabs) for over a decade.
You can find screenshots on the tutorial pages: https://www.gimp.org/tutorials/
To be fair, it probably has been a decade since I used it. I used it / tried to use it in my teens.
Hasn’t used floating windows by default for like 15 years.
You can run GIMP in either single window or multiple windows mode, there is a setting in the "Windows" menu that switched between the two. The multiple windows mode is the default and IMO works better if you are using a window maanager with a virtual desktop dedicated to it (or graphics apps in general). In my Window Maker-based setup i have a virtual desktop for graphics apps and i have it configured to always place GIMP windows in that virtual desktop. The main thing i'd like is being able to preserve the tear-off menus across launches (GIMP remembers the various window locations but always closes any persistent menu windows).
You can still use multiple windows, but it hasn't been the default for a long time.
Isn't it? I probably just changed it and forgot about it then. Either way, it takes a couple of seconds to switch.
Why not offer this as a universal binary? Seems like a bunch of extra work to generate two separate DMGs and try to point users to the right one...
Regardless, congrats to the team! Though, I'll note this blog post is from almost 6 weeks ago now.
If the GIMP team's experience is anything like ours (Wireshark), it's because a significant percentage of your dependencies are pathologically blind to the concept of fat binaries, so you'd end up having to do the grunt work of supporting fat binaries in both your application and your dependencies. It's a lot easier to just add a CI builder for each architecture and ship separate packages.
GIMP is already a pretty big download (~240MB), so saving users another significant fraction of that is nice. Also helps keep their mirrors' costs down.
I actually appreciate not having universal binaries. I almost always prefer to have a smaller footprint and the current app for arm64 is 874.4 MB according to Finder.
Along with the other answers here, using a newer Xcode and macOS SDK in order to build for M1 can limit compatibility with old macOS (OS X) versions.
hmm as a user I really don't like downloading binaries that are almost twice the size needed and of which I won't use half of
Mac users are well adjusted to having to pick the correct binary by now and the consequences of getting it wrong are fairly minor.
I'm not affiliated with Gimp and don't know why they didn't support fat binaries in the end; but I did look into compiling Gimp as a Universal Binary on my own at one point. My experience matches those of another comment, which is that not all dependencies supported compiling to fat binaries (i.e. you couldn't just add a bunch of flags and get a fat binary at the end). The only solution I thought of was to compile for both platforms and then lipo all the built files. The main problem is I couldn't figure out a strategy to do this without making the build scripts into a gigantic mess.
I wouldn't be surprised to find they're using a build tool chain that can't produce a universal build ... I've run into that before ...
Recent and related:
GIMP Turns 27 - https://news.ycombinator.com/item?id=33808435 - Nov 2022 (291 comments)
I know a lot of people like to bash on the Gimp and complain about features it's been missing for years (I might have even done some of the complaining myself!) but I really appreciate the work they're putting into it. This kind of low-level work with an ancient codebase can be pretty nontrivial and thankless work. Thanks, Gimp team!
What's so hard about porting to a new hardware arch? Why would building for ARM Macs be any different than x86? Unless you have assembly code it's just a matter of changing a compiler flag, isn't it?
A couple of issues that came up for me when porting from x86 to ARM recently:
1. The x86 architecture gives programmers a lot of memory ordering guarantees, so that communication of values between threads does not usually need memory fences. ARM64 does not give so many guarantees, meaning that multi-threaded code may need additional memory fences to avoid data races. But data races due to out-of-order memory updates are hard to diagnose.
2. Page size in macOS is 4 kB on x86, but 16 kB on ARM, so if someone has hard-coded the page size rather than calling sysconf(_SC_PAGESIZE) this may need to be discovered and fixed.
Probably comes down to either inline assembly or dependencies, or both.
Yup, I don't know if Gimp does it, but speeding up image filters is basically the perfect scenario where inline assembly can have huge payoffs.
These days, compiler intrinsics are typically the best approach to that stuff. Mostly.
Linux builds of GIMP already ran on arm64, as well as a number of even weirder architectures (like mips or s390x).
Aside from the points in the other comment, it takes time to change the build/test/release process for a new architecture. In some codebases it's a matter of adding a line to a Makefile, in others it's writing hundreds of lines of Bazel and a new CI pipeline.
Getting a Silicon build of Gimp wasn't actually that difficult. I know at least one other person besides myself that had gotten a build working from source and published how to do it in some form. The problem is that the CI system Gimp used for the Mac build did not have ARM runners, yet. This meant that to produce the production build required cross-compiling from an Intel Mac. While I'm sure it's possible to accomplish this, it was quite tedious and I gave up. As an example, one problem was that the Gimp build process builds tools that need to be run on the system doing the build and just splitting out those parts from the parts that need to be compiled for the target system was tedious.
A recent change in Ardour that used int128_t did not break on ARM nor did it break on unoptimized x86_64 builds, but did break on optimized x86_64 builds. That's just one example of the sort of platform-specific madness that may need to be faced and chased down.
Just providing a link to stackoverflow discussion that seems to relate to this, as I was curious about the details. Looks like it was undefined behavior relating to casting pointers.
https://stackoverflow.com/questions/62738652/gcc-turning-on-...
Building open source software packages for apple is difficult because you need to pay for apple computers to run the build software.
This isn't true.
What is true is that if you want users to be able to just download and run (rather than download, run an obscure command, and then run your software), you have to pay Apple to notarize your builds.
Fuck Apple for this.
> rather than download, run an obscure command, and then run your software
This also isn't true.
On a Mac (or on Windows) software that has not been digitally signed will show a scary dialog box telling you that software you download off the internet might be malicious.
On the Mac, to bypass this, you just right click the software and pick "Open".
That used to be true. With the latest versions of macOS, you have to run
xattr -rd com.apple.quarantine ~/Download/TheDamn.dmg
I'll never understand binary crybabies. Just build the damn thing yourself.
There days for minor adjustments I just use PhotoPea (the online photo editor). If I need more than that I use Affinity Photo or Photoshop.
The software that I would love to see running well on macOS (Intel or ARM) is Inkscape.