Jump to content
4Lakes

Windows Affinity Photo 32-bit to 16-bit takes >8 minutes, CS6 does this in ~5 seconds

Recommended Posts

Summary: The image is 4988 x 2814px, 14.04 MB, 7 layers: 1 background pixel layer, 5 masked curve adjustment layers, 1 B&W layer in RGBA/32 (HDR), ProPhoto RGB (Linear). Using Document, Color Format to convert this image in 32-bits to 16-bits RGBA/16 - ProPhotoRGB takes over 8 minutes of processing time on a relatively well-spec'ed machine. Adobe Photoshop CS6 using the same image in 32-bits, similar number of layers and same color space to 16-bits in same color space takes about 5 seconds. Affinity Photo takes an inordinately long time that is not acceptable for the workflow.

Details:

The machine:

Windows 7 Professional 64-bit up-to-date per Windows Update

Service Pack 1

Processor: Intel Core i7-3770 CPU @ 3.40GHz

32.0 GB RAM

Windows Experience Index 7.7 (on a scale of 1.0 to 7.9)

Graphics card: GeForce GTX 970 version 385.69

NVIDIA Control Panel reports (see attached PNG)

More details on machine in attached PNG. Disk C: is a SSD and has both Affinity Photo and Adobe Photoshop CS6.

 

The software:

Affinity Photo 1.6.1.93

RAM Usage limit 25,599 MB

Renderer: Default (NVIDIA GeForce GTX 970)

Adobe Photoshop CS6 64-bit, using the NVIDIA GeForce GTX 970)

Using Photo Affinity's Document, Color Format, RGB 16 bit it takes slightly over 8 minutes to have hourglass disappear and the RGBA/16 - ProPhotoRGB to appear. During this time Windows Task Manager reports (see attached PNG's). CPU utilization by Affinity Photo is essentially 100% during this time.

Trying 32-bit to 16-bit conversion on the same image in the beta version 1.6.1.93 (Beta) does not result in Task Manager reporting "Affinity Photo (not responding)" but if anything the conversion takes even longer at about 8 minutes 55 seconds.

Doing this 32-bit to 16-bit conversion of same image and same color spaces in Photoshop CS6 takes about 5 seconds of processing time.

 

Graphics card details.png

Machine Info 1.pdf

Not responding 32 to 16 bit, TaskManager1.PNG

Not responding 32 to 16 bit, TaskManager2.PNG

Share this post


Link to post
Share on other sites

I have similar issue with some files when I change the export profile from from PNG-24 to PNG-8. It gets stuck on calculating the size (didn't wait 8 minutes) with high CPU (90%). If I try to export it in PNG-8, it gets stuck (again, didn't wait 8 mins).

It happens with this image (attached), nothing else added, not even a single curve.

lights-night-alcohol-party.jpg

Share this post


Link to post
Share on other sites

Can do but the .afphoto file is about 225 MB and I do not want to upload it to a public forum. I recall Affinity can set up a DropBox or something similar which would be OK. Please advise, but I need to get some sleep first.

Thanks for the very prompt response.

Share this post


Link to post
Share on other sites
10 minutes ago, arcador said:

I have similar issue with some files when I change the export profile from from PNG-24 to PNG-8. It gets stuck on calculating the size (didn't wait 8 minutes) with high CPU (90%). If I try to export it in PNG-8, it gets stuck (again, didn't wait 8 mins).

It happens with this image (attached), nothing else added, not even a single curve.

lights-night-alcohol-party.jpg

 

PNG-8 is harder work as it has to make an optimised 256 colour palette. 32bit to 16bit should be very quick though.

 

Share this post


Link to post
Share on other sites
2 hours ago, 4Lakes said:

Can do but the .afphoto file is about 225 MB and I do not want to upload it to a public forum. I recall Affinity can set up a DropBox or something similar which would be OK. Please advise, but I need to get some sleep first.

Thanks for the very prompt response.

 

Hi, you can upload the file here - https://www.dropbox.com/request/9uJPdkfRxx5A05zLW8Tc

That's a private link, only I will be able to download it, and once I've investigated, I will delete the file.

Share this post


Link to post
Share on other sites

Mark,

A problematic file #2 is being uploaded to the dropbox link you provided as I type this. This file #2 is a new one I made using another 5-shot bracket from the same photography session using the same camera. I did the complete process from opening the 5 RAW files for HDR through adding the masked curve adjustment layers and a B&W layer in one session today.

Interestingly, after I had done all the processing on file #2, I tried the Document, Color Format, RGB 16 conversion and Affinity Photo did this in a few seconds. Puzzled, I closed file #2, opened the previous problem file #1, did Document, Color Format, RGB 16 conversion and, as before, this took several minutes with the CPU at near 100%. I thought to send you both this original file #1 and the file #2 I created today but then I thought to close file #1, re-open file #2, and try Document, Color Format, RGB 16 conversion a second time. This time the conversion took several minutes, just as file #1 had taken.

