Strange Affinity Photo 1.10 Freeze on Windows (apparently after update to latest Nvidia driver?)

[i5963c]

I encounter regular freezes of Affinity Photo in recent days. These problems were certainly not happening last week!

My system setup is as follows: Windows 10 Pro (up to date), AMD Ryzen 3090X CPU, Nvidia RTX3060 GPU (with 12 GB dedicated GPU memory, driver update of last week), 32 GB of RAM, Affinity Photo 1.10.0 (latest 'official' version), HW acceleration ON, Wacom Intuos PTK640 tablet (drivers up to date).

This setup worked flawless till last week (apart from a different bug that I reported recently in relation to pattern layers, but this bug is not related to the workflow that triggers my actual problems).

Context:

I'm working on a large photo restoration project. It includes many old photos (some of them almost 100 years old), that I've digitized with a high resolution camera and a macro lens.

My standard workflow is as follows:

• Capturing of the pictures happens via tethering in Capture One. B&W conversion, perspective correction, cropping, and, if required, some dynamic range adjustments also via Capture One.
• Then, further processing in Affinity Photo (via the 'Edit with...' menu option of Capture One). The transfer between both applications happens via 16 bit TIFF files with the AdobeRGB profile.
• In Affinity Photo, I duplicate the background layer. To this layer, I (optionally) apply a 'Dust and Scratches' live filter that I tune to remove some of the finest scratches (common problem with old photos, easily visible with a sharp macro lens). If appropriate, a mask is applied to the live filter (e.g. to avoid loss of sharpness around the eyes, which I may restore manually in the next step - see below)
• Next, on top of the duplicate background layer, I create an empty pixel layer that I use to remove further blemishes in a non-destructive way, via the Inpaint brush (with the 'Source' parameter set to 'Current Layer and Below').
• Depending on the picture, I sometimes apply further external filters from within Affinity Photo (Silver Efex Pro and/or Topaz Sharpen AI), after first 'merging all visible layers' to make sure that the external filter is applied to the 'combined' native Affinity layers.

As said, till last week, this process worked perfect.

Now, this same process makes that Affinity Photo freezes after some strokes with the Inpaint brush. The only thing that I changed for my system (in recent days) is the update to the most recent version of the Nvidia drivers (from version 471.41 to version 471.68).

Whenever I execute my regular workflow, I notice (via the Windows Task Manager) that the Dedicated GPU memory usage grows very fast from the initial 'stable' position (around 2 GB used) towards its limit (just below 12 GB), and then, Affinity Photo freezes (the message 'Not responding' appears in the top-left corner). It doesn't crash (so, no dump files), but it just remains in an endless frozen state. The only way to get out of it, is to kill the application.

Further findings:

If I don't apply an empty pixel layer to draw strokes with the Inpaint brush, but if I apply the Inpaint strokes directly on the duplicated background layer (= destructive editing), there is still an increase in the memory usage, but this increase is much lower, and - so far - I haven't been able to freeze Affinity Photo. To me, this looks like a memory problem in Affinity Photo.

As a next experiment, I disabled HW acceleration. In this situation, Affinity Photo doesn't increase the usage of the dedicated GPU memory, but what is very strange in this scenario (at least to me) is that the GPU (3D graph in Windows Task Manager) shows a percentage of up to 33% whenever I use the Inpaint brush. I would expect that the GPU is not used when HW acceleration is switched OFF?

Because the above workflow worked perfect till last week, and the only system change (I can remember) is the driver update of the Nvidia GPU, I wonder whether there is a way that I can downgrade this driver? If this is feasible, thanks to let me know whether this is advised, and how it can be done in a safe way.

Many thanks.

 

 

[Komatös]

Hello @i5963c,

The high GPU 3D performance is due to the real-time display of the UI of the Affinity apps and the tools and live filters.

If you still have an older GPU driver, which obviously does not cause any problems, you should switch back to this one. 

Otherwise, if nothing works anymore, please make a memory dump via the task manager for support.

Right click on the taskbar --> select Taskmanager --> right click on Photo.exe --> create image file.

[Lem3]

Use this page to search for recent NVIDIA drivers:

https://www.nvidia.com/en-us/geforce/drivers/

[Gregory St. Laurent]

3 hours ago, i5963c said:

I encounter regular freezes of Affinity Photo in recent days. These problems were certainly not happening last week!

My system setup is as follows: Windows 10 Pro (up to date), AMD Ryzen 3090X CPU, Nvidia RTX3060 GPU (with 12 GB dedicated GPU memory, driver update of last week), 32 GB of RAM, Affinity Photo 1.10.0 (latest 'official' version), HW acceleration ON, Wacom Intuos PTK640 tablet (drivers up to date).

This setup worked flawless till last week (apart from a different bug that I reported recently in relation to pattern layers, but this bug is not related to the workflow that triggers my actual problems).

Context:

I'm working on a large photo restoration project. It includes many old photos (some of them almost 100 years old), that I've digitized with a high resolution camera and a macro lens.

