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...
When your language has neither name-mangling nor namespaces, a simple grep gets you a long way, without language specific support. Ma editor (not sure if it counts as IDE?) uses only words in open documents for completions and that is generally enough. If I feel like I want to use a lot of methods from a particular module I can just open that module.
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.
When does the final calculation happen then, at file save/export? Will be unexpected. Or does it end up in the final format? That's going to be a nightmare, because then you can't use GIMP to redact data anymore.
> 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!
Cropping IS a destructive operation. If the program isn't throwing information away, then it doesn't actually do cropping, but some different operation instead.
From a user perspective I wouldn't like it, if I were to crop something and the data would be still there afterwards. That would be a data leak waiting to happen.
I genuinely can't empathize with this objection. To me it's basically the same as arguing against Undo/Redo in a text editor because someone could come along and press Undo on my keyboard after I've deleted sensitive data.
What percentage of users sends around raw project files from which they've cropped out sensitive data to users who shouldn't see that data, vs. what percentage of users ever wants to adjust the crop after applying other filters? The latter is basically everyone, the earlier I'm guessing at most 1%?
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. :(
It got deprecated only in 3.10 and you can compile against that and link it with the latest Gtk+ 3 library. I do this for my programs, because I don't like it when the widget toolkit ignores my OS settings.
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.
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.
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.
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.
It sounds like you are a gimp developer. Curious about the use of AI to work on it. Do the gimp devs use AI to write code?
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.
> Half the developers I know still don't use LSP
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...
When your language has neither name-mangling nor namespaces, a simple grep gets you a long way, without language specific support. Ma editor (not sure if it counts as IDE?) uses only words in open documents for completions and that is generally enough. If I feel like I want to use a lot of methods from a particular module I can just open that module.
I guess I'm nobody then.
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.
Like 99.9999 of woodworkers already cheat by using metal and not wood tools
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.
Metal tools also require massive investments compared to plain wood tools.
I take it you also mean vibe coding to be one shot and go?
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.
When does the final calculation happen then, at file save/export? Will be unexpected. Or does it end up in the final format? That's going to be a nightmare, because then you can't use GIMP to redact data anymore.
> 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!
Cropping IS a destructive operation. If the program isn't throwing information away, then it doesn't actually do cropping, but some different operation instead.
From a user perspective I wouldn't like it, if I were to crop something and the data would be still there afterwards. That would be a data leak waiting to happen.
I genuinely can't empathize with this objection. To me it's basically the same as arguing against Undo/Redo in a text editor because someone could come along and press Undo on my keyboard after I've deleted sensitive data.
What percentage of users sends around raw project files from which they've cropped out sensitive data to users who shouldn't see that data, vs. what percentage of users ever wants to adjust the crop after applying other filters? The latter is basically everyone, the earlier I'm guessing at most 1%?
Nice - all actions performed on a layer should retain a hidden "raw original" so we get non-destructive transforms.
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."
That is generally my intention when downscaling an image.
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.
nondestructive edits are great, it's the interface that's weird
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.
Why is then opening a JPEG not an Import?
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.
When opening a jpg, it literally says "importing pic.jpg" when opening a jpg
Exactly. That's my point.
When saving, it simply should say "Exporting pic.jpg".
'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:
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.
I assume you don’t do this manually and you’re doing some kind of scripting, can you describe your process?
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.
The lack of GenAI integration is actually refreshing
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.
Content-aware fill has been in PS since 2010 I believe, long before the genAI craze.
There are other applications with that implemented, with GenAI too.
Photoshops recent AI rotate tool looks useful compared to these features GIMP is adding.
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.
Select a rectangle. Stroke or fill the selection.
I agree it's a bit counter-intuitive, but afaik it's always worked like that.
It always had worked like that and it has always been a 100% nonintuitive and peculiar way to deal with this operation
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.
Type "R" to enter rectangle select mode. Click and drag on the image to select. "Stroke Selection" and various fills are on the Edit menu.
Don't worry, GIMP's UI never made any sense to anyone (Graphic Designer or otherwise), save for hardcore GIMP fans.
If you want to draw squares, you're probably looking for a vector drawing program, like Inkscape.
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.
One of the first things I install on any new computer is Gimp. Thank you to all involved in the Gimp project.
Well, I guess you just have to go wake him up now won't you?
https://www.youtube.com/watch?v=I2pV02dTVE8
Let everyone be reminded how joyful GIMP 2.10 menus used to look ...
https://i.imgur.com/nVyMQBt.png
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)
Thank you for this.
Also small world, floating point JPEG person here.
Ah, hey! We've been busy with getting 3.2 finished, but I plan to go back and read over your latest message once we've recovered a bit. :)
No rush - been busy over here too.
Did you also manage to enable menu icons?
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. :(
It got deprecated only in 3.10 and you can compile against that and link it with the latest Gtk+ 3 library. I do this for my programs, because I don't like it when the widget toolkit ignores my OS settings.
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.
Ah, PDF editting works?
Didnt know that! Thanks for telling!
Is it possible to train a model on all gimp features that will eventually let us prompt whatever edits we want and it’ll automate gimp to achieve it?
You could do this, GIMP is scriptable which is half the battle - you may not even need to train a model.
Why the downvotes?