Thinking over what might have some bearing on this different behavior, I think I used the History panel to go back to the 32-bit version after the initial rapid conversion to 16-bits. I am certain I did NOT use the Document, Color Format menu to convert the 16-bit back to 32-bit. I also had one crash while working on file #2. This crash has occured several times before and is associated with deleting points on a curve adjustment layer. As before, I sent the automatically generated crash report to Affinity with my email address. Unfortunately, I am not certain if the crash was before or after the initial rapid 32-bit to 16-bit Color Format conversion of file #2.

If needed, I can go through another 5 bracket RAW to 32-bit HDR, add some curves and a B&W adjustment layers, and then try Document, Color Format, RGB 16 conversion. This time I will save the document with the File, Save History With Document option that I just noticed today. Perhaps having the history of the process will help you find the problem

The uploaded file #2 is named _1120304-308, 32bitHDR.afphoto.

Regards,

Jim

Share this post


Link to post
Share on other sites
On 25/11/2017 at 7:50 AM, 4Lakes said:

Mark,

A problematic file #2 is being uploaded to the dropbox link you provided as I type this.

Regards,

Jim

 

Hi Jim, I've tried the file you uploaded, but when I attempted 32=>16bit conversion, the process was instant.

Share this post


Link to post
Share on other sites

Mark,

Well this is frustrating. I opened the file and tried the 32-bit to 16-bit conversion and it again took minutes (I used End Task in Task Manager after a minute or two). Since Affinity can not have every possible combination of operating system, CPU, graphics card, etc. I went to Edit, Preferences, Performance, Renderer and changed from the NVIDIA GeForce GTX 970 to WARP and restarted Affinity Photo. Opened the file and again 32-bit to 16-bit took minutes before I again used End Task in Task Manager. Could you check on your end if changing the Renderer to WARP should take the graphics card out of the conversion and thus rule out the GTX 970 as a possible source for the problem?

I also updated the graphic's card driver but problem remains. I deleted all the layers from the file, problem remains.

Is there anything I can do on my end or send to you that would be helpful in troubleshooting this? Task Manager offers the option of creating a Dump File (1.47 GB) which I could send to you or I can take screen shots of any of Task Manager's tabs (Processes, Services, Performance; I doubt the Networking or Users tabs would help).

Regards,

Jim

Share this post


Link to post
Share on other sites

Hi Jim, changing the renderer won't make any difference, as that is only used for presenting the final document to the screen, it doesn't participate in the editing of documents.

 

Just out of interest, if you start Windows in Safe Mode, and then attempt the same thing, is it still as slow?

Share this post


Link to post
Share on other sites

Mark,

Progress!

First trial of Windows Safe Mode was loaded with network drivers because the file in question is on a network drive (or rather, drives since it is a RAID). Document, Color Format, 32-bit RGB to 16-bit RGB had the same multi-minute 100% CPU utilization until I ended the task with Windows Task Manager. Thorough person that I am, I then copied the problem file to a local disk and re-booted but in Windows Safe Mode without network drivers. The 32-bit to 16-bit conversion completed in several seconds. Closing the file without saving it in 16-bit and then re-opening the 32-bit file worked a second, third, etc. time consistently!

Next I rebooted Windows 7 Professional 64-bit in its standard mode. In short, Affinity did the  32-bit to 16-bit RGB color format conversion in 1-2 seconds consistently and repeatedly as long as the image file was opened from either of my two local hard drives (I did not try the local SSD drive C:). Every time the image file was opened from the network drive, it was 100% CPU utilization for minutes. When you successfully converted the file from 32-bit to 16-bit without problems, was it on a local drive or a network drive?

I will send you details on the network and RAID as soon as I contact my son, the IT professional, who set up and maintains the network and drives. Is there anything in particular you would like to know about the network architecture and the RAID drive? I know the drive sends a text message to him if any problems are detected and has been up and running at least 2 years without problems. It is used by multiple programs including Photoshop CS6, Lightroom 6, Bridge, Adobe Acrobat, LibreOffice, Capture One 9 and now 10, Luminar 2018 (as limited as the current Windows version is), VueScan x64, Firefox, Internet Explorer, NikonScan 4 (modified driver to get that to work under Win 7 64-bit), and Zerene Stacker 64-bit (focus stacking program). Essentially all non-program files are stored on the network RAID including Lightroom's backup catalog (my son got that to work on a network drive despite Adobe stating it can not be done).

Regards,

Jim

P.S. This accounts for why, in my previous post, the 32-bit to 16-bit conversion worked on a file that was not yet saved. When I saved the file on the network and then re-opened it, conversion took about 8 minutes.

 

Edited by 4Lakes
addded Firefox to programs used, P.S.

Share this post


Link to post
Share on other sites

Hi, thanks for the detailed information. When I tried it, it was on a local drive. I imagine the problem is caused by the fact that we don't fully load files into memory (as they can be many gigabytes in size), so we only partially load files (could perhaps only be 5% of the original file for example). So when you perform that operation it's got to send data back and forth across the network. It's using 100% CPU because each core is sat spinning waiting for more data to come in.

 

We'll try to replicate the scenario here, to see if things could be improved, but I would recommend working on the file locally, then transferring to your network RAID when you finish a session.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×