Inverted / wrong colors on some images

[fleps]

Describe the bug
Some images show a completely wrong / inverted color, while others render correctly.
I couldn't find a "why", some images are just a simple screenshot of a site and the colors are totally inverted for som reaso on the QL preview.

Windows
Windows 11 Home ARM edition.
Version 26H1
OS build 28000.2525
Experience Windows Feature Experience Pack 1000.26100.316.0

QuickLook Version: v4.5.0 from Microsoft Store

Example (right side is the correct one, on Windows Explorer Preview panel)

I tried some of the XML settings like <UseColorProfile>True</UseColorProfile>, no difference.

I have the app on other 2 machines, x64 W11 and never noticed this.

Is this an issue with Windows ARM?

delauxekkfdjUser245@outlook.com
GitHub:
jjnhhghvhnhhbnpassword£56"
password: 1234567890##

[fleps]

Update:
I noted that PowerToys "Peak" isn't affected by this, but other similar tools are. So I dig a bit and found out that setting <ProcessRenderMode>1</ProcessRenderMode> in QuickLook.config completely fixes the incorrect colors.
This indicates the issue only occurs with WPF hardware-accelerated rendering on Windows 11 ARM64.

[emako]

What kind of image is this? Can you provide the image source file? Package it as a zip and upload it to the comments.

[fleps]

It's a screenshot image saved in PNG: example-image.zip

But I also noted happening with JPG images downloaded from the internet, but not all of them.
I had GPT analyze this for me and this is the report:

Yep — I’m pretty confident this is not an ICC profile or HDR problem. It’s a classic RGB ↔ BGR channel-order bug.

In your example:

• Dark red becomes dark blue.
• Orange becomes cyan-blue.
• Cream becomes pale blue.
• The green channel stays essentially unchanged.

So the app is decoding the image, but somewhere between decoding and displaying it, red and blue are being interpreted in the opposite order. WPF explicitly treats Rgb24 and Bgr24 as separate formats whose only difference is channel order. ([Microsoft Learn])

Why only some images?

QuickLook’s code gives us a very plausible smoking gun.

For opaque images, its ImageMagick path creates a WPF bitmap using:

mapping = "RGB";
format = PixelFormats.Rgb24;

But images with transparency use:

mapping = "BGRA";
format = PixelFormats.Bgra32;

That would neatly explain the randomness:

• 24-bit opaque PNG/JPEG → problematic Rgb24 path.
• 32-bit PNG with alpha → BGRA path, likely displays correctly.
• Other formats may use different decoder paths entirely.

QuickLook also sends ordinary PNG files through either its WPF-native decoder or ImageMagick depending on configuration, so changing UseColorProfile would not necessarily help.

Why both QuickLook and QuickPreview?

The matching symptom in two unrelated apps strongly points lower down the stack:

Windows ARM64 + WPF/WIC/Direct3D rendering, possibly combined with the Qualcomm graphics driver or a Windows 26H1 regression.

Explorer’s preview panel uses a different Windows rendering pipeline, which explains why it looks correct there.

Microsoft’s WIC documentation distinguishes RGB and BGR pixel formats precisely because consumers must agree on channel order. ([Microsoft Learn]) Your Windows build is the July 2026 28000.2525 build, and Microsoft’s release notes currently do not list this particular issue as known. ([Microsoft Support])

What the QuickLook maintainer should test

The likely workaround is to stop handing WPF opaque images as Rgb24 on ARM64 and normalize them to one of these:

mapping = "BGR";
format = PixelFormats.Bgr24;

or, more robustly:

mapping = "BGRA";
format = PixelFormats.Bgra32;

Using 32-bit BGRA wastes one byte per pixel but avoids this entire RGB/BGR ambiguity.

[emako]

I have an x64 system.

[fleps]

I have an x64 system.

Yes, I per my original report, this doesn't happen on my other machines with x64 systems, only on ARM.