GIMP issueshttps://gitlab.gnome.org/GNOME/gimp/-/issues2023-04-29T09:13:11Zhttps://gitlab.gnome.org/GNOME/gimp/-/issues/9283Spontaneous cluster of up to 3 zoom values appearing close to 100% value2023-04-29T09:13:11ZJo RadcliffeSpontaneous cluster of up to 3 zoom values appearing close to 100% value### Environment/Versions
- GIMP version:2.10.12
- Package installer: Aptitude
- Operating System: Linux
- Not verified in last stable version of GIMP
### Description of the bug
Although GIMP 2.10 usually opens with 7 preset zoom levels a...### Environment/Versions
- GIMP version:2.10.12
- Package installer: Aptitude
- Operating System: Linux
- Not verified in last stable version of GIMP
### Description of the bug
Although GIMP 2.10 usually opens with 7 preset zoom levels and taking on a further 3 to total 10 it often happens that up to three custom values inexplicably appear between 90% and 110% aside the standard 100%. These values are not related to recent previous usage.
### Reproduction
Is the bug reproducible? fairly often, one value between 90% and 110% half the time, two values quarter of the time, three values tenth of the time.
Reproduction steps:
1. Open GIMP
2. Open a new image in GIMP
3. Traverse zoom values by placing mouse pointer over zoom arrow bottom left of window and either mouse clicking or scroll wheeling to see zoom values. Type in a few custom values and double click magnifying glass button top right to fit to page.
Expected result: Custom values only appear where selected and the most recent selections up to 3 more besides default 7 retained unless some of defaults lost whereby only replaced by further selected values.
Actual result: Random cluster of up to three values appear usually between 90% and 110%. These can be very persistent, selecting another custom value outside that narrow range will be lost soon following any mouse pointer traversing the zoom range and a cluster value reappearing. Clustering inhibits workflow as 100% is an important default that becomes "shielded" by the spurious values.https://gitlab.gnome.org/GNOME/gimp/-/issues/8615PNG export crashes Dataton WatchOut Production (probably due to Exiv2 saving ...2024-03-11T12:08:54Zkraves-ozPNG export crashes Dataton WatchOut Production (probably due to Exiv2 saving 'zTXt' tag)### Environment/Versions
- GIMP version: 2.10.12
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> flatpak, Standalone Installer from gimp.org
- Operating System...### Environment/Versions
- GIMP version: 2.10.12
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> flatpak, Standalone Installer from gimp.org
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Windows, macOS
<!--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
Export PNG appears to produce a non-compliant format that crashes some other apps.
### Reproduction
Is the bug reproducible? Always
Reproduction steps:
1. Open a supplied PNG (perhaps only with alpha)
2. Usually I'm just cropping/sizing but doesn't matter
3. Export to PNG with any options
4. Resulting PNG now has something that crashes another major display application that seems to use Visual C++
Expected result: Not cause a third-party app crash
Actual result:
### Additional information
I also logged a bug report for their app. Opening exported PNG in a basic image editor, like Preview or Image Convertor, then saving again removes the error.
Thankshttps://gitlab.gnome.org/GNOME/gimp/-/issues/4249PNM export of very big images is extremally slow2023-08-04T16:41:27ZWitold BarylukPNM export of very big images is extremally slowTrying to export PNM (image, which I am not sure selects which PNM format, but I am guessing it tries to find the best one?), is very slow for very big images (approx 10GB uncompressed, 60000x60000). The export process is relatively fast...Trying to export PNM (image, which I am not sure selects which PNM format, but I am guessing it tries to find the best one?), is very slow for very big images (approx 10GB uncompressed, 60000x60000). The export process is relatively fast itself, but it takes about 26 minutes for the export dialog to even show up, the one that has only two options: "Raw" and "ASCII". I have no idea why it is so long, as the GIMP already should have all the metadata required and PNM can all be written to disk in a streamed fashion with O(1) allocation that doesn't depend on image size. After clicking final Export the write to disk (actually a network attached filesystem using sshfs), is fast enough about 1 minute, but my server is a bit slugish despite 10Gbps networking used, so that might be the limit of the IO.
During this waiting for the Export dialog to show up GIMP memory usage and CPU usage fluctuates widely.
I have enough RAM to keep entire image in memory. I only have tile cache set to 30 GB tho. I still have 26GB of free memory on my system. (128GB RAM in the machine, but big portion of it is used by filesystem caches and tmpfs).
The image is using 8-bit integers per color (RGB, 24-bit per pixel), without alpha. 23 layers with simple compositing. GIMP is saying 41.8GB for the image resource usage in the GIMP process.
I do not have similar issues exporting to PNG from GIMP.
Using Linux, Debian GNU/Linux, testing, amd64, GIMP 2.10.12-1https://gitlab.gnome.org/GNOME/gimp/-/issues/4116Rectangle selection tool freezes UI2024-01-06T08:45:55ZSamuel Ratssamuel.rats@gmail.comRectangle selection tool freezes UIGIMP version: 2.10.12
Reproduced at least back to first 2.10 release.
Operating System:
- Windows 10
- Linux (Ubuntu 16.04, Ubuntu 18.04)
Package:
- Windows : Installer from gimp.org
- Linux : flatpak
# Context
Hi everyone :)
...GIMP version: 2.10.12
Reproduced at least back to first 2.10 release.
Operating System:
- Windows 10
- Linux (Ubuntu 16.04, Ubuntu 18.04)
Package:
- Windows : Installer from gimp.org
- Linux : flatpak
# Context
Hi everyone :)
I contacted you a while back in the mailing list, but never followed up (sorry...) about a bug on rectangle selection tool.
Thanks to the Hacktoberfest, Genymobile (my company) is giving me a full day to contribute to open source projects we use and love.
So here is the first step: a bug report.
# Description of the bug
The bug is located in the Rectangle Selection Tool.
Reproduction can be a bit tricky, so I also made a video.
What happen is that, given some circumstances, when resizing the rectangle selection, the whole UI/GIMP freezes, leave no other choice but force-closing it.
This happens when upper-left rectangle coordinates are odd.
# Reproduction
Always
Reproduction steps:
- Given a blank image (2480px * 3508px) (attached)
- When using the Rectangle Selection Tool
- Activate "Fixed" rule, set to "Aspect ratio"
- Create an initial rectangle, which will be a square
- Move the rectangle until upper-left corner coordinates are odd numbers
- Using the Tool UI, set its width to 2480, then press enter.
- Then, the UI/GIMP is frozen
Expected result:
Selection is set to a 2480px * 2480px square
Actual result:
UI/GIMP freezes
# Additional information
I started investigating the bug a while back, so I may have a few pointers on the issue.
This seems to be related to double rounding on the square coordinates (PROP_X, PROP_Y, PROP_WIDTH, PROP_HEIGHT).
I know that switching to integer coordinates fixes the issue (did that a while back, but it broke other things).
Also, if this is really a rounding issue, other tools may also have the same behavior (not tested).
It's mid-day here, when I post this bug, and I still did not managed to rebuild GIMP on my Linux.
I have another 4 hours ahead, so I'll keep you posted if I have some more info (and maybe, a fix).
# Attachments
- [gimp-rectangle-selection-tool.mkv](/uploads/4585ff7a96d5cfc1972d90fe4b206ae1/gimp-rectangle-selection-tool.mkv)
- [u7hlu17tq.jpg](/uploads/76893df83bb562b460d2ea2f5f23390e/u7hlu17tq.jpg)https://gitlab.gnome.org/GNOME/gimp/-/issues/4112Creating a new selection after finishing one with the Free select tool is imp...2023-11-30T20:54:39ZGhost UserCreating a new selection after finishing one with the Free select tool is impossible without hitting Return, Esc or changing tools firstGIMP version: 2.10.12
Operating System: Windows 10
Package: mingw64/mingw-w64-x86_64-gimp 2.10.12-5
# Description of the bug
The free select tool should function like the rectangle and elliptical select tools: the action of closing a...GIMP version: 2.10.12
Operating System: Windows 10
Package: mingw64/mingw-w64-x86_64-gimp 2.10.12-5
# Description of the bug
The free select tool should function like the rectangle and elliptical select tools: the action of closing an area by clicking on the starting point should immediately free up the tool for further use. Instead, currently it requires pressing RETURN before a new selection can be made. This is inconsistent with how both the rectangular and elliptical selection tools work -- both of which allow resizing of a previous selection, as well as creating a new selection without having to press RETURN first.
If this is a setting in preferences, then the default setting should be set in favor of consistency.
# Reproduction
Is the bug reproducible? Always
Reproduction steps:
1. With image open, select area using free select tool.
2. Select a new area using free select tool without switching to another tool first or pressing RETURN.
…
Expected result: As with rectangle/ellipse select tools, the expected result is that a new area is selected (instead of/in addition to/subtracting from the existing selection)
Actual result: A second selection is not possible without pressing RETURN or switching to another tool first.https://gitlab.gnome.org/GNOME/gimp/-/issues/4100Undo Command does not restore cursor position in text layer2021-09-01T17:57:06ZGhost UserUndo Command does not restore cursor position in text layerGIMP version: 2.10.12
Note: After undoing a char deletion the cursor is not restored but moved to the text end.
Operating System: [Windows & Linux]
# Reproduction
![save_cursor](/uploads/cf1ba3f3b70ad26aa0b8d15d9b43577e/save_cursor.gi...GIMP version: 2.10.12
Note: After undoing a char deletion the cursor is not restored but moved to the text end.
Operating System: [Windows & Linux]
# Reproduction
![save_cursor](/uploads/cf1ba3f3b70ad26aa0b8d15d9b43577e/save_cursor.gif)
Is the bug reproducible? [Always]https://gitlab.gnome.org/GNOME/gimp/-/issues/4098inconsistencies in gimp_paintbrush behavior2024-03-01T15:11:21Zofnutsinconsistencies in gimp_paintbrush behaviorGIMP version: 2.10.12 Linux flatpak
# Description of the bug
* Create a path with a single stroke going left to right.
* Add a green background (for contrast) and a transparent layer
* FB/BG colors are the usual black and white, active...GIMP version: 2.10.12 Linux flatpak
# Description of the bug
* Create a path with a single stroke going left to right.
* Add a green background (for contrast) and a transparent layer
* FB/BG colors are the usual black and white, active gradient is `FG to BG (RGB)`.
With
* Fade=0,gradient=0
![image](/uploads/356922446dc80fadacd59b2ff9d509f6/image.png)
* Fade=0,gradient=300
![image](/uploads/4100c9c10c985df1c7331fe724cb2df4/image.png)
So far so good. This is coherent with a stroke that starts from the left
* Fade=300,gradient=0
![image](/uploads/4df6386ecbc45e17464ba245a346c490/image.png)
First problem, the opacity increases left to right, when the PD browser doc says the opposite:
> The 'fade-out' parameter is measured in pixels and allows the brush stroke to linearly fall off. The pressure is set to the maximum at the beginning of the stroke. As the distance of the stroke nears the fade-out value, the pressure will approach zero.
* Fade=300,gradient=300.png
![image](/uploads/83c7bda20efc67955eec74e01c391737/image.png)
Second problem, having a gradient disables the fade-out.
- - -
XCF file used for the tests:
[Stroke.xcf](/uploads/2d478e9bad42bdeec4c8d8e84465a8fe/Stroke.xcf)https://gitlab.gnome.org/GNOME/gimp/-/issues/4055Text in zoom text box truncated2024-03-18T19:29:15ZGhost UserText in zoom text box truncatedGIMP version: 2.10.12
Operating System: [Windows & Linux]
# Description of the bug
Text (%) is truncated, see Windows Screenshot:
![windows](/uploads/540a87212ddda7ec74fe420ae6e86d6f/windows.PNG)
After zooming out completely the perc...GIMP version: 2.10.12
Operating System: [Windows & Linux]
# Description of the bug
Text (%) is truncated, see Windows Screenshot:
![windows](/uploads/540a87212ddda7ec74fe420ae6e86d6f/windows.PNG)
After zooming out completely the percent sign is not shown:
![linux](/uploads/932bbea04b7d21642c7afff7cced7ddc/linux.gif)
Expectation:
The text box size should adapt according to text size (number + %), as when zooming in
![zoom_in](/uploads/cbf210d5feeb565e6c1b33dbc8d2b467/zoom_in.gif)
Is the bug reproducible? [Always]https://gitlab.gnome.org/GNOME/gimp/-/issues/4037Tool BoxMiddle Mouse Click tries to open Clipboard Text as File even if it is...2024-03-12T22:17:26ZGhost UserTool BoxMiddle Mouse Click tries to open Clipboard Text as File even if it is not an URIGIMP version: 2.10.12
Operating System: [Windows & Linux]
# Description of the bug
Copy some text to clipboard. Hover Mouse over Tool Options, click MMB.
![open_file](/uploads/6058d0bc47b8804be2fe03e5e7238086/open_file.gif)
# Reproduc...GIMP version: 2.10.12
Operating System: [Windows & Linux]
# Description of the bug
Copy some text to clipboard. Hover Mouse over Tool Options, click MMB.
![open_file](/uploads/6058d0bc47b8804be2fe03e5e7238086/open_file.gif)
# Reproduction
Is the bug reproducible? [Always]
Expected result:
nothing should happen.
Actual result:
Try to open an non existent file.https://gitlab.gnome.org/GNOME/gimp/-/issues/4021"Save image" dialog title should be "Save As"2023-05-12T23:46:12ZGhost User"Save image" dialog title should be "Save As"GIMP version: 2.10.12, Win7x64
![Save_AS](/uploads/0cce3fac6fbbb8538c73ef4b03884d23/Save_AS.png)GIMP version: 2.10.12, Win7x64
![Save_AS](/uploads/0cce3fac6fbbb8538c73ef4b03884d23/Save_AS.png)https://gitlab.gnome.org/GNOME/gimp/-/issues/4012Page Setup Menu Icon greyed out icon in Standard Theme with file open2024-03-02T13:59:25ZGhost UserPage Setup Menu Icon greyed out icon in Standard Theme with file openGIMP version: 2.10.12, Win7x64
# Reproduction steps:
1. Reset Settings (optional)
2. No File open, Standard Icon Theme -> File Page Setup Icon greyed out (OK)
3. Create new File
4. File Page Setup Icon still greyed out (Bug)
5. Change ...GIMP version: 2.10.12, Win7x64
# Reproduction steps:
1. Reset Settings (optional)
2. No File open, Standard Icon Theme -> File Page Setup Icon greyed out (OK)
3. Create new File
4. File Page Setup Icon still greyed out (Bug)
5. Change Icon Theme to Color
6. Change Back to Standard Icon Theme -> File Page Setup Icon is correct now
Expected result:
Show correct icon, after a file is created
Actual result:
The icon is greyed out.
![grayed_out](/uploads/f99c20587f9d63d52e4b2c691f9d548b/grayed_out.gif)https://gitlab.gnome.org/GNOME/gimp/-/issues/4011Resetting the Preferences doesn't properly reset the highlighted entries in t...2019-10-01T21:34:53ZGhost UserResetting the Preferences doesn't properly reset the highlighted entries in theme and icon theme selectorsGIMP version: 2.10.12, Win7x64
# Reproduction steps:
1. Change Icon Theme to Color, Theme to Light
2. Reset Settings
3. Theme and Icons are reverted to standard (Dark & Symbolic) as expected but not the selections in the Settings Dialo...GIMP version: 2.10.12, Win7x64
# Reproduction steps:
1. Change Icon Theme to Color, Theme to Light
2. Reset Settings
3. Theme and Icons are reverted to standard (Dark & Symbolic) as expected but not the selections in the Settings Dialog
close dialog, re-open, then selection (Dark & Symbolic) is correct
Expected result:
Select (Highlight) Dark Theme and Symbolic Icons
Actual result:
The previous Color Icon & Light theme remain highlighted, which is confusing.
Even after re-selecting e.g. Light then OK, Light is not applied, so it's incorrectly highlighted.
![highlight_issue](/uploads/4058b02e53c2c751c3af30a449f6df03/highlight_issue.gif)https://gitlab.gnome.org/GNOME/gimp/-/issues/40012.10.12 x64 for Win: Fails list dir contents, when some file is not accesible...2024-03-14T15:21:18ZSomeone fromjapan2.10.12 x64 for Win: Fails list dir contents, when some file is not accesible for preview.GIMP version: 2.10.12 x64 for Windows
Operating System: Windows 7 x64
Package: Installer from gimp.org
# Description of the bug
"Open image" dialog (file->open) fails completely to list contents of a directory(aka "folder"), when any...GIMP version: 2.10.12 x64 for Windows
Operating System: Windows 7 x64
Package: Installer from gimp.org
# Description of the bug
"Open image" dialog (file->open) fails completely to list contents of a directory(aka "folder"), when any file is locked for access.
# Reproduction
In my case I have images stored along with MS Publisher pub files.
When (just) one of these files is open in Publisher for edit, gimp fails to list the directory, including all the sub-directories.
Pub is not one of GIMP formats. However it throws a message:
> "Could not read the contents of <dir>
> Error when getting information for file “<work_dir>\<filename>.pub”: Input/output error
It makes browsing for images, and opening them impossible with "open file" dialog.
Reproduction steps:
1. save a document, like .PUB along with images in a directory
2. open that document for exclusive R/W in supporting software (Publisher in my case)
3. start GIMP and try entering(listing) the directory
Expected result:
All the files and sub-directories should be listed, regardless of contents and state of access.
Actual result:
Nothing is listed, like the directory is empty (when it is not)
A message is thrown, that GIMp could not read a file, which it was not supposed to read at all.
# Additional information
![image](/uploads/50d6b5d4125798367b0116dbd53c91b3/image.png)2024-03-21https://gitlab.gnome.org/GNOME/gimp/-/issues/3992Bug when dealing with filters2024-03-12T22:37:50ZGhost UserBug when dealing with filters```
GNU Image Manipulation Program version 2.10.12
git-describe: GIMP_2_10_10-209-g3d8535b55f
C compiler:
Configured with: --prefix=/Applications/Xcode-10.app/Contents/Developer/usr --with-gxx-include-dir=/Library/Developer/CommandLineT...```
GNU Image Manipulation Program version 2.10.12
git-describe: GIMP_2_10_10-209-g3d8535b55f
C compiler:
Configured with: --prefix=/Applications/Xcode-10.app/Contents/Developer/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode-10.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
using GEGL version 0.4.16 (compiled against version 0.4.16)
using GLib version 2.58.1 (compiled against version 2.58.1)
using GdkPixbuf version 2.36.12 (compiled against version 2.36.12)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.4 (compiled against version 1.42.4)
using Fontconfig version 2.13.0 (compiled against version 2.13.0)
using Cairo version 1.16.0 (compiled against version 1.16.0)
```
> fatal error: Segmentation fault: 11
Stack trace:
```
0 libgimpbase-2.0.0.dylib 0x00000001054b9b85 gimp_stack_trace_print + 1509
1 gimp-bin 0x0000000104580f76 gimp_eek + 374
2 gimp-bin 0x0000000104580dfb gimp_fatal_error + 27
3 gimp-bin 0x0000000104581abd gimp_sigfatal_handler + 45
4 libsystem_platform.dylib 0x00007fff7df48b5d _sigtramp + 29
5 ??? 0x00007fb94bd8cc80 0x0 + 140433818176640
6 libgegl-0.4.0.dylib 0x00000001058eb987 gegl_node_connect_from + 119
7 gimp-bin 0x00000001049ae9f1 gimp_gegl_apply_cached_operation + 1761
8 gimp-bin 0x00000001048a7d17 gimp_drawable_merge_filter + 775
9 gimp-bin 0x00000001048b034d gimp_drawable_filter_commit + 317
10 gimp-bin 0x00000001045f7454 gimp_filter_tool_control + 292
11 gimp-bin 0x000000010463ea80 gimp_tool_control + 400
12 libgobject-2.0.0.dylib 0x0000000105d3eadc g_closure_invoke + 204
13 libgobject-2.0.0.dylib 0x0000000105d54a54 signal_emit_unlocked_R + 2004
14 libgobject-2.0.0.dylib 0x0000000105d558d0 g_signal_emit_valist + 2240
15 libgobject-2.0.0.dylib 0x0000000105d560c2 g_signal_emit + 130
16 libgobject-2.0.0.dylib 0x0000000105d3eadc g_closure_invoke + 204
17 libgobject-2.0.0.dylib 0x0000000105d54a54 signal_emit_unlocked_R + 2004
18 libgobject-2.0.0.dylib 0x0000000105d558d0 g_signal_emit_valist + 2240
19 libgobject-2.0.0.dylib 0x0000000105d560c2 g_signal_emit + 130
20 libgobject-2.0.0.dylib 0x0000000105d3eadc g_closure_invoke + 204
21 libgobject-2.0.0.dylib 0x0000000105d54a54 signal_emit_unlocked_R + 2004
22 libgobject-2.0.0.dylib 0x0000000105d558d0 g_signal_emit_valist + 2240
23 libgobject-2.0.0.dylib 0x0000000105d560c2 g_signal_emit + 130
24 libgtk-quartz-2.0.0.dylib 0x0000000104f239ff gtk_real_button_released + 63
25 libgobject-2.0.0.dylib 0x0000000105d3eadc g_closure_invoke + 204
26 libgobject-2.0.0.dylib 0x0000000105d546f2 signal_emit_unlocked_R + 1138
27 libgobject-2.0.0.dylib 0x0000000105d558d0 g_signal_emit_valist + 2240
28 libgobject-2.0.0.dylib 0x0000000105d560c2 g_signal_emit + 130
29 libgtk-quartz-2.0.0.dylib 0x0000000104f236ff gtk_button_button_release + 15
30 libgtk-quartz-2.0.0.dylib 0x0000000104fe0494 _gtk_marshal_BOOLEAN__BOXED + 100
31 libgobject-2.0.0.dylib 0x0000000105d3eadc g_closure_invoke + 204
32 libgobject-2.0.0.dylib 0x0000000105d54b94 signal_emit_unlocked_R + 2324
33 libgobject-2.0.0.dylib 0x0000000105d55b47 g_signal_emit_valist + 2871
34 libgobject-2.0.0.dylib 0x0000000105d560c2 g_signal_emit + 130
35 libgtk-quartz-2.0.0.dylib 0x000000010511b118 gtk_widget_event_internal + 600
36 libgtk-quartz-2.0.0.dylib 0x0000000104fddf42 gtk_propagate_event + 322
37 libgtk-quartz-2.0.0.dylib 0x0000000104fddb37 gtk_main_do_event + 1255
38 libgdk-quartz-2.0.0.dylib 0x000000010538a7b4 gdk_event_dispatch + 84
39 libglib-2.0.0.dylib 0x0000000105dc4c16 g_main_context_dispatch + 326
40 libglib-2.0.0.dylib 0x0000000105dc4fc2 g_main_context_iterate + 514
41 libglib-2.0.0.dylib 0x0000000105dc52ef g_main_loop_run + 191
42 gimp-bin 0x00000001045805b0 app_run + 1056
43 gimp-bin 0x00000001045831ad main + 989
44 libdyld.dylib 0x00007fff7dd5d3d5 start + 1
```https://gitlab.gnome.org/GNOME/gimp/-/issues/3984Copy/Paste retains color of transparent pixels2023-08-18T04:06:57ZGhost UserCopy/Paste retains color of transparent pixelsGIMP version: 2.10.12
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).
Operating System: [Windows 8.1]
Package: [Installer...GIMP version: 2.10.12
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).
Operating System: [Windows 8.1]
Package: [Installer from gimp.org]
# Description of the bug
Copying and pasting Gimp layers to other image editing program leaves “edit history” on to the pasted layer. Drew a red line, deleted red line, drew red line in another spot, copy layer, paste layer to another program, pasted layer shows two red lines.
# Reproduction
Is the bug reproducible? [Always]
Reproduction steps:
* Starting a new file, add a layer (transparent is preferred)
* Make a scribble or doodle on the new layer (the scribble must be a different color to the “transparent” color, [transparent is normally black])
* Copy the layer, and open any other program with an image editor (paint)
Paste the layer onto the program (normally, programs like paint don’t have transparency so you may see the scribble on a black background or whatever background sharing the transparent color option: this is normal)
This is where it doesn’t get normal!
* Back to Gimp, edit the layer in any way as long as the previous scribble is either gone or not in the same spot as before (best to cut the scribble and paste it in the same layer but in a different spot)
* Now copy the layer again and paste it on to your other image editor
…
Expected result:
Like any typical image editor, whatever edits made on to layer, transparent or not, will look exactly the same when copied and pasted to another program. Yes, layers with transparency will not be transparent when moving to a program such as paint, but at least it doesn’t show any “history” so to speak.
Actual result:
Now what happens to me when I do this is the layer I pasted on to the other program, for some reason, has an impression of previous work done to it despite being long removed. So that scribble that you drew and either moved or removed, will appear on the same spot untouched with the edits overlapping it when pasting the gimp layer onto another image program.
This did not happen when using the previous version of Gimp. *I think it was a 2015 version*
Copying and pasting layers from other programs like Krita or Sketchbook does not do similar issues: meaning this is not a problem with my computer.
Pasting Gimp layers to programs that does support transparency has the same effect but without the opaque background. I’ve discovered this error when copying and pasting a gimp layer on to the Clickteam Sprite Editor “*that editor supports transparency*”
Copying from and pasting back into Gimp does not do the same result, it must be pasted to another program.
# Additional information
If you have a backtrace for a crash or a warning, paste it here.https://gitlab.gnome.org/GNOME/gimp/-/issues/3970Surface pro 4 display set to portrait mode gives cursor offset in gimp when u...2023-06-01T19:47:40ZGhost UserSurface pro 4 display set to portrait mode gives cursor offset in gimp when using surface pen.Hi I have a Surface pro 4, which runs windows 10 which is all updated and I am attempting to use the surface pen with no clip with Gimp. When in Landscape mode the surface pen works fine with gimp but when the display mode is changed to ...Hi I have a Surface pro 4, which runs windows 10 which is all updated and I am attempting to use the surface pen with no clip with Gimp. When in Landscape mode the surface pen works fine with gimp but when the display mode is changed to portrait I get an offset from where the pen cursor is and where the draw mark appears in gimp. In Gimp the microsoft input device is set to screen.3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/3968Stroke Path required manual set of Line Style each time2024-03-01T09:07:47ZGhost UserStroke Path required manual set of Line Style each timeIn a long drawing session earlier this week, I found that every time I wanted to Stroke a path, I had to manually open the Line Style selector and re-select the Dash preset to "Line", even though it seemed to show the correct illustratio...In a long drawing session earlier this week, I found that every time I wanted to Stroke a path, I had to manually open the Line Style selector and re-select the Dash preset to "Line", even though it seemed to show the correct illustration to the right of the "Custom" pattern. If I didn't, nothing would be drawn.
Just tried it now, and it remembered my choices from before and drew the stroke properly, first time. But that was a single path in a new empty space. When it was requiring a re-selection every time, I had multiple layers, multiple paths, pasted-in layers, multiple background layers, and hours of complexity. Could that make a difference?
![GIMP_Stroke_Style](/uploads/504641f4f239f4fce588967356ea9035/GIMP_Stroke_Style.JPG)https://gitlab.gnome.org/GNOME/gimp/-/issues/3962GIMP crashes when opening "too many" image files.2023-08-16T09:41:59ZSilverWoodchuck47GIMP crashes when opening "too many" image files.GIMP version: 2.10.12
Operating System: [Windows 7 / 32bit]
Package: [GIMPPortable]
# Description of the bug
GIMP crashes when opening "too many" image files.
# Reproduction
Is the bug reproducible? [Always]
Reproduction steps:
...GIMP version: 2.10.12
Operating System: [Windows 7 / 32bit]
Package: [GIMPPortable]
# Description of the bug
GIMP crashes when opening "too many" image files.
# Reproduction
Is the bug reproducible? [Always]
Reproduction steps:
1. Select a bunch of files in Windows Explorer. In my case: 14 files totaling 27MB
2. Drag said files to an opened instance of GIMP
3. Watch GIMP open a few of the files quickly, then slow to a crawl before crashing.
Expected result:
All files open ready to be edited or some sort of message telling that I'm opening too many files.
Actual result:
Watch GIMP open a few of the files quickly, then slow to a crawl before crashing.
# Additional information
I ran GIMP in "debug mode": gimpportable --verbose --console-messages
The last line shows, as shown in the attachment:
`(gimp-2.10.exe:3284): Glib-ERROR **: 19:06:51.301: ../glib-2.60.4/glib/gmem.c:105: failed to allocate 18241376 bytes`
![error](/uploads/51260c3fb9af919f0eeb1944ab90081f/error.PNG)https://gitlab.gnome.org/GNOME/gimp/-/issues/3951Wrong size when creating a text layer with a size in points2020-03-03T22:49:39ZofnutsWrong size when creating a text layer with a size in pointsGIMP version: 2.10.12
Operating System: Linux
Package: flatpak
# Description of the bug
### In the python-fu console:
Make sure the image is at 72PPI
```
>>> image=gimp.image_list()[0]
>>> pdb.gimp_image_set_resolution(image, 72.,7...GIMP version: 2.10.12
Operating System: Linux
Package: flatpak
# Description of the bug
### In the python-fu console:
Make sure the image is at 72PPI
```
>>> image=gimp.image_list()[0]
>>> pdb.gimp_image_set_resolution(image, 72.,72.)
>>> pdb.gimp_image_get_resolution(image)
(72.0, 72.0)
```
At 72PPI, since there are 72 points in a inch, a point and a pixel should be equiavalent
Create a text layer with a size in pixels
```
>>> layer = pdb.gimp_text_layer_new(image,'ABC','Sans',100.,0)
>>> layer.height
117
```
117 pixels for a 100px font is OK, because the layer height includes line spacing
Create a text layer with a size in points
```
>>> layer = pdb.gimp_text_layer_new(image,'ABC','Sans',100.,1)
>>> layer.height
8383
```
The size is not the same at all.
If we divide this size by 72, we get close to the size in pixels, which is also the size in points (116.43).
So in all likelihood the size we passed was understood as inches and not as points.
Problem is not dependent on font.
# Reproduction
Is the bug reproducible? Always
# Additional information
In case it matters, on my system:
* Pango is 1.38.1
* Cairo is 1.14.6
See also [this problem on StackOverflow](https://stackoverflow.com/questions/57985234/font-size-rendering-is-different-depending-upon-login-using-gimp) which could indicate that the problem is platform dependent.https://gitlab.gnome.org/GNOME/gimp/-/issues/3949Image Map plug-in selects wrong areas2021-08-08T19:18:55ZGhost UserImage Map plug-in selects wrong areasGIMP version: 2.10.10
Operating System: Windows (maybe other OSs too, but I don't have other)
Package: Installer from gimp.org
# Description of the bug
The Plugin "Image Map" often selects wrong area. You make click on the one area, ...GIMP version: 2.10.10
Operating System: Windows (maybe other OSs too, but I don't have other)
Package: Installer from gimp.org
# Description of the bug
The Plugin "Image Map" often selects wrong area. You make click on the one area, but the program selects another area.
# Reproduction
Is the bug reproducible? Randomly and often
Reproduction steps:
1. Load in GIMP the file "Deutschland_Landschaften_Städte_Flüsse.jpg"
2. Start Image Map plugin (Filters/Web/Image Map)
3. Open in the Image Map the map-file "Deutschland_Landschaften_Städte_Flüsse.map"
4. Try to click on the several areas for selection
Some areas will be selected correctly but some areas not! Sometime you have to click many times on the area for the right selection. Sometimes you cannot select the area you will.
# Additional information
The areas at the end in the map-file are always corectly select. If you in text editor moves the area at the end of the map-file and load this changed map-file, the area will be selected corectly.
![Deutschland_Landschaften_Städte_Flüsse](/uploads/3f8400f922faf61e42012646b76f9870/Deutschland_Landschaften_Städte_Flüsse.jpg)[Deutschland_Landschaften_Städte_Flüsse.map](/uploads/5402aae98cce3433f1c18ce850965c52/Deutschland_Landschaften_Städte_Flüsse.map)