Hacker News Reader

Comment by nickjj | Hacker News Reader

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.

View on HN

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 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.

I take it you also mean vibe coding to be one shot and go?

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.

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.

> 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...

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.

Ctags are very limited and unpopular. Most people do not use them, by any measurement standard.

Using a text editor without LSP or some form of intellisense in 2026 is in the extreme minority. Pretending otherwise is either an attempted (and misguided) "flex" or just plain foolishness.

> probably half the engineers at my company are just raw dawgin it with either vim or emacs

Both vim and emacs support LSP and intellisense. You can even use copilot in both. Maybe you're just not aware...

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.

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 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.

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.

That's up to you. Right now filters work the same way - you can merge them automatically on creation, merge them at some point while working, or merge them on export. For formats like PSD, we'll eventually add the option to export as non-destructive filters as well.

We don't want to take away choices - we just want to add more options for people's workflows.

> 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%?

but nobody argues against undo/redo in gimp!

going by your text editor analogy, we are arguing against implementing undo/redo as a "non-destructive delete", based on adding backspace control characters within the text file. I want infinitw undo/redo, but i also want that when I delete a character it is really gone, not hidden!

Sorry, but I still don't see it - the text editor analogy is stretched far too thin. If I share a project file, I want the other user to see all this stuff. If I don't want them to see all this stuff, I send them an export.

It would be a true shame if every useful feature was left out due to 1% of use cases becoming slightly different.

Nice - all actions performed on a layer should retain a hidden "raw original" so we get non-destructive transforms.

Reply on news.ycombinator.com