My standard workflow is as follows:

• Capturing of the pictures happens via tethering in Capture One. B&W conversion, perspective correction, cropping, and, if required, some dynamic range adjustments also via Capture One.
• Then, further processing in Affinity Photo (via the 'Edit with...' menu option of Capture One). The transfer between both applications happens via 16 bit TIFF files with the AdobeRGB profile.
• In Affinity Photo, I duplicate the background layer. To this layer, I (optionally) apply a 'Dust and Scratches' live filter that I tune to remove some of the finest scratches (common problem with old photos, easily visible with a sharp macro lens). If appropriate, a mask is applied to the live filter (e.g. to avoid loss of sharpness around the eyes, which I may restore manually in the next step - see below)
• Next, on top of the duplicate background layer, I create an empty pixel layer that I use to remove further blemishes in a non-destructive way, via the Inpaint brush (with the 'Source' parameter set to 'Current Layer and Below').
• Depending on the picture, I sometimes apply further external filters from within Affinity Photo (Silver Efex Pro and/or Topaz Sharpen AI), after first 'merging all visible layers' to make sure that the external filter is applied to the 'combined' native Affinity layers.

As said, till last week, this process worked perfect.

Now, this same process makes that Affinity Photo freezes after some strokes with the Inpaint brush. The only thing that I changed for my system (in recent days) is the update to the most recent version of the Nvidia drivers (from version 471.41 to version 471.68).

Whenever I execute my regular workflow, I notice (via the Windows Task Manager) that the Dedicated GPU memory usage grows very fast from the initial 'stable' position (around 2 GB used) towards its limit (just below 12 GB), and then, Affinity Photo freezes (the message 'Not responding' appears in the top-left corner). It doesn't crash (so, no dump files), but it just remains in an endless frozen state. The only way to get out of it, is to kill the application.

Further findings:

If I don't apply an empty pixel layer to draw strokes with the Inpaint brush, but if I apply the Inpaint strokes directly on the duplicated background layer (= destructive editing), there is still an increase in the memory usage, but this increase is much lower, and - so far - I haven't been able to freeze Affinity Photo. To me, this looks like a memory problem in Affinity Photo.

As a next experiment, I disabled HW acceleration. In this situation, Affinity Photo doesn't increase the usage of the dedicated GPU memory, but what is very strange in this scenario (at least to me) is that the GPU (3D graph in Windows Task Manager) shows a percentage of up to 33% whenever I use the Inpaint brush. I would expect that the GPU is not used when HW acceleration is switched OFF?

Because the above workflow worked perfect till last week, and the only system change (I can remember) is the driver update of the Nvidia GPU, I wonder whether there is a way that I can downgrade this driver? If this is feasible, thanks to let me know whether this is advised, and how it can be done in a safe way.

Many thanks.

 

 

I experienced freezing also when I update to the 471.41 drivers, I reverted back to an older driver and my freezing disappeared.

[i5963c]

@Komatös, Thanks for clarifying the reason why I see load on the GPU while HW acceleration is switched off. I tried to create a dump file via the Task Manager while my system hangs, but I didn't succeed. My system was completely unreactive.

@Komatös, @Lem3, @Gregory St. Laurent, Thanks to all for the feedback on how to downgrade my Nvidia drivers.

I actually downgraded my GPU driver. First, from 471.68 to 471.41, but this didn't help with the freezes. I then further downgraded (clean install) to an even earlier version (462.59) for which I still had the download files on my system. This did (again) not help to resolve my problem.

I could not understand why my workflow (see my initial post) seemed to work last week, and why it blocks this week. I then noticed (almost by accident, by ALT-clicking on the inpaint layer) that when applying the inpaint brush, this brush was apparently based on one of the brushes in the 'Acrylics' category, i.s.o. my normal 'Basic' category. Apparently, Affinity Photo always applies the last used brush layout. I wasn't aware of this, and with the inpaint brush there is also no difference in how this brush appears on screen. It just draws a red zone on the area that must be restored, irrespective of the texture of the 'active' brush. I can understand that drawing brushes with a texture of the 'Acrylics' category may require more system resources than drawing with a simple round brush of the 'Basic' category.

So, I tested again (after first having upgraded my GPU drivers back to the most recent version) with a simple 'Basic' inpaint brush. This appears to work smoother than with an 'Acrylic' brush. But I kept monitoring the RAM and GPU memory allocation, and I noticed a number of things:

