Last night I installed PhotoLab 10 trial on my Surface 7 ARM laptop and it took a very long time, mostly associated with the myriad AI models that needed to be installed. This morning I got an “Optimising AI Models 0/1“ message that sat there for about 5 minutes before getting to the Learning Centre screen.
I now see a “Full preview in progress“ message each time I load an OM System ORF file and PhotoLab gets stuck for 30 to 60 seconds before I can do anything else. I have both the “Enable high quality preview“ and “Enable DeepPrime rendering“ options turned off. These tests were conducted using the PhotoLab 10 sample images rather than my own.
This is much longer than PhotoLab 9.12 Build 772, which I have just installed and where I have both performance options turned on.
Sadly, PhotoLab continues to run as an AMD/Intel x64 application rather than as a native ARM executable, and this is likely partly responsible for the slowness. For comparison, Photoshop and Lightroom both open in 1 to 2 seconds and are very responsive, as are other applications on the laptop.
Hopefully DXO can address these issues and make ARM laptops first class devices like Intel/AMD devices.
I would think the fact that Apple’s chips are ARM-based, and PL 10 is stable and fast on my Mac mini M4, that they have at least a partial code base already. But I’m not a software engineer. Maybe it’s a resource issue.
“Apple’s M-series chips are custom-designed system-on-a-chip (SoC) processors built using ARM-based architecture. Marking a transition away from Intel’s x86 architecture, Apple designed these processors to integrate the CPU, GPU, memory controller, and machine-learning Neural Engine into a single physical package.”
I asked Dr. Know about this, and this was the response (Dr. Know is AI and can make mistakes):
“The disparity between DxO PhotoLab’s performance on Apple Silicon and its absence on Windows ARM comes down to platform standardization, hardware acceleration APIs, and third-party library dependencies.
Platform Standardization vs. Fragmentation
When Apple transitioned to the M-series chips, it was a wholesale replacement of their entire hardware lineup. Developers had no choice but to build natively for ARM if they wanted to stay on the Mac platform. In contrast, Windows on ARM (powered largely by Qualcomm Snapdragon chips) represents a small fraction of the broader Windows market. Because standard x86/x64 Intel and AMD processors still dominate the PC ecosystem, smaller developers like DxO lack the financial incentive to rebuild and maintain an entirely separate Windows ARM codebase.
Hardware Acceleration for DeepPRIME
DxO PhotoLab’s flagship noise reduction technologies (DeepPRIME and DeepPRIME XD) require massive computational power, relying on direct access to the GPU and Neural Processing Unit (NPU). Apple provided unified, highly optimized APIs (Metal and Core ML) that allowed DxO to tap directly into the unified memory and Neural Engine of your Mac. On Windows, Qualcomm’s Adreno GPUs and Hexagon NPUs require completely different optimization paths. They lack standard NVIDIA CUDA support and have historically struggled with the OpenCL and DirectCompute protocols DxO uses for PC rendering. Running AI denoising through Windows’ x86 emulation layer results in severe performance bottlenecks that ruin the user experience.
Third-Party Codec Dependencies
Photo editors are not completely standalone; they rely on a web of licensed, third-party decoding libraries that must also be recompiled for a new architecture. For example, the proprietary algorithm licensed to decode the High-Efficiency compressed NEF files from your Nikon Z8 does not currently have a native Windows ARM decoding library. Even if DxO managed to emulate the PhotoLab interface on a Snapdragon PC, it would be unable to properly ingest the raw files because the underlying CPU-optimized code cannot be read by the operating system.
Until ARM processors capture a much larger share of the heavy-workstation PC market—and all associated third-party raw decoders are rewritten natively for Windows ARM—DxO will likely keep its Windows development focused squarely on traditional x86 architecture.”
I just installed PhotoLab 10 it on my M1 MacMini and it shows as a “Universal” executable containing both Intel and ARM versions of the code.
It’s a shame that DXO haven’t done similarly for ARM-Windows, particularly as the Snapdragon 2 and Nvidia’s RTX Spark platforms are launching over the next few weeks.
The macOS version is almost entirely different code. On macOS, PhotoLab is built in Apple’s AppKit wrapped in SwiftUI. On Windows, PhotoLab is built in WPF (Windows Presentation Foundation) and the .NET framework. This is before we get into the processing layer and GPU optimisation (also different stacks, with Metal and Apple’s Neural Engine not making it to Windows ARM).
An ARM version on Windows would be a big project and would have to be based entirely on the Windows version of PhotoLab. None of the macOS code could carry over.