Heal tool in GIMP very slow

I’m frequently using the GIMP heal tool on photos with a resolution exceeding 3000x2000. With increasing size of the heal tool (starting approximately at >100) it gets incredibly slow and unresponsive. I’m using GIMP (recently upgraded to 2.99.16) under Ubuntu 22.04 on a Ryzen 7 5800 with a Radeon rx 6700 xt. With 32 GB, memory should also be sufficient. Activation or deactivation of OpenCL makes no difference.
In contrast to the heal tool the clone tool works perfect.

Does anybody have similar problems or a solution?

I only had difficulty when I made the tool a crazy size of 500. 100 was no trouble. In the dockable dialogs option the last one in the list is called dashboard. Installing that may reveal what is happening to your resources and causing the slow down. I am on windows, so I can not easily test the open CL options. I do not on darktable that unsupported graphics cards can causes crashes, but that is not what you are describing

Thank you for your reply.
The dashboard shows that utilization of all resources is between 5 and 15%. So, limited memory or computing power does not seem to cause this problem at a first glance. However, when looking at the system monitoring (Linux) I see that one core is fully utilized during use of the heal tool. It seems that the heal tool does not make use of multiple cores or the GPU. Not surprisingly the utilization of the core used is correlated with the brush size. Utilization is below 100% with smaller brush sizes. Starting at app. size 100 utilization is 100%.

For some image corrections I did not consider the use of the heal tool with a size exceeding 100 as “crazy”. But as with most mental problems, you are the last person to realize there is a problem :wink:

Based on your reply and missing resonance in the forum I assume that for most users it’s not an issue.

Hi Gerd,
the site has been down for many days, so there may be others experiencing problem.

Hello Terry

Thanks. I’m quite convinced that I’m not the only one who is misusing the heal tool by using a “crazy” brush size. I have made a report on Gitlab:

Let’s see if there will be a follow up.


Um… GIMP 2.10.8 flatpak… Try to update it > in terminal
flatpak update org.gimp.GIMP
Because we are at 2.10.34 nowadays and there are many bug fixes and new filters especially from 2.10.20/22 you might love them :wink:

I just tested here on 2.10.30 (ubuntu, 22.04.2, Intel i7, 32gb) and didn’t see any problems (even up to a size of 500). Wonder if an update might have fixed something for you as @PixLab mentioned.

The visible part of the conversation in GitLab is misleading. The thread was started four years ago by another person.
I’m using currently flatpak GIMP 2.99.16 beta on Ubuntu 22.04.
I’ll try 2.10.30 again. In the past I had issues with the 2.10.xx versions and my AMD graphics card.

GIMP does not use graphic card, only CPU.

I have just tried flatpak GIMP 2.10.34. The heal tool works better. Still sluggish, but much faster compared to 2.99.16.
The problem with 2.10.34 are strange green artifacts appearing in most menus (cf. screenshot).
In 2.99.16 I don’t see this artifacts.
Switching OpenCL support off in 2.10.34 makes no difference

when you input clinfo in the terminal what does it said? (you might need to install clinfo sudo apt install clinfo)

Output of clinfo:

umber of platforms 1
Platform Name AMD Accelerated Parallel Processing
Platform Vendor Advanced Micro Devices, Inc.
Platform Version OpenCL 2.1 AMD-APP (3452.0)
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_icd cl_amd_event_callback
Platform Extensions function suffix AMD
Platform Host timer resolution 1ns

