Why Wallpapers Look Dull on Device: Taming Display P3 in the Delivery Pipeline

Profile presence alone is not enough

As the inventory went on, I hit a trickier problem. Some images were tagged "sRGB," yet the pixels themselves were painted with saturation beyond the sRGB range. In that case, whether to re-assign P3 or leave it as sRGB cannot be decided from the tag alone. You have to look inside.

I used ImageMagick to roughly measure how far the pixels spill past the sRGB boundary. Convert a copy down to sRGB, compare it to the original, and if the difference is large, assume the content is wide-gamut.

# Convert to sRGB and measure how big the difference is (RMSE)
# Large difference = colors that do not fit in sRGB = wide-gamut content
orig="wallpaper_001.jpg"
magick "$orig" -profile sRGB.icc /tmp/as_srgb.jpg
diff=$(magick compare -metric RMSE "$orig" /tmp/as_srgb.jpg null: 2>&1 | sed 's/ .*//')
echo "$orig RMSE=$diff"
# Rule of thumb: in my set, images above ~1500 RMSE were usually P3-derived

The threshold depends on how your app's art is made, so it is practical to eyeball a few images and tune it. The point is to measure "do the pixels use the wide gamut" once, instead of trusting the tag. Skip this and the next re-assignment step will break your colors.

Align the gamut before delivery

My policy settled on this: embed an explicit Display P3 profile into wallpapers whose pixels are wide-gamut. With P3 embedded, P3 devices render vividly, while sRGB devices let iOS scale it down. Handing the dual-target work to the device is simply less to maintain.

# Re-assign Display P3 to an image whose pixels are P3
# (only for images confirmed "wide-gamut" by the previous step)
sips --matchTo "/System/Library/ColorSync/Profiles/Display P3.icc" \
  input.jpg --out output.jpg

Slapping a P3 profile onto an image whose pixels are actually sRGB does the opposite, inflating colors unnaturally. That is exactly why the earlier "is the content wide-gamut" check earns its keep. After ruining a few images, I learned you have to know which gamut the source was authored in before you assign anything.

Make the pre-delivery gate a script

Fixing it once does nothing if the next update reverts the export setting and the dullness creeps back. So I put a small gate in front of the delivery script that drives "no profile" to zero. If even one image lacks a profile, it stops delivery and tells me.

#!/usr/bin/env bash
# gamut-gate.sh — exit 1 if any image in the delivery folder lacks a profile
set -euo pipefail
DIR="${1:-./assets}"
missing=0
while IFS= read -r -d '' f; do
  if ! sips --getProperty profile "$f" 2>/dev/null | grep -qi "profile:"; then
    echo "⚠️  no profile: $f"
    missing=$((missing + 1))
  fi
done < <(find "$DIR" -type f \( -iname '*.jpg' -o -iname '*.png' \) -print0)
 
if [ "$missing" -gt 0 ]; then
  echo "🚫 $missing image(s) without a profile. Re-export before shipping."
  exit 1
fi
echo "✅ Every image has a profile. OK to ship."

Adding this one line to CI or a local pre-ship script stops the leak structurally. Problems like color gamut that "come back when you have forgotten them" are, in my experience running six apps in parallel, best stopped by a mechanism rather than by human attention.

Xcode assets and the React Native side

For icons and onboarding images bundled into the app, the Asset Catalog behavior matters too. Xcode assets have a display-gamut setting, and leaving it at Any & sRGB rounds wide-gamut images down to sRGB. For images I want shown in wide color, I switch the gamut to Display P3.

In the screens I built with Rork, I use expo-image to show wallpapers loaded from a remote source. On iOS it respects the image profile internally, so as long as P3 is embedded correctly on the delivery side, no special color conversion was needed in code. I deliberately keep this part plain and treat gamut as a responsibility of the delivery pipeline.

import { Image } from "expo-image";
 
// Do no color conversion in code. Assume the delivered image carries
// the correct profile, and simply display it as-is.
export function WallpaperPreview({ uri }: { uri: string }) {
  return (
    <Image
      source={{ uri }}
      style={{ flex: 1 }}
      contentFit="cover"
      cachePolicy="memory-disk"
    />
  );
}

The loading and caching mechanics are a separate story, so I wrote up the image-performance side in how I tuned wallpaper image loading with expo-image. Settling gamut at the "ship correct data" stage and keeping the display side plain has been the least fragile shape for me while running six apps in parallel.

Android wide color is a different story

Once gamut settles on iOS, Android has its own rules. Wide-gamut displays vary by device, and some devices will not opt into wide color unless the app declares that it draws in wide color. With Expo you can set the window color mode in app.json.

{
  "expo": {
    "android": {
      "manifestPlaceholders": {},
      "wideColorGamut": true
    }
  }
}

Depending on the setup this becomes android:colorMode="wideColorGamut" on the Activity in AndroidManifest.xml. The caveat: enabling wide color carries a small power cost, and you do not need it on for every screen. Putting only the "color is the star" screens like the wallpaper preview into wide color, and leaving the rest normal, was the practical call.

The table below is the policy I settled on per asset type.

Verifying on device and in screenshots

I do not rest on the numbers alone; in the end I confirm with my eyes. My routine is two stages. First I open the same wallpaper on both a P3 device (here, a newer iPhone) and an older device that only has sRGB, and check that saturation has not broken. With the profile embedded correctly, the older device should look a touch quieter and the newer one more vivid, yet both should read naturally.

The other thing I watch is App Store screenshots. PNGs exported for screenshots can lose their profile for the same reason the delivery images did. If colors look dull on the store product page, that alone changes the first impression. I now run screenshots through sips --getProperty profile before submitting them.

# Check the screenshot gamut as well before submission
for f in ./store-screenshots/*.png; do
  sips --getProperty profile "$f" 2>/dev/null | grep -i "profile:" \
    || echo "$f: no profile (re-export needed)"
done

What I noticed after sorting it out

Color gamut tends to get pushed aside precisely because it is not a flashy feature. Having quietly lost color for years, in a genre where the look is everything, was honestly a slightly bitter thing to discover as an indie developer.

That said, once the cause was clear the fix was simple. Inventory the profiles of your delivery images, measure whether the content is wide-gamut, unify on P3, and re-embed. Keep the display side plain, and stop the leaks with a gate before delivery. What stayed with me is that the win came not from adding new technology, but from checking the provenance of data I was already shipping.

The next move is clear: drop gamut-gate.sh into the tail of the export script and make "zero images without a profile" a habit before every delivery. If you build apps that handle wallpapers or photos, I hope this nudges you to measure the gamut just once before you ship.