Being able to scale an image without losing quality is going to be handy. I always found it odd that scaling down an image now and then scaling it back to its original size 2 seconds later with the same tool resulted in a loss of quality and having to delete the layer, then re-import the image to get the original quality back.
It's because each transform was "destructive" (like filters use to be by default). What link & vector layers do instead is store a transform matrix, so each transform just updates the matrix instead of actually re-rasterizing the layer each time.
We were hoping to expand that feature to all layer types for 3.2, but we ran out of time to properly test it for release. It'll like be finished for the next minor release.
I can't speak for all of us, but generally no (in terms of GenAI at least). There are concerns about generated code not being compatible with GPL, and honestly a lot of the drive-by GenAI coded merge requests tend to not work.
I see you are getting downvoted but I don't blame you for this question. I've been curious about what developers of established products are doing with LLM assisted coding myself.
Like most of us, they're certainly using ai-assisted auto-complete and chat for thinking deep. I highly doubt they're vibe coding, which is how I interpret the parent's question and probably why they are being down voted.
This is insulting to our craft, like going to a woodworkers convention and assuming "most of [them]" are using 3D-printers and laser cutters.
Half the developers I know still don't use LSP (and they're not necessarily older devs), and even the full-time developers in my circle resist their bosses forcing Copilot or Claude down their throats and use in fact 0 AI. Living in France, i don't know a single developer using AI tools, except for drive-by pull-request submitters i have never met.
I understand the world is nuanced and there are different dynamics at play, and my circles are not statistically representative of the world at large. Likewise, please don't assume this literally world-eating fad (AI) is what "most of us" are doing just because that's all the cool kids talk about.
Your IDE either uses an LSP or has its own baked-in proprietary version of a LSP. Nobody, and I mean nobody, working on real projects is "raw dawgin" a text file.
Most modern IDE's support smart auto-complete, a form of AI assistance, and most people use that at a minimum. Further, most IDE's do support advanced AI assisted auto-complete via copilot, codex, Claude or a plethora of other options - and many (or most) use them to save time writing and refactoring predictable, repetitive portions of their code.
Not doing so is like forgoing wheels on your car because technically you can just slide it upon the ground.
The only people I've seen in the situation you've described are students at university learning their first language...
I write code exclusively in vim. Unless you want to pretend that ctags is a proprietary version of an LSP, I'm not using an LSP either. I work at a global tech company, and the codebase I work on powers the datacenter networks of most hyperscalers. So, very much a real project. And I'm not an outlier, probably half the engineers at my company are just raw dawgin it with either vim or emacs.
I don't use an IDE under the common definition. All my developer friends use neovim, emacs, helix or Notepad++. I'm not a student. The people i have in mind are not students.
Your ai-powered friends and colleagues are not statistically representative. The world is nuanced, everyone is unique, and we're not sociologists running a long study about what "most of us" are doing.
> forgoing wheels on your car
Now you're being silly. Not using AI to program is more akin to not having a rocket engine on your car. Would it go faster? Sure. Would it be safer? Definitely not. Do some people enjoy it? Sure. Does anyone not using it miss it? No.
I didn't say using different technology was cheating, and metal tools are certainly part of woodworking for thousands of years so that's not really comparable.
It's also very different because there's a qualitative change between metal woodworking tools and a laser cutter. The latter requires electricity and massive investments.
Many years ago I tested a native OS/2 image editor with this feature. It also made it possible to undo an individual transform or effect in the current stack while leaving the rest untouched. Will that be possible in Gimp as well?
Yes, it's planned for transform tools and already possible with filters. Technically our transform tools are already capable of this (they use GEGL operations the same as our non-destructive filters). We just need to tweak it to not immediately commit the transform, and then implement a UI.
> I always found it odd that scaling down an image now and then scaling it back to its original size 2 seconds later with the same tool resulted in a loss of quality
Maybe it's because I grew up with Paint Shop Pro 6 and such, but that seems completely normal and expected to me
I was using Photoshop, I don't remember when exactly but it's probably in the 15-20 year range when non-destructive scaling was available. I don't remember not having it. Glad to see GIMP is moving in this direction.
> I always found it odd that scaling down an image now and then scaling it back to its original size 2 seconds later with the same tool resulted in a loss of quality
I'm honestly baffled at your surprise... say, if you crop an image, and 2 seconds later you enlarge it to its original size; do you expect to get the inital image back? Or a uniform color padding around your crop?
Scaling is just cropping in the frequency domain. Behaviour should be the same.
From a developer perspective you're obviously correct, but from a user perspective it doesn't make sense that the tool discards information, especially when competing tools don't do that.
Of course as a developer that makes it all the more impressive - kudos to the team for making such big progress, I can't wait to play around with all the new improvements!
Does anyone else find non-destructive editing kinda unintuitive?
I get the practical benefits of it, but it feels shoehorned in to an interface for doing destructive edits. Chained edits frequently interact in ways that confuse/surprise me.
I think I'd rather do non-destructive edits via some sort of node-editor interface. (And to be honest most of the things I use GIMP for don't need non-destructive editing in the first place)
The current non-destructive UI is a bit of a compromise - we can't really mix layers with NDE filters in the layer dock until GTK4 (from what I understand), so the pop-up menu is what we had to work with.
You can check "Merge filter" at the bottom of the filter dialogue though, and it will automatically merge the filter like in 2.10 (and the setting is remembered going forward)
"When I was a kid, when we shrunk a 200x200 image down to 100x100 we lost information forever, and we liked it that way. It was a simple time. A predictable time."
Until you're a professional designer and they ask you to "scale up this part" or something. Then you realize that your actual intention is having the original layer currently rendered at that size and did not actually intend to permanently modify the original so you can't go back.
Once you export it is, of course, actually downscaled.
Same idea behind masks and modifiers and the like. Most modern creation tools try to give ample opportunity for non-destructive modification to simpler, immutable primitive layers.
This is one of those things I'd think geeks would geek out about, as nondestructive edits mean the steps to construct an image are stored, not just the final image—kinda like a monad in FP.
Can I finally Ctrl+s jpeg image? And no, export is not enough because first time it will ask for for path and compression level which it already knows. I just want to Ctrl+s and be done.
Almost all programs treat the “Save” operation as something used with the native format, in this case XCF files. These preserve things like layers, etc. JPG and other formats are exports because after you close the file you can’t get all that stuff back when you reopen it.
I get it, and when Photoshop changed this default, GIMP followed with changing this workflow. It used to be different in older versions of Photoshop and Gimp.
Advanced user usually know exactly what they're doing, and opening a PNG or JPEG file, changing a few pixels, and saving it, should require as few key presses as possible.
I don't want the UI to get in my way when I open->edit->save.
'Opening a JPEG' is creating a new image and importing the JPEG to it. ctrl-e on first use will establish the export setting. It's two clicks if you really want to overwrite the original. I think it would be very easy to accidentally and destructively overwrite the original image file if it was different, when ctrl-e is in muscle memory.
This is not true with common applications people are familiar with. Excel and Word will happily "save" a PDF, and it behaves like exporting and doesn't change the document being edited.
Word and Excel seems to change behavior on every release. I don't think it's something Gimp should try to chase.
Gimp has save: "Save native gimp file" and export "Export an image file". It's a bit confusing to me why people find this confusing.
It seems like you can assign this action to Ctrl + S, yes. See here:
Edit → Keyboard Shortcuts → file → Overwrite […]
I think this would be awful default behaviour, but I guess it’s nice to have the option if you really want it, and I was pleasantly surprised at how easy it was to find after reading your comment.
It used to be even simpler, though I am sure it caused all sorts of problems: for any Gtk+ program, if you hovered over a menu and pressed a new key combination, it would reassign the shortcut for that menu to what you just pressed. You still had to turn it on, and it was an amazing feature, but you'd occasionally reassign something you did not want to :)
File - Overwrite file, that's been there for a while. It can be turned into a hotkey, it's unmapped by default, and I don't think that'd change nor should it change, given how user hostile that'd be, the long history of how it works in editors like that, and with how they lean towards non-destructiveness of it all. Also, that just sounds like perhaps a simpler editor would be a better fit, like Paint.
Love GIMP. Always capable of doing anything I need done with raster images or even PDFs. Lately I've been opening PDFs and lightening the pages so that they can be printed without wasting a bunch of toner on backgrounds that are meant to be white but were scanned in as a light grey.
Sorry, I don't have to do it in sufficient quantity of frequency to encourage scripting. And while doing it manually, I notice that the required tweaking of levels changes depending on the content of the page and how poor the scan is. I'm not sure an automated solution would provide satisfactory results consistently.
Do you suggest using manual brushes instead of content-aware fill, or am I supposed to not want to retouch the images in the way that GenAI makes so quickly and easily? My argument is that applications probably should provide useful tools for solving practical problems, regardless of their implementation details.
I use Gimp pretty sporadically but the latest UI refresh (I’m guessing introduced in 3.0?) completely baffles me.
It might just be that it’s better tailored for graphic designers, which I’m clearly not. But now I can’t even figure out how to draw a square on screen. Let along anything clever.
Hi! What was the last version of GIMP that you used before 3.0?
We get an equal amount of "GIMP's UI never changes!" and "You changed too much of the UI in the latest version", so it's difficult sometimes to figure out the specific issues.
I’ve been using it for at least a decade, likely longer.
Albeit I might only use it, at most, for a few hours every few months. So I’m definitely not a seasoned expert despite that length of time. But I always considered myself reasonably competent.
I usually indifferent about UI changes, I’m not someone who tends to complain either for nor against. So this isn’t a complaint about Gimp changing thing (if that’s what happened). The issue here is really more about how I now cannot figure out the simple things any more. And that might just be on me rather than Gimp.
I don’t see that option. Maybe the issue is my installation has broken in some odd way. I’ll try completely removing it and all preferences, then reinstalling.
Comments like yours miss the point. In fact worse, they just serve to stagnate FOSS because it pushes the assumption that the software is always right and users are idiots, without taking any time to understand what those users are actually trying to do.
There are hundreds of good reasons why someone might want to overlay a vector shape on a bitmap image. The desire to draw shapes on bitmap isn’t something weird that I’ve just invented for HN. It’s been a staple feature such graphics packages since the inception of bitmap graphics editing. And it’s been a staple feature of Gimp since I first switched to Linux in the 90s.
But that’s all moot because I was just making an arbitrary example.
And as an aside, I do use vector drawing software too. So I’m fully aware of their existence.
If you mean the color icons, you can easily switch back to those in the Welcome Dialog that appears when you first open GIMP (look in the Personalize tab). It's the first thing I do when I install GIMP on a new machine. :)
oh wow, i never realized that this is there, in such a convenient location too. and you can't just change the icon style, but also disable the tool groups which was the most annoying change i found because it makes finding the right tool harder. (i'd love tool groups where the tools are grouped but not folded, or in a way where i can expand certain groups that i use often)
That was a feature in GTK2 (the GUI library we use) that was removed in GTK3.
We could try to fight the library and reimplement it ourselves, but it'd take a developer dedicated to do it. I miss the menu icons too. :(
I find Gimp super useful and easy to learn. Using it to edit pdfs generated by NotebookLM is my new way of creating decks and presentations. Thanks for the great work.
Use the ellipse selection tool and hold Shift to make it a circle. Hold Ctrl to pull from origo. Then use Stroke Selection or Fill Selection.
Although, I miss being able to create a selection from a point on the ellipse/circle instead of just origin or bounding box corner.
I would also like to stroke on the inside or outside of the selection instead of just its middle.
I have often had to first fill the circle and then select again from the same origin point to cut out the inside.
Instead of trying to get at the same origin point, I usually just keep the selection active and then go to "Selection" menu and choose either "Shrink" or "Expand" options (or similar language: I use a localized version).
There's always the GFig filter, which has existed in GIMP for a long time. :)
GIMP 3.2 actually adds vector layers, which are the basis for a shape tool (it was my "big project" for this release). We have a GSoC project idea for doing the last bit of work to make a dedicated shape tool: https://developer.gimp.org/core/internship/ideas/#implement-...
You can draw a representation of a circle with extremely primitive tools and it isn't possible to actually draw a circle. Your question as rendered is hard to answer.
This plugin https://github.com/LinuxBeaver/Gimp_Layer_Effects_Text_Style... also makes adding text effects with GIMP pretty good. This is unrelated to 3.2 but turned out to be a necessity for me.
reply