• Despite the use of a 'simple' 'Basic' brush, the memory usage is still accumulating, albeit at a lower speed.
• There also seems to be a significant difference in the use of a mouse and the use of a tablet as input devices for the inpaint process. When applying a mouse stroke, the memory usage first increases and then decreases again. After a number of brush strokes, the memory usage increases (however at a slow pace). When using the tablet pen, the memory usage increases with every pen stroke (sometimes around 0.3 GB per stroke!). This way, it's easily possible to use the full amount of my dedicated GPU memory (12 GB). The reason for the difference in memory usage increase between mouse and tablet pen may be related to the fact that pen strokes happen at a much higher frequency than moving and dragging with a mouse. But, that's of course one of the key reasons to use a tablet with a pen i.s.o. a mouse!
• There seems to be some 'randomness' in the behavior, without a clear pattern. In a number of cases, the workflow scenario seems to 'work OK'. Ten minutes later, the memory usage pattern as described above reappears...
• If I save the document halfway (including the history!), close it and then reopen it, I notice that the memory usage is much lower than prior to saving. This appears to indicate that there are memory leaks in the code (i.e. memory is not released, although it is no longer required).
• As a further evidence of these leaks, I've also noticed that (in some cases, not always, and no pattern recognized!) the allocated memory does not decrease when documents are closed.
• I did some test with different settings for the Tablet Input Method (Windows Ink, High Precision), but this didn't appear to make a difference.

 

[Komatös]

In fact, it takes quite a long time for the Affinity programmes to free up the memory. On a PC/laptop with <= 8 GB RAM and possibly an integrated GPU, this can quickly lead to a programme standstill.

[NotMyFault]

There are bug reports from other users who lead to the assumption of a potential memory leak in 1.10.

Occasionally i see a similar issue, but not reproducible.

[i5963c]

3 hours ago, Komatös said:

In fact, it takes quite a long time for the Affinity programmes to free up the memory. On a PC/laptop with <= 8 GB RAM and possibly an integrated GPU, this can quickly lead to a programme standstill.

@Komatös,

Thanks for your feedback, but my machine has 32GB of RAM, plus 12GB of dedicated memory on my GPU. This is a completely different setting than the type of system configuration that you describe in your message. I believe that my setup should be more than adequate to run the type of workflow that I described without any issues.

To me, the behavior that I encounter really points towards a memory leak in the code. I sincerely hope that it gets the attention of the developers and that it can be fixed asap.

[Komatös]

My feedback should also be seen more as a general comment, and as a small blow with the roof batten for the developers 😆 🖖🏼

[i5963c]

2 hours ago, NotMyFault said:

There are bug reports from other users who lead to the assumption of a potential memory leak in 1.10.

Occasionally i see a similar issue, but not reproducible.

@NotMyFault,

Thanks for your reaction. I'm not sure to which bug reports you refer specifically, as I'm not aware of the behavior of the memory allocation for each of the many outstanding bug reports. I'm quite new on this forum, so I have no reference basis, but do you believe that this (potential) memory leak issue is specific for the 1.10 release, or is this an issue that exists already since long?

If it would indeed be related to the most recent 1.10 release, it could probably be a recommendation to downgrade to version 1.9.2, rather than the 'standard answer' to deactivate the HW acceleration? I would appreciate to know your opinion on this?

[NotMyFault]

Tricky to give an advice. I would try to use the latest beta (before 1.9.2 retail was published) which can be installed in parallel to test this. Affinity said occasionally that „final“ beta and retail are code-wise identical, they use same version id.

Similar, a new 1.10. beta could be worth testing.

it totally depends on your risk appetite and how much time you can dedicate testing  different versions.

1.9.2 seems a lot more stable to me than current 1.10.

[Seaway]

I also encountered this problem, my graphics card is RTX2080ti GPU memory 11GB.
Windows 10, AMD Ryzen 3900X CPU, 64 GB of RAM.
I observed the use of GPU memory in 1.10.1.1142, and it was normal at first, occupying around 2~4G of GPU memory.
After operating for a period of time, a crash occurs, and the GPU memory 10G is instantly occupied.
This did not happen in 1.92.
1.10.1 If you turn off hardware acceleration, the problem no longer occurs.

[RichardMH]

Have a look in 

%APPDATA%\Affinity\Photo\1.0\Log.txt

Its possibly full of error messages.

 

 

 

[i5963c]

3 hours ago, RichardMH said:

Have a look in 

%APPDATA%\Affinity\Photo\1.0\Log.txt

Its possibly full of error messages.

 

 

 

Hello @RichardMH,

Thanks for your reply.

I looked into my Log.txt file, and this file is almost empty. It only contains some reference data for my GPU (and to a 'Microsoft Basic Render Driver', not sure what this is).

Certainly no error messages in this file...

 

Kind regards.

[Bussty]

I'm having similar issues. Log file attached and noticed this warning...

 

Attempting to create Direct3D device on default adapter
Setting screen DPI to 113.413953488372 (scale = 2.5)
[OpenCL] Error -11 (485): Could not build program!
[OpenCL] Error -11 (485): Could not build program!
[OpenCL] Error -11 (485): Could not build program!
[OpenCL] Error -11 (485): Could not build program!
[OpenCL] Error -11 (485): Could not build program!
[OpenCL] Error -11 (485): Could not build program!
[OpenCL] Error -11 (485): Could not build program!
[OpenCL] Error -11 (485): Could not build program!
[OpenCL] Error -11 (485): Could not build program!
[OpenCL] Error -11 (485): Could not build program!

 

Any ideas?

 

Many thanks 

 

Andrew

Log.txt