Platform Name AMD Accelerated Parallel Processing
Number of devices 1
Device Name gfx1031
Device Vendor Advanced Micro Devices, Inc.
Device Vendor ID 0x1002
Device Version OpenCL 2.0
Driver Version 3452.0 (HSA1.1,LC)
Device OpenCL C Version OpenCL C 2.0
Device Type GPU
Device Board Name (AMD) AMD Radeon RX 6700 XT
Device PCI-e ID (AMD) 0x73df
Device Topology (AMD) PCI-E, 0000:2f:00.0
Device Profile FULL_PROFILE
Device Available Yes
Compiler Available Yes
Linker Available Yes
Max compute units 20
SIMD per compute unit (AMD) 4
SIMD width (AMD) 32
SIMD instruction width (AMD) 1
Max clock frequency 2855MHz
Graphics IP (AMD) 10.3
Device Partition (core)
Max number of sub-devices 20
Supported partition types None
Supported affinity domains (n/a)
Max work item dimensions 3
Max work item sizes 1024x1024x1024
Max work group size 256
Preferred work group size (AMD) 256
Max work group size (AMD) 1024
Preferred work group size multiple (kernel) 32
Wavefront width (AMD) 32
Preferred / native vector sizes
char 4 / 4
short 2 / 2
int 1 / 1
long 1 / 1
half 1 / 1 (cl_khr_fp16)
float 1 / 1
double 1 / 1 (cl_khr_fp64)
Half-precision Floating-point support (cl_khr_fp16)
Denormals No
Infinity and NANs No
Round to nearest No
Round to zero No
Round to infinity No
IEEE754-2008 fused multiply-add No
Support is emulated in software No
Single-precision Floating-point support (core)
Denormals Yes
Infinity and NANs Yes
Round to nearest Yes
Round to zero Yes
Round to infinity Yes
IEEE754-2008 fused multiply-add Yes
Support is emulated in software No
Correctly-rounded divide and sqrt operations Yes
Double-precision Floating-point support (cl_khr_fp64)
Denormals Yes
Infinity and NANs Yes
Round to nearest Yes
Round to zero Yes
Round to infinity Yes
IEEE754-2008 fused multiply-add Yes
Support is emulated in software No
Address bits 64, Little-Endian
Global memory size 12868124672 (11.98GiB)
Global free memory (AMD) 12566528 (11.98GiB) 12566528 (11.98GiB)
Global memory channels (AMD) 6
Global memory banks per channel (AMD) 4
Global memory bank width (AMD) 256 bytes
Error Correction support No
Max memory allocation 10937905968 (10.19GiB)
Unified memory for Host and Device No
Shared Virtual Memory (SVM) capabilities (core)
Coarse-grained buffer sharing Yes
Fine-grained buffer sharing Yes
Fine-grained system sharing No
Atomics No
Minimum alignment for any data type 128 bytes
Alignment of base address 1024 bits (128 bytes)
Preferred alignment for atomics
SVM 0 bytes
Global 0 bytes
Local 0 bytes
Max size for global variable 10937905968 (10.19GiB)
Preferred total size of global vars 12868124672 (11.98GiB)
Global Memory cache type Read/Write
Global Memory cache size 16384 (16KiB)
Global Memory cache line size 64 bytes
Image support Yes
Max number of samplers per kernel 29663
Max size for 1D images from buffer 134217728 pixels
Max 1D or 2D image array size 8192 images
Base address alignment for 2D image buffers 256 bytes
Pitch alignment for 2D image buffers 256 pixels
Max 2D image size 16384x16384 pixels
Max 3D image size 16384x16384x8192 pixels
Max number of read image args 128
Max number of write image args 8
Max number of read/write image args 64
Max number of pipe args 16
Max active pipe reservations 16
Max pipe packet size 2347971376 (2.187GiB)
Local memory type Local
Local memory size 65536 (64KiB)
Local memory size per CU (AMD) 65536 (64KiB)
Local memory banks (AMD) 32
Max number of constant args 8
Max constant buffer size 10937905968 (10.19GiB)
Preferred constant buffer size (AMD) 16384 (16KiB)
Max size of kernel argument 1024
Queue properties (on host)
Out-of-order execution No
Profiling Yes
Queue properties (on device)
Out-of-order execution Yes
Profiling Yes
Preferred size 262144 (256KiB)
Max size 8388608 (8MiB)
Max queues on device 1
Max events on device 1024
Prefer user sync for interop Yes
Number of P2P devices (AMD) 0
Profiling timer resolution 1ns
Profiling timer offset since Epoch (AMD) 0ns (Thu Jan 1 09:00:00 1970)
Execution capabilities
Run OpenCL kernels Yes
Run native kernels No
Thread trace supported (AMD) No
Number of async queues (AMD) 8
Max real-time compute queues (AMD) 8
Max real-time compute units (AMD) 20
printf() buffer size 4194304 (4MiB)
Built-in kernels (n/a)
Device Extensions cl_khr_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_fp16 cl_khr_gl_sharing cl_amd_device_attribute_query cl_amd_media_ops cl_amd_media_ops2 cl_khr_image2d_from_buffer cl_khr_subgroups cl_khr_depth_images cl_amd_copy_buffer_p2p cl_amd_assembly_program

NULL platform behavior
clGetPlatformInfo(NULL, CL_PLATFORM_NAME, …) No platform
clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, …) No platform
clCreateContext(NULL, …) [default] No platform
clCreateContext(NULL, …) [other] Success [AMD]
clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT) Success (1)
Platform Name AMD Accelerated Parallel Processing
Device Name gfx1031
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) Success (1)
Platform Name AMD Accelerated Parallel Processing
Device Name gfx1031
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) Success (1)
Platform Name AMD Accelerated Parallel Processing
Device Name gfx1031

The artifacts in GIMP seem to be a known issue and related to AMD GPUs:

Oh… OK, so it’s a known issue :+1:

There is an appimage, overthere Reddit - Dive into anything

I tried it it’s a nice one, you can try it, advantage of appimage, no install, just do not open it while a GIMP session is on, maybe you won’t have anymore the green artefact as in the report it says that it happens with “flatpak” :wink:

I have just upgraded to the new version of AMD GPU driver (Radeon™ Software for Linux® version 23.10.2 for Ubuntu 22.04.2). The issue with the green artifacts in GIMP menus is resolved.
The heal tool with larger brush sizes in GIMP 2.10.34 is still slow, but usable.
I hope the performance issues of the heal tool in 2.99.xx will be resolved before 3.0 is released.

1 Like

Thanks for the tip with the appimage. The appimage GIMP 2.10.34 works nicely.
The heal tool is slow, but usable and no green artifacts in menus.

GIMP 2.99.16 has issues with the heal tool. It is not only slow, but shows streaks/smears when used.

Just a thought, about the slow heal tool, what is the spacing in the Tool Options?
At 1 mine is slow, but at 2 it’s like magic, it got way faster


Great tip. The heal tool is much faster.
With the settings you showed in your screenshot also GIMP 2.99.16 works fine.

I’ll correct my feedback to the GIMP developers in Gitlab.
At least it helped to resolve the issue with the green artifacts. They have closed the case as not GIMP, but the AMD GPU drivers have been the culprit.

Thanks a lot.

The only bad news now is that I’m going to be messing up even more photos with the heal tool :slight_smile: