GIMP issueshttps://gitlab.gnome.org/GNOME/gimp/-/issues2024-03-09T10:10:14Zhttps://gitlab.gnome.org/GNOME/gimp/-/issues/10797gimp don't have intuitive access to help pages2024-03-09T10:10:14Zlillolollogimp don't have intuitive access to help pages<!-- ⚠️ IMPORTANT: READ ME! ⚠️
This is the default template for bug reports.
For feature requests or performance issues, please switch instead to the appropriate template in the "Choose a template" list.
It is important that you fill al...<!-- ⚠️ IMPORTANT: READ ME! ⚠️
This is the default template for bug reports.
For feature requests or performance issues, please switch instead to the appropriate template in the "Choose a template" list.
It is important that you fill all the fields of the template.
-->
### Environment/Versions
- GIMP version:2.99.16
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)-->selfbuild
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->Windows 11
### Description of the bug
Since gimp 3 have many new feature, redesign, etc. it is important to offer easily access to the help pages.
Almost all widgets have the functions with a tooltip description and the possibility to press F1 to open the help page for this function,tools don't have it, many tooltip are missing on many tools,plugin don't have help button etc.
Tools have only the the possibility to open the help page by menu Tools->type of tool->tool.3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/10076Preparation for the future XCF2023-10-04T20:51:50ZJehanPreparation for the future XCFHaving a brand new [XCF](https://developer.gimp.org/core/standards/xcf/) format has been a long-time project of the team (present in [roadmap](https://developer.gimp.org/core/roadmap/)). This report is to gather needs, requirements and i...Having a brand new [XCF](https://developer.gimp.org/core/standards/xcf/) format has been a long-time project of the team (present in [roadmap](https://developer.gimp.org/core/roadmap/)). This report is to gather needs, requirements and implementation ideas. It is definitely not planned for GIMP 3, but for after. I'm adding a %"3.2" milestone as meaning "something we want to do at some point after GIMP 3 is released".
I write this report for myself and other developers if they have any comment on the technical choices. It won't change much GIMP from the "user point of view", except that it will suddenly unlock a lot of possibility and make it easier to improve GIMP with unblocking the storing capabilities of XCF (many issues are stuck on the complexity of doing them while keeping the current format).
Some of the key points for a new formats are:
* Built around GEGL Buffers. Since our internal buffers are GEGL buffers and it's meant to stay that way, it just makes sense.
* Partial load: files are getting bigger, not only because we want to store more in them, but because size of source images are getting bigger as time passes (while FullHD was a big deal 10 years ago, now it's 4K or now; and if we talk about prints, it's even far higher; any camera also produces photos of 5 or 10k per dimension nowadays), computer memory is bigger too… so now it's common to have very huge project files. Also since GIMP is able to load bigger-than-memory images, more users are getting interested in GIMP when they need to process huge images. Nevertheless it doesn't mean we want to load everything at once. Sometimes we can get away with partial loads until specific actions occur. E.g. previews only, but also with upcoming animation support, we may want to only load buffers for some frames, not the whole project. It means better performance as well as sensation of faster loads.
* Incremental save and autosave: with huge files, saving can take seconds or even minutes. This was a main blocker for autosave (we can't randomly block editing). Incremental saves are also a huge time-saver but it's harder to implement with a custom file format because we have to create the whole API infrastructure to manage data offsets, sizes and whatnot. It would be much easier to depend on a stable and generic "container format" which implements this part for us and just provide us with a stable API.
* Embedding data: as we are talking more and more about possibility of embedding data (used fonts, palettes or brushes associated to a project, etc.), it would be easier done when moving once again to a well known container format rather than just appending it to a custom file format and managing offsets.
## Image data
This one is easy. The new format idea was always planned on being based on GEGL buffers. It also means that we need to make sure that on-disk GEGL buffers are a stable format (I think it is already, but this needs to be sure) from now on.
Having GEGL buffers would give us [autosave](https://gitlab.gnome.org/GNOME/gimp/-/issues/67) (and/or [backup saves](https://gitlab.gnome.org/GNOME/gimp/-/issues/51)) nearly for free as GEGL buffers have the ability to sync on disc easily and very quickly. Nevertheless with the additional container layer (see below), this might not be as true, unless we do things in 2 steps: uncompress data to disc then load from the uncompressed data (and oppositely: sync buffers directly to disc then compress in container archive).
## Container format
For auto-save and other features to be as easy as possible, the structure would be a common case of a container format containing a single metadata file (indicating how the file is structured, such as which buffer corresponds to which layer, etc.), the image data itself (GEGL buffers) and other embedded data. The question about the container format can then be raised. Historically a lot of format just use zip (OpenDocument, OpenRaster, EPUB, even my recent work on GEX for GIMP extensions).
The advantage of zip are:
1. It's very common and won't go away. Implementations are also many.
2. A common usage is that the first file added in the zip should be non-compressed, is called `mimetype` and contains for only contents the registered mimetype. This way, all zip-based file formats have a very easy magic number at offset 38, which is the chosen mimetype. E.g. a `.odt` file has `mimetype` at offset 30 and `application/vnd.oasis.opendocument.text` at offset 38.
3. While not being an extraordinary compression, zip is ok while relatively fast.
Now very recently I read this article by the sqlite project about using sqlite as a complex format container and I found it quite interesting: https://www.sqlite.org/affcase1.html
As for the points above:
1. I think that sqlite has quite a large userbase and is probably not going to disappear anytime soon, though I'm not sure if it has other implementations than the upstream one (we would likely use the upstream one anyway, the point is about format sustainability as we don't want to get stuck with an abandoned format).
2. Not sure if sqlite have similar properties where we could store some data to be always found at a given offset. This being said, I'm wondering if we could not simply keep our XCF header ("gimp xcf v[0-9][0-9][0-9]" at offset 0) and simply store the sqlite db after that. This way, all existing readers would know it's a GIMP project file, simply with a bumped version so they would not try and read it (then it doesn't matter that the format after this is in fact completely different). Since XCF has always been a versioned format anyway, we are able to do this.
3. The article linked above say that the compression rate is similar, though we'd want to verify if this is also true for image data. Also I expect the speed to be similar too. Though it should be tested.
Now how I see good additional advantages to using sqlite:
* Data safety: we take great care of not breaking XCF and there are even several safety measures in GIO to not overwrite a XCF file until the file descriptor is closed. Nevertheless the atomic update abilities of sqlite would clearly be a step further to make sure that we can't break a XCF even if the software/OS crashes or electricity goes down just at the wrong moment while updating.
* While zip also allows to only extract or insert/update part of the archive contents, it looks like sqlite will be more performant. This really requires testing and understanding how both technology operates more closely though.
Anyway this is mostly to be studied. Note that the idea floated around that it would be nice to also allow the ability to have folder-projects, which is basically about having the XCF content just using the file system (no container format). For instance, Ardour does this. It should not be a default, because having single files to share is just more practical to more and also because without any compression, a XCF project would take a lot of space on-disk, but it has advantages:
* Without the container layer, load/save should be much faster. Even more for the near-instant sync discussed above.
* By breaking the data in sub-files, it is easier to sync (partial syncs for backups, etc.).
* Similar to the previous point, it makes XCF projects simpler to version (e.g. in `git`) because if you edit a single buffer, you don't have to re-version the whole project.
* It also makes the text parts (metadata) diffable.
Of course, here zip looks like it's a better fit because it's already file-system like, but nothing prevents us to use path-like names as object names to query in a SQL db.
## Metadata format
XML still feels like the best fit for extensibility, backward and forward compatibility.
Typically it allows to easily add new tags or new attributes while staying very semantic. And when adding some optional new features in-between others, it's much easier to have the older versions of GIMP not to break (we would just make them to ignore unknown tags/attributes and display a warning that some features might be missing).
## libxcf
It might be the opportunity to move XCF loading and saving to an external library [libxcf](https://gitlab.gnome.org/GNOME/gimp/-/issues/3258).
## Backward compatibility
Obviously all this discussion about a new format doesn't mean we will break loading old XCF files. We will keep code loading old XCF files forever. Being able to load any XCF files, even from the very early GIMP versions, is a key feature in GIMP. This whole report is only about a vision for a future format which will be much more easily extended, easier to save, and so on.3.2JehanJehanhttps://gitlab.gnome.org/GNOME/gimp/-/issues/9833Request: Scale image to Background/Canvas height automatically when importing2023-08-09T16:08:25ZJoe HindyRequest: Scale image to Background/Canvas height automatically when importing**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Windows 11
### Description of the feature
<!-- Please describe your feature with details.
Add screenshots, design images or other files which wo...**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Windows 11
### Description of the feature
<!-- Please describe your feature with details.
Add screenshots, design images or other files which would help for
understanding the feature or for implementation.
Also add links when needed, for instance for implementation standards
or other relevant resources.-->
Essentially, what I'm requesting is a togglable function that will automatically scale images to the existing canvas (Background layer) size when I import them into Gimp. You can find similar functionality in Photoshop (which enables this functionality by default on a fresh install) where it'll scale the imported image to the canvas layer's height immediately upon import (while maintaining the original aspect ratio), which can make some types of work much easier to do quickly.
This is possible manually. As an example, if I create a 1920x1080 Background layer (canvas), and I import, say, a mobile phone screenshot, I would use the Layer>Scale Layer function to adjust the height to 1080 (I would let the Scale Layer function maintain the original aspect ratio here). This can take a long time (comparatively speaking) if I'm trying to do something like line up three mobile screenshots into a single image for use in a blog or social media post.
The closest I've been able to come to this is the [ofn-autoscale-layer](https://sourceforge.net/projects/gimp-tools/files/scripts/) plugin script. However, despite its name, it's still a manual process requiring a keyboard shortcut. It's essentially just Scale Layer but adjusts the imported layer to the Background layer height when activated without any additional input from the user.
### Use cases
<!-- If not obvious, explain the use cases or problems to solve. -->
The use case is, admittedly, pretty minor. It would be mainly used for quick and dirty image creation for use in things like [blog posts](https://www.slashgear.com/1354685/best-travel-apps-android/) like the one linked where one may want to line up 3 mobile screenshots in a single image. Any workflow that involves quickly tossing an image into Gimp to scale it for social media / blog post use could benefit from this. The manual methods described above aren't terrible for this kind of work, but an automatic toggle can save a pretty significant amount of time at scale.3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/9831New blend formulas2023-08-11T20:32:48ZGNOME Gitlab AutomationNew blend formulas
The following Merge Request (MR) has been forwarded from GitHub in order to prevent
the GNOME Project from losing contributions coming from un-official channels. And for
contributors to not see their valuable contributions not being acc...
The following Merge Request (MR) has been forwarded from GitHub in order to prevent
the GNOME Project from losing contributions coming from un-official channels. And for
contributors to not see their valuable contributions not being accounted for.
Relevant information:
Github handle: Muzzarino
MR URL: https://github.com/GNOME/gimp/pull/46
Patch URL: https://github.com/GNOME/gimp/pull/46.patch
Body of the MR:
Added formulas for multiply add, overlay (muladd), and the inverse light functions3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/9808Please natively support export (and maybe import) to OCA (Open Cel Animation)...2023-07-30T20:54:49ZDennis CarrlPlease natively support export (and maybe import) to OCA (Open Cel Animation) format.**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->
Any of them
### Description of the feature
<!-- Please describe your feature with details. -->
[OCA](https://rxlaboratory.org/tools/oca/) is a ...**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->
Any of them
### Description of the feature
<!-- Please describe your feature with details. -->
[OCA](https://rxlaboratory.org/tools/oca/) is a newer format that's designed for seamless usage of traditional 2D cel animation between any art or animation program that supports it. It's meant to be simple and already there are exporters and importers being developed for krita, blender, and it's natively built into OpenToonz/Tahoma2D. I know for a fact that GIMP in later releases plans on supporting animation features built into it from the GIMP Animation Package (GAP) program. So it would be an excellent opportunity to be able to do some animation in GIMP and then open the very same project in say natron or blender, even ones like After Effects or any program you desire should a plugin be made for it.
### Use cases
<!-- If not obvious, explain the use cases or problems to solve. -->
Because GIMP is planning on later releases to expand animation capabilities, it makes sense to be able to export or import OCA projects just like how you can export ORA files.3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/9323Adding layer groups to existing project increases file size up to 70%2024-02-14T17:38:34ZenzedrailmapsAdding layer groups to existing project increases file size up to 70%### Environment/Versions
- GIMP version: 2.99.14
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> Gimp project beta flatpak
- Operating System: <!--[Windows? ma...### Environment/Versions
- GIMP version: 2.99.14
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> Gimp project beta flatpak
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Linux
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).-->
### Description of the bug
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->
I have a project with around 400 layers. It saves to 37.4 GiB.
With no other changes I added 9 layer groups and put the layers into these groups. I then saved the file again.
The new file size is 40.9 GiB which is an increase of roughly 10% for no actual change in the graphical data in the file.
Either one of two things may have happened:
1. Each layer group needs additional storage space that amounts to 3.5 GiB for 9 layer groups, OR...
2. The file compression becomes less efficient when layers are divided up into layer groups.
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)--> Always
Reproduction steps:
1. Create a project with no layer groups
2. Save the project
3. Add layer groups for layers and see how the file size changes
…
Expected result:
The file size should not change much or at all as layer groups are just a few extra entries in the layer list occupying a handful of extra bytes.
Actual result:
Increased file size for no obvious reason
### Additional information
If you have a backtrace for a crash or a warning, paste it here.3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/8675Improve light/dark theme support with OS preferences lookup2024-01-25T17:58:17ZJehanImprove light/dark theme support with OS preferences lookupFollowup of #8509, but moved to GIMP 3.2 milestone, because it's not a priority right now and our dark theme support works quite OK so far.
Basically Freedesktop now has an API for light/dark style preferences:
* [Page on GNOME wiki](h...Followup of #8509, but moved to GIMP 3.2 milestone, because it's not a priority right now and our dark theme support works quite OK so far.
Basically Freedesktop now has an API for light/dark style preferences:
* [Page on GNOME wiki](https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/Dark-Style-Preference). Since we don't plan to use libadwaita or libhandy so far, the section of interest is the [other section](https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/Dark-Style-Preference#other) which has some useful C code sample to get inspired from.
* [Some blog post](https://blogs.gnome.org/alexm/2021/10/04/dark-style-preference/)
* [Some other blog post](https://blog.elementary.io/the-need-for-a-freedesktop-dark-style-preference/)
We should study a bit the rationale. I say this in particular as what is particularly interesting is that this is a 3-state settings: prefer-light, prefer-dark and default (I also wonder if there were cases where someone might set their OS to dark, but might want exceptionally GIMP to be light? Right now, this is not possible, but with such setting, it would). Yet in the second blog post, they say:
> Similarly, when communicating this preference to users, it likely shouldn’t be a choice between “light” and “dark.” Instead, it should be phrased as “prefer dark style” or similar.
Which kinda contradicts the 3-state logic. So we should look further on it.
Also there is the discussion about whether GIMP should follow the system settings as a default, or stay dark by default. Typically in the GNOME wiki link, their second case is:
> Apps that didn't have a preference but used dark appearance by default (e.g. **Photos** or **Videos**) should be dark unless the system prefers light appearance, such as for the high contrast mode. […]
Lastly, we should look how to set the theme to "prefer light". It's not clear to me how it's done with GTK+3 themes (the sample explains how to get the FD setting, not how to apply it to GTK themes). We have a trick to prefer the dark theme, not one to prefer the light themes (unlike for instance libadwaita where they apparently have a `ADW_COLOR_SCHEME_FORCE_LIGHT`).
Some TODOs:
* [ ] Study the Freedesktop settings rationale.
* [ ] Check how to force/prefer light theme with GTK+3 themes.
* [ ] Decide what should be GIMP default behavior regarding theme.
* [ ] Check how similar settings are handled in other OSes, and implement if possible at least a similar logic with macOS and Windows API (apparently they both have similar OS settings, though it might not be a 3-state, maybe it's just `prefer-dark` vs default for these).3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/8513The two toolboxes stuck together after turning off single window mode and on2024-02-15T03:25:20ZlilydjwgThe two toolboxes stuck together after turning off single window mode and on### Environment/Versions
- GIMP version: 2.99 60d08c87f4
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> https://github.com/archlinuxcn/repo
- Operating System...### Environment/Versions
- GIMP version: 2.99 60d08c87f4
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> https://github.com/archlinuxcn/repo
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Arch Linux
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).-->
### Description of the bug
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->
By default there are three windows in non-single-window mode, one window to show an image and two toolboxes. I have those two toolboxes stuck together and cannot tear apart.
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)-->
Reproduction steps:
1. launch GIMP 2.99. It's in single window mode.
2. Turn off single window mode. Now three windows.
3. Turn on single window mode. The two toolboxes are both on the left now.
4. Turn off single window mode again. Only two windows.
…
Expected result: The two toolboxes remain seperate.
Actual result: They are stuck ever since. I can close all those closable tabs and reopen them separately, but it's a lot of work and they'll stick again after switching to single window mode.
### Additional information
I'm on Wayfire (a wlroots-based Wayland compositor). I have those toolboxes stuck with release version (2.10.32) too but didn't know how.3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/8447Enable "Lock Tab to Dock" for newly opened dockable dialogs if they are added...2022-08-02T21:24:39ZMichael SchumacherEnable "Lock Tab to Dock" for newly opened dockable dialogs if they are added to a dock directly, or as soon as they are added to an existing dock**Operating System:** all
### Description of the feature
This is a follow-up feature request to enhancement request #8444.
Issue #8444 is about changing the default lock state for all dialogs docked to dock in the default user interfa...**Operating System:** all
### Description of the feature
This is a follow-up feature request to enhancement request #8444.
Issue #8444 is about changing the default lock state for all dialogs docked to dock in the default user interface layout, and can probably be done without any source code changes.
The behavior for any newly added dialogs would then still be unspecified, and this enhancement request is intended to rectify that.
### Use cases
If all default dialogs are locked to their respective docks, the users can expect that to happen for all newly added dialogs as well.
Some special consideration might be necessary for dialogs which are not added to a dock directly via its tab menu, but opened as standalone dialogs - and this into a new dock - via the Windows > Dockable Dialogs sub-menu. Users may well expect to be able to drag these to an existing dock and then expect them to stay there.
This might require some additional configuration options, but bears the danger of becoming a option-matrix kind of behemoth if we'd try to cover all possible cases ;)3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/8444Enable "Lock Tab to Dock" for all dockable dialogs in the default user interf...2024-02-24T21:47:52ZMichael SchumacherEnable "Lock Tab to Dock" for all dockable dialogs in the default user interface layout**Operating System:** all
### Description of the feature
The feature would be a change to the default settings shipped with and used by GIMP.
In particular, it is about setting the "Lock Tab to Dock" setting for each dialog that is pa...**Operating System:** all
### Description of the feature
The feature would be a change to the default settings shipped with and used by GIMP.
In particular, it is about setting the "Lock Tab to Dock" setting for each dialog that is part of the default interface layout to enabled, preventing any accidental and deliberate movement of the tab inside its docks, and outside of its dock.
### Use cases
The main audience for this change is new users, who tend to drag dialogs out of there docks by dragging sliders (e.g. brush size or opacity) and grabbing the tabs instead, without knowing what is happening and/or how they can revert this change.
Possible side effects are that the customizability of the interface becomes less obvious, and users who are used to dialogs being movable may think this feature has been removed altogether.3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/8386Plugin registration in 3.02023-04-13T01:44:27ZofnutsPlugin registration in 3.0**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->All
### Description of the feature
As I understand it in Gimp v3, a plugin `foobar`
1. Must be is a directory `foobar` in the plugin path
2. Is r...**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->All
### Description of the feature
As I understand it in Gimp v3, a plugin `foobar`
1. Must be is a directory `foobar` in the plugin path
2. Is registered by identifying a `foobar` or `foobar.*` executable in the directory (and there can be only one such file, when there are several, all but one are ignored).
So, the plugin is wholly identified by the directory. In addition, the use of directories is the recognition that a plugin can be spread over several files (libraries, translations, configuration).
In light of this, considering only the timestamp of the executable to invalidate the cache data in `pluginrc` is a bit restrictive, change to other files can also impact the registration result (a config file can enable/disable some options, and why should the registration code be in the main executable anyway?).
The proposed change is to have the time stamp in `pluginrc` be the timestamp of the most recent file in the plugin directory, and refresh the cache if the more recent file in the directory is more recent than this time stamp.
As far as I can tell:
* For most existing single-file plugins there won't be any impact
* There should be little performance impact since the directory is scanned each time
### Use cases
I have several v2 plugins that will register different procedures from a configuration, for instance:
- A set of guides
- A luminosity mask
- A hatching pattern
These are procedures (one set of guide = one procedure = one menu entry) so that they can be associated to keyboard shortcuts. Currently when users change the configuration files they have to do non-obvious things (such as `touch`ing the executable, or erasing/altering `pluginrc`) to make the changes visible. Implementing the above would make this unnecessary, the new configuration file would make Gimp re-register.
I see that in V3 there are the `query` and `init` calls, and `init` could likely be used for this, but it is a bit of overkill since the configuration file rarely changes after a while.3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/8100Improving "Clipping" in transformation tools: clipping target + GUI rethinking2023-05-08T10:46:46ZJehanImproving "Clipping" in transformation tools: clipping target + GUI rethinking**Operating System:** all
### Description of the feature
The "Clipping" settings is always a bit of a mystery to me. Each time I have to read the docs to understand/remember again what is what. I think this could be improved by reviewi...**Operating System:** all
### Description of the feature
The "Clipping" settings is always a bit of a mystery to me. Each time I have to read the docs to understand/remember again what is what. I think this could be improved by reviewing a bit the GUI. Possibly even replacing this one scrolldown "Clipping" settings by breaking it into more understandable sub-options.
Typically there are currently a single option where you don't do any kind of clipping/cropping (Adjust) vs. options where you crop, either to the old layer size (Clip) or to as much as possible without having any transparent area (Crop to Result) or finally cropping to keep the same ratio as the original layer. I wonder if we could not reorganize differently the choices.
The second thing is relatively to what we clip. Right now, it's all relative to the layer. But we have use cases where it could be relatively to the canvas, or even relatively to specific pixel size and/or a given ratio. It is both a different topic but related because I think that any new GUI rework of these options should take both choices into consideration.
### Use cases
Today @Aryeom had a class with students where we would try to rectify a paint from a photography with the Perspective tool in corrective mode. Since the tool can't know the actual object ratio, it would adjust the handle contents to fit into the layer size, which means you need to first crop the layer to be the right ratio, but also it needs you need to crop bigger than the original needed contents since you must crop destructively (as the *layer* size matters). Here is the process:
- Load your image in GIMP
- Since I know that the paint is 63×76cm in real life, crop with "Delete crop pixels" (or possibly "Selected layers only" if you have more layers you don't want to crop) and "Fixed Aspect ratio" of 63:76.
- Now with Perspective tool, select "Corrective" direction and "Adjust" clipping. Move the handles to the paint corners, then transform.
- Finally since I want the frame into my image, I could crop again with "Allow growing".
So I go from left (first step) to right (last step):
![crop-with-ratio](/uploads/c72e5a4d4d3c74d2683defd6292db59b/crop-with-ratio.png)
The problem with this workflow is that the first crop is annoying and also necessarily destructive because the layer size is used as the clipping reference.
The second problem is that since we necessarily need to target a target size bigger than the original size, which might not be what we want, quality wise (we can rescale after, but then it's one more transformation step; if we can do the thing on one step, it means less quality loss).
These could be avoided if we had a way to choose the clipping target: it could be either the layer, or the canvas (so we could crop non-destructively and even to smaller size) or even to any size as set through pixel (then no crop needed at all). Optionnally setting a ratio and letting the tool choose the biggest possible size with this ratio within the handles for instance.
There is definitely something to improve here. I'm letting this report for myself as I may want to have a look at it, but not now and probably not by GIMP 3.0. So it's a self-reminder.3.2AryeomAryeomhttps://gitlab.gnome.org/GNOME/gimp/-/issues/8095Creating a stroke around a circular selection does not create a circle2023-07-08T14:54:45ZRuman GerstCreating a stroke around a circular selection does not create a circle### Environment/Versions
- GIMP version:2.10.24
- Package: Ubuntu packages (APT)
- Operating System: Kubuntu 21.10
**Info:** Tested it also with the latest beta Flatpak version
### Description of the bug
A user expecting to create a ...### Environment/Versions
- GIMP version:2.10.24
- Package: Ubuntu packages (APT)
- Operating System: Kubuntu 21.10
**Info:** Tested it also with the latest beta Flatpak version
### Description of the bug
A user expecting to create a circular outline will intuitively choose the option to create a circular selection and create a stroke around it. With increasing width of the stroke, the result becomes less circular.
To generated the expected behavior, users must create a path (see this video from 2009: https://www.youtube.com/watch?v=NqAozyd4AhU), which is less intuitive and involves additional steps.
![Screenshot_20220417_203544](/uploads/d45878ec319408468d896cb2895ccf62/Screenshot_20220417_203544.png)
![Screenshot_20220417_203607](/uploads/fb68c07c21ed18506b0a37456e241f72/Screenshot_20220417_203607.png)
![Screenshot_20220417_203614](/uploads/2d820e7fb0ca92f06d20ec4b539376f0/Screenshot_20220417_203614.png)
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)--> Always
Reproduction steps:
1. Create a circular selection with fixed 1:1 ratio
2. Go to Edit > Stroke selection...
3. Choose a line width > 1 (e.g. 50 or 100)
4. Click "Stroke"
Expected result: A perfect circle around the selected area with even thickness
Actual result: A circular object with uneven thickness and 4 visible indentations
### Additional information
If you have a backtrace for a crash or a warning, paste it here.
None3.2Shubham DauleShubham Daulehttps://gitlab.gnome.org/GNOME/gimp/-/issues/8094Improvement/Suggestion (Size request for export)2024-02-24T22:38:11ZCPUCzarImprovement/Suggestion (Size request for export)**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->
### Description of the feature
<!-- Please describe your feature with details.
Add screenshots, design images or other files which would help fo...**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->
### Description of the feature
<!-- Please describe your feature with details.
Add screenshots, design images or other files which would help for
understanding the feature or for implementation.
Also add links when needed, for instance for implementation standards
or other relevant resources.-->
### Use cases
<!-- If not obvious, explain the use cases or problems to solve. -->
I'm sure your software is used a lot for working with other online application i.e. Youtube, Instagram, Twitch, etc. Part of the proccessing of importing is size limitations for things like thumbnails etc. Example: YouTube has a 2mb cap on Thumbnail images. It'd be nice if as part of the export options you could choose an actual file size you want to shoot for. Then the program would choose whatever options get you the closest to that size while keeping quality.
Just a thought, thanks for all you do. It is very much appreciated3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/7553Efficient (incremental) file save2024-02-27T18:40:56ZMark SweeneyEfficient (incremental) file save**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->All
### Description of the feature
Save only the changes to a file
### Use cases
<!-- If not obvious, explain the use cases or problems to solve...**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->All
### Description of the feature
Save only the changes to a file
### Use cases
<!-- If not obvious, explain the use cases or problems to solve. -->On a 10k file with 50+ layers, saving one small change means saving the entire file again.
It would be wonderful if some kind of smart save was an option.
1GB + files take a while to save even on SSD3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/7539Opening some images lock GIMP2022-01-30T15:32:26ZJehanOpening some images lock GIMP### Environment/Versions
- GIMP version: master
- Operating System: Linux
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branc...### Environment/Versions
- GIMP version: master
- Operating System: Linux
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).-->
### Description of the bug
As described [in this comment](https://gitlab.gnome.org/GNOME/gimp/-/issues/5863#note_1300758), opening some image locks GIMP. I experienced this same issue with some other image (which I can't upload as these are private docs).
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)-->
Reproduction steps:
1. Open [the image in this zip](https://gitlab.gnome.org/GNOME/gimp/uploads/e07caa1d2f10809c78ed431a7dd90c8c/xiaomi_photo.zip)
Expected result: GIMP asks what to do with the profile and loads the image.
Actual result: GIMP seems to lock, seemingly forever (wait long enough at least for me to get bored and kill the process).
### Additional information
It looks like this would happen when an image would output either the rotation (as is the case for the file uploaded here) or the color profile dialog (the case I encountered on other files) **and** there is somehow warnings outputted at load, for instance because of #5863.
Indeed there is a way to work around the issue: in Preferences > Debugging, make so that we don't debug the warnings. Then the image opens without any problem and the warning is just outputted to stderr:
```
app/gimp-2.99: (null)-WARNING: No namespace info available for XMP prefix `MiCamera'
```
Note that that setting, in Preferences > Image Import & Export, the "Metadata Rotation Policy" or "Color Profile Policy" to anything but "Ask what to do" is not enough not to block GIMP.
Finally, and unfortunately, running GIMP inside `gdb`, it doesn't block anymore (but the debug dialog does not contains a trace because it fails to attach to the process). So it's harder to understand what's happening.3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/7508Hierarchical names in layer groups2022-03-27T15:14:42ZJotamucheroniHierarchical names in layer groups**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->All
### Description of the feature
I think it would be interesting if Gimp could differentiate one layer from another not just by its name, but al...**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->All
### Description of the feature
I think it would be interesting if Gimp could differentiate one layer from another not just by its name, but also by the name of the group it's in. That is, the same way it is done on a file system.
In my opinion, it doesn't make much sense to be able to place a layer in a group, but still need to label it with a unique name at the global level. This forces the user to use redundant nomenclature such as: "group 1" -> "group 1 photo", "group 1" -> "group 1 text"; "group 2" -> "group 2 photo", "group 2" -> "group 2 text". An attempt to name, for example, layers like "group 1" -> "photo", "group 1" -> "text", "group 2" -> "photo", "group 2" -> "text" will result in a naming conflict and Gimp will automatically rename the last two layers as "text #1" and "group #1".
I don't know if it's a simple functionality to implement, but it's very very useful.
### Use cases
If this functionality is implemented, it will be possible to name layers within a group independently of the names of layers outside the group. With that, it will be possible to name layers in a simpler and leaner way.3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/7473Apply to all opened images / Macro recording2021-11-14T23:16:39ZCarsten JensenApply to all opened images / Macro recording**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Windows
### Description of the feature
<!-- Please describe your feature with details.
Add screenshots, design images or other files which would...**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Windows
### Description of the feature
<!-- Please describe your feature with details.
Add screenshots, design images or other files which would help for
understanding the feature or for implementation.
Also add links when needed, for instance for implementation standards
or other relevant resources.-->
I find myself very often doing repetitive work, like reducing amount of colors, applying the same color map etc.
If it's a lot of images I tend to move to imagemagick and use a script. But with a few images (<20) I do it manually
in gimp, where I have to wait for each change to be processed before starting working on a new image. And in the end
save them all and have to manage all the export dialog boxes and choices.
So, it could be really nice to have a macro recorder which can record the steps done on a single image, and apply to
all the other opened images and/or have it batch processed on the contents of a folder.
Here are some steps I usually do with a 16bit color image (and repeat for many more)
1. Adjust color levels
2. Wait 2-3 secs
3. Convert image to grayscale (because it's much faster to convert 16 bit to gray to 8 colors than directly from 16bit to indexed 8)
4. wait 2-3 secs
5. convert to indexed 8 colors
6. wait 1 sec
7. CTRL-E
8. Click Export
9. Click yes to replace
10. Click export (after making sure export settings are correct)
11. CTRL-W
12. CTRL-D
Quite a lot of time, and actions for a simple job, plus the high risk of human error.
### Use cases
<!-- If not obvious, explain the use cases or problems to solve. -->3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/7306Parameter Ranges Are Not Reasonable2022-04-12T15:00:48ZStrate2Parameter Ranges Are Not Reasonable### Environment/Versions
- GIMP version:
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)-->
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after ...### Environment/Versions
- GIMP version:
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)-->
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).-->
### Description of the bug
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->
![Unbenannt](/uploads/c4002b006cfe86b2ac646f437df5e398/Unbenannt.PNG)
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)-->
Always
Reproduction steps:
Look at the image. Already looks pretty drastical, doesn't it? Now look at the parameters. They are all barely off the centre, which is the most subtle area for the fractal effect. I just don't understand why you would not skew those parameters a bit. Have you even tried using this effect yourselves? Half the slider should be all about setting the values between -.1 and .1 and only at the outter edges of the parameter it should go to these ridiculous values, if you insist. Idk why you would insist, though, because if you turn it up just a little bit too wide you just get a white image, due to it trying to draw too many repetitions. so maybe you could not only skew the parameter way better, but also reduce its range entirely. It is the same with the order. 1, 2 and 3 still look like something where you can still see what the original image was like. but everything above that is just barely usable. still i can't drag the slider to 3, because it is linear and goes up to >1000. It's not just the fractal effect. You could try to add some workflow improvements to the parameters in all of the effects by skewing them. Take inspiration from VST plugins (audio software). If you release a VST plugin without reasonable ranges people just won't use them, because there are enough competitors. Image processing seems to be a less competitive field, except for Adobe's stuff. but let's just imagine really quickly that it would be really cool if everyone knew GIMP has a cool workflow. that would be nice, wouldn't it?
…
Expected result:
Being able to make a slightly fractal version of my photo
Actual result:
not being in the mood for that anymore.. for now.3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/7213GEGL Graph chain operation should be easier to use.2021-09-12T05:05:11ZLinuxBeaverGEGL Graph chain operation should be easier to use.Hey, I'm friends with Liam on the Gimp discord and I've been experimenting with GEGL Graph chain operations. I'd like to know if there is a way to make GEGL graph easier so Gimp can do things like designer text with less manual effort.
...Hey, I'm friends with Liam on the Gimp discord and I've been experimenting with GEGL Graph chain operations. I'd like to know if there is a way to make GEGL graph easier so Gimp can do things like designer text with less manual effort.
Here are some examples of me using GEGL Graph chain operations
https://streamable.com/y8yl6z
https://streamable.com/beo1ky
https://streamable.com/qv3dys
You can even test them yourself
![image](/uploads/f7bcfaa036a91950a7b9c825e3055676/image.png)
**Very Small**
gegl:color-overlay value=#fbff00
gegl:dropshadow x=0.00 y=0.00 radius=0.00 grow-shape=circle grow-radius=3 opacity=1 color=#1d9fa9
gegl:dropshadow x=0.00 y=0 radius=0.00 grow-shape=circle grow-radius=3 opacity=1 color=#dcfcff
gegl:dropshadow y=5 x=4 radius=0.70 grow-radius=0
**Small**
gegl:color-overlay value=#fbff00
gegl:dropshadow x=0.00 y=0.00 radius=0.00 grow-shape=circle grow-radius=4 opacity=1 color=#1d9fa9
gegl:dropshadow x=0.00 y=0 radius=0.00 grow-shape=circle grow-radius=4 opacity=1 color=#dcfcff
gegl:dropshadow y=5 x=4 radius=0.80 grow-radius=0
**Medium**
gegl:color-overlay value=#fbff00
gegl:dropshadow x=0.00 y=0.00 radius=0.00 grow-shape=circle grow-radius=6 opacity=1 color=#2868ff
gegl:dropshadow x=0.00 y=0 radius=0.00 grow-shape=circle grow-radius=6 opacity=1 color=#dcfcff
gegl:dropshadow y=5 x=4 radius=0.90 grow-radius=0
**Large**
gegl:color-overlay value=#fbff00
gegl:dropshadow x=0.00 y=0.00 radius=0.00 grow-shape=circle grow-radius=8 opacity=1 color=#2868ff
gegl:dropshadow x=0.00 y=0 radius=0.00 grow-shape=circle grow-radius=8 opacity=1 color=#dcfcff
gegl:dropshadow y=5 x=4 radius=1.00 grow-radius=0
Color Overlays, Drop Shadow, Long Shadow and Transformation overlays are at the heart of this. If you could think of a way to make GEGL chain operations easier a lot more people would benefit from the Gimp.
One idea is to have Gimp save the operations manually in a folder and run them all together, (like pic attached). That way a user could revoke the design text.
Example/Mockup
![image](/uploads/238655febe998d1c3330f9e8202e6a45/image.png)
![image](/uploads/1b0f5b6ca3e6ef4ada2a88d45742f544/image.png)
The end goal is to make it where the user can make design text as quick as possible instead of manually evoking drop shadow long shadow and gegl operation menu > color overlay. Please consider. I think a lot of people would like this.3.2