GNOME Bugzilla – Bug 142987
Scale layer property
Last modified: 2018-05-24 11:05:39 UTC
Layers should have an option to give them a scale, where they will be placed on the final image as a different size than they actually are. Thus, original detail could be retained in the ear-ring I draw on my character, and I can go back and make minor changes easily.
This is a rather weird concept for an image manipulation program and I have never seen another app doing this. I don't think we will add this feature.
Sounds like a feature from an SVG editor. Not suitable for a raster based image manipulation program, imo.
Well, it's not completely insane and it's something that is supposed to be doable with the framework provided by GEGL. That doesn't necessarily mean that we will do it but we could keep it as an enhancement request. If only it had a more meaningful summary...
This fits in with the general idea of maintaining a transformation matrix for each layer, so that one can build up a set of linear transformations (scale, rotate, perspective, etc.) without losing detail at each step.
Yes, OK, the summery was a little vague. First then, weskaggs' mention of a full transformation mechanism is much better actually. The first step of this could actually be a transformation matrix, with more user-friendly interfaces for Scale, Rotate, etc. added layer, simply auto-generating the matrix needed for the requested transformation. I often work with many components to my image, and often I work in high detail and scale things down, but I hate to loose the detail in the case that I need to make more changes. This is why I want the feature, and rotation of layers would be wonderful as well. Henrik, yes, this does sound like a feature of an SVG, but that doesn't mean it isn't useful or wouldn't be a welcome feature. I very often require both vector and raster related tools for a single image, so this just seems natural to me and completely unnatural to separate them.
Why on earth do you scale things down in the first place? If you scale things down in a pixel-based image manipulation program you have to expect that you loose detail. That's the concept of pixel-based image manipulation. Anyway, all these concepts (also the other enhancement requests you made) are in the GEGL design so rest assured we've already put a lot of thought into this direction.
OK, so, I'm confused. You're saying its a pointless, useless feature and there is already work towards it. So, is this a possible happening or not? And, I scale them down because somethings are just easier to work with at a larger scale, but they may need to be smaller relative to the rest of the image. This also goes along with my bug #143138
GEGL is supposed to support such things in it's rendering graph but that doesn't necessarily mean that GIMP is going to make use of it. It might make sense to discuss it later when the framework is in place. At the moment it's far from being possible.
I would like to second the motion.. One example of where this can be useful is where you're trying to fit a layer from one image into another .... lots of tweaking of location, rotation, scaling, shearing, etc. With the standard pixel-only translations, you lose information at each step. If it's done as a matrix operation, you pretty much end up doing the same amount of work (just add in the (cheap) cost of the matrix math), but the resulting quality is far higher. Once you start doing other changes (e.g. painting on the result), you might have to fix the image in pixels, but the end result quality for many operation sequences would be a world apart. It might also make it a good bit cheaper for keeping track of history as well... All you'd have to store would be the initial image, the trasformaiton matricies and the final image (for speed). You might, however, want a checkbox to turn the feature off, as some people might actually <i>like</i> the distortive effect of multiple pixelated translations.
The one case where a pixelated result can be most wanted is when you're shrinking down a huge layer to a small graphic -- doing fruther transformations based on the huge original can be expensive, so fixing after the initial scale down can be important.
*** Bug 686275 has been marked as a duplicate of this bug. ***
Please see Bug 686275 for another view on this subject.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/78.