You can't fix that by choosing a better default colour, because no single colour works on every photo. What you can do is check each photo after layout: measure the pixels that sit under the mark and decide whether the mark will be readable there. If it won't, flag the photo, switch the colour, or add a shadow.

This post builds that check in Swift with Core Image. It's short, it runs in a few milliseconds per photo, and the interesting part isn't the code but two decisions inside it: how you combine the background pixels, and how you account for opacity.

The measure: WCAG contrast ratio

We need a number that says "how distinguishable are these two colours to a human eye". The web accessibility world already has a standard one, the contrast ratio from WCAG 2.1:

ratio = (L_lighter + 0.05) / (L_darker + 0.05)

where L is relative luminance: the colour converted from sRGB to linear light, then weighted by how sensitive the eye is to each channel:

L = 0.2126 R + 0.7152 G + 0.0722 B     (R, G, B linear, 0...1)

The ratio runs from 1:1 (identical) to 21:1 (black on white). WCAG asks for 4.5:1 for body text and 3:1 for large text. A watermark is usually large and isn't meant to be read like a paragraph, so I use 3:1 as the line between "readable" and "weak". That's a judgement call, not a standard for watermarks, and you can tune it.

One useful number falls out of the formula. White and black have equal contrast against a background whose luminance is about 0.179. Below that, white text wins; above it, black text wins. Note that 0.179 is a linear value; in everyday sRGB terms, it's a mid grey of roughly 118 out of 255, a lot darker than the "50% grey" most people would guess.

In Swift:

import Foundation

/// sRGB-encoded 0...255 channel to linear 0...1.
@inline(__always)
func linear(_ c: UInt8) -> Double {
    let v = Double(c) / 255
    return v <= 0.04045 ? v / 12.92 : pow((v + 0.055) / 1.055, 2.4)
}

func luminance(_ r: UInt8, _ g: UInt8, _ b: UInt8) -> Double {
    0.2126 * linear(r) + 0.7152 * linear(g) + 0.0722 * linear(b)
}

func contrast(_ a: Double, _ b: Double) -> Double {
    (max(a, b) + 0.05) / (min(a, b) + 0.05)
}

(The WCAG 2.1 text uses 0.03928 as the threshold in the linearisation; 0.04045 is the sRGB specification's value. For 8-bit input they give the same result.)

Step 1: Sample the pixels under the mark

You already know where the watermark goes, because your layout code computed its rectangle. Take that rectangle, cut it out of the photo, and shrink it to a small grid, say 24 × 24. That's 576 samples, which is plenty to describe the background and costs almost nothing to analyse.

Two details matter here.

Core Image's origin is bottom-left. If your layout uses UIKit coordinates (top-left origin), flip the rectangle before cropping, or you'll measure the wrong corner of the photo. This is the most common bug in this kind of code, and it fails silently: you get plausible numbers for the wrong pixels.

Clamp before you resample. Outside a cropped image, Core Image sees transparent pixels. A Lanczos downscale near the edges of the crop blends those in, which darkens your edge samples. Calling clampedToExtent() first repeats the edge pixels outward so the filter has real data to work with.

import CoreImage
import CoreImage.CIFilterBuiltins

let sharedContext = CIContext()   // create once, reuse for the whole batch

/// Returns `grid` x `grid` RGBA8 sRGB samples of `rect`.
/// `rect` is in UIKit coordinates: pixels, top-left origin.
func backgroundSamples(of image: CIImage, under rect: CGRect,
                       grid: Int = 24) -> [UInt8]? {
    let extent = image.extent
    let ciRect = CGRect(x: extent.minX + rect.minX,
                        y: extent.maxY - rect.maxY,      // flip Y
                        width: rect.width, height: rect.height)
        .intersection(extent)
    guard !ciRect.isNull, ciRect.width >= 1, ciRect.height >= 1 else { return nil }

    let region = image
        .cropped(to: ciRect)
        .clampedToExtent()
        .transformed(by: CGAffineTransform(translationX: -ciRect.minX, y: -ciRect.minY))

    let scaleY = CGFloat(grid) / ciRect.height
    let scaleX = CGFloat(grid) / ciRect.width

    let resize = CIFilter.lanczosScaleTransform()
    resize.inputImage = region
    resize.scale = Float(scaleY)
    resize.aspectRatio = Float(scaleX / scaleY)

    let bounds = CGRect(x: 0, y: 0, width: grid, height: grid)
    guard let small = resize.outputImage?.cropped(to: bounds),
          let sRGB = CGColorSpace(name: CGColorSpace.sRGB) else { return nil }

    var pixels = [UInt8](repeating: 0, count: grid * grid * 4)
    sharedContext.render(small, toBitmap: &pixels, rowBytes: grid * 4,
                         bounds: bounds, format: .RGBA8, colorSpace: sRGB)
    return pixels
}

Rendering into sRGB on purpose matters: the WCAG formula is defined on sRGB values, so we ask Core Image to convert whatever the photo's colour space is (often Display P3 on iPhone) into sRGB before we read the bytes.

Step 2: Account for opacity

Most watermarks aren't opaque. At 85% opacity, a white mark over a dark-blue sky isn't white; it's 85% white and 15% blue. That blended colour is what the eye compares with the background, and it always has less contrast than the solid colour would.

So instead of comparing "white" with the background, compare the blended mark colour with the background, pixel by pixel:

struct RGB { var r, g, b: Double }   // 0...255, sRGB-encoded

func blended(_ mark: RGB, over bg: RGB, opacity a: Double) -> RGB {
    RGB(r: a * mark.r + (1 - a) * bg.r,
        g: a * mark.g + (1 - a) * bg.g,
        b: a * mark.b + (1 - a) * bg.b)
}

func lum(_ c: RGB) -> Double {
    luminance(UInt8(c.r.rounded()), UInt8(c.g.rounded()), UInt8(c.b.rounded()))
}

This blends in encoded sRGB, which matches how an 8-bit sRGB drawing context composites by default. If your renderer blends in linear light, blend linear values instead. The decision rarely changes, but the numbers will shift a little.

Step 3: Use the worst case, not the average

Here's the decision that matters most. The easy version is: average the background, compute one contrast ratio, done. Core Image even has a filter for it (CIAreaAverage).

The average hides exactly the photos you're trying to catch. Picture a watermark that straddles the edge of a sunlit white wall and a deep shadow. The average of those two is a middling grey, and dark text against middling grey looks fine on paper. On the actual photo, half the mark sits on the shadow and disappears.

So compute the contrast for every sample, sort, and look at the 10th percentile: the contrast that 90% of the mark area beats. If the worst tenth of the background is too close to the mark colour, part of the mark will be unreadable no matter how good the average looks.

struct MarkCheck {
    enum Tone { case light, dark }
    let tone: Tone
    let worstContrast: Double          // 10th percentile across the samples
    var isReadable: Bool { worstContrast >= 3.0 }
}

func percentile(_ values: [Double], _ p: Double) -> Double {
    let sorted = values.sorted()
    let index = Int((Double(sorted.count - 1) * p).rounded())
    return sorted[index]
}

func checkMark(samples: [UInt8], opacity: Double) -> MarkCheck {
    let light = RGB(r: 255, g: 255, b: 255)
    let dark  = RGB(r: 26, g: 26, b: 26)           // #1A1A1A rather than pure black

    var lightRatios: [Double] = []
    var darkRatios: [Double] = []
    lightRatios.reserveCapacity(samples.count / 4)
    darkRatios.reserveCapacity(samples.count / 4)

    for i in stride(from: 0, to: samples.count, by: 4) {
        let bg = RGB(r: Double(samples[i]), g: Double(samples[i + 1]), b: Double(samples[i + 2]))
        let bgL = lum(bg)
        lightRatios.append(contrast(lum(blended(light, over: bg, opacity: opacity)), bgL))
        darkRatios.append(contrast(lum(blended(dark, over: bg, opacity: opacity)), bgL))
    }

    let lightWorst = percentile(lightRatios, 0.10)
    let darkWorst = percentile(darkRatios, 0.10)
    return lightWorst >= darkWorst
        ? MarkCheck(tone: .light, worstContrast: lightWorst)
        : MarkCheck(tone: .dark, worstContrast: darkWorst)
}

The 10th percentile is a tunable. A mark made of thick letters survives a few bad pixels; a thin script font doesn't. If you use hairline fonts, look at the 20th or 25th percentile instead.

Mean versus worst case, in numbers

To see whether the percentile earns its keep, I ran the same check (ported to Python) on three synthetic backgrounds, with a white mark and a #1A1A1A mark at 85% opacity:

The first two rows are the easy cases, and both methods agree. The foliage shows texture costing you something: the noise pulls the worst case well below the mean, though white still passes comfortably.

The last row is the reason for this post. The average says dark text passes at about 4:1. The worst-case check says neither colour works: whichever you pick, roughly half the mark sits on a background of nearly its own brightness. A mean-based check would ship that photo with a half-invisible watermark.

What to do when neither colour passes

When both tones come back weak, the background is split, and changing the colour can't help. You have three honest options:

1. Add a shadow or outline. A soft dark shadow under light text creates its own local background. Size it relative to the image, not in points, or it vanishes on large photos.
2. Add a backing plate. A rounded rectangle at 30–40% opacity behind the text guarantees contrast. It's more visible, which is sometimes the point.
3. Move the mark. If your layout allows another corner, run the check there too and pick the best one. With 576 samples per position, checking four corners is still cheap.

For a batch tool, I'd add a fourth: tell the person. Flagging "these 7 photos have a weak watermark" before export is more useful than silently guessing.

Wiring it into a batch

Per photo, the cost is one small Core Image render and a few thousand arithmetic operations. Use one CIContext for the whole batch (creating a context is the expensive part), load each photo, compute the layout, run the check, then decide:

func review(_ images: [CIImage], markRect: (CIImage) -> CGRect,
            opacity: Double) -> [(index: Int, check: MarkCheck)] {
    images.enumerated().compactMap { index, image in
        guard let samples = backgroundSamples(of: image, under: markRect(image)) else {
            return nil
        }
        return (index, checkMark(samples: samples, opacity: opacity))
    }
}

// Later:
// let weak = review(photos, markRect: layout, opacity: 0.85).filter { !$0.check.isReadable }

If you're doing this over large photos, load them downsampled for the check. You're measuring a 24 × 24 grid; you don't need the full 48 megapixels in memory to do it.

Takeaways

• Measure the pixels under the mark, after layout, in sRGB.
• Compare the blended mark colour with the background, because opacity always costs contrast.
• Judge by a low percentile, not the average. Split backgrounds are where watermarks quietly disappear, and the average is blind to them.
• When neither colour passes, change the treatment (shadow, plate, position), not the colour.

I build an iPhone app called BatchMark, which applies one text or logo watermark, with your chosen position, size, opacity, font and spacing, to a whole set of photos at once. A setup that works on the first photo but not the fortieth is exactly the failure that a batch makes easy to miss, which is why I've been thinking about checks like this one. If you want to see the batch flow itself, here's how batch watermarking works in the app.

This post walks through what went wrong, the approach that works, and Swift code for each step. Nothing here needs a third-party library. It's Core Graphics, some arithmetic, and about 120 lines of Swift.

The obvious approach: average every pixel

Core Image ships a filter for exactly this, CIAreaAverage. Feed it an image and an extent, and it gives you back a 1×1 image whose single pixel is the mean colour. It's fast, it runs on the GPU, and for a photo of a red wall it works perfectly.

Now try a beach photo: blue sky on top, teal sea in the middle, sand at the bottom, a row of orange umbrellas.

I built that test image on purpose so I'd know the right answer. The average came out as roughly rgb(142, 168, 173), a dull grey-teal. That colour isn't anywhere in the picture. Averaging blends opposite hues together, and the more varied a photo is, the closer the result drifts towards grey.

What a person means by "the main colour" isn't the mean. It's the biggest group of similar pixels. That's a clustering problem, and the classic tool for it is k-means.

Step 1: Shrink the photo first

You don't need 12 million pixels to find a colour. A 64×64 sample (4,096 pixels) is plenty, and it turns k-means from a slow job into one that finishes in a few milliseconds.

Drawing into a small CGContext does the downsampling and gives you a predictable pixel format at the same time. Using an sRGB context also means wide-gamut images get converted for you, so the maths later only has to handle one colour space.

import CoreGraphics
import Foundation

func samplePixels(from image: CGImage, side: Int = 64) -> [Lab] {
    var buffer = [UInt8](repeating: 0, count: side * side * 4)
    let sRGB = CGColorSpace(name: CGColorSpace.sRGB)!

    let drew = buffer.withUnsafeMutableBytes { raw -> Bool in
        guard let context = CGContext(
            data: raw.baseAddress,
            width: side,
            height: side,
            bitsPerComponent: 8,
            bytesPerRow: side * 4,
            space: sRGB,
            bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue
        ) else { return false }
        context.interpolationQuality = .medium
        context.draw(image, in: CGRect(x: 0, y: 0, width: side, height: side))
        return true
    }
    guard drew else { return [] }

    var pixels: [Lab] = []
    pixels.reserveCapacity(side * side)
    for i in stride(from: 0, to: buffer.count, by: 4) where buffer[i + 3] > 200 {
        pixels.append(Lab(r: buffer[i], g: buffer[i + 1], b: buffer[i + 2]))
    }
    return pixels
}

Squashing the aspect ratio to a square is fine here. We care about how much of each colour there is, not where it sits. The alpha check skips mostly transparent pixels, which matters if you ever run this on a PNG with a cut-out.

One tip: if your source is a full-size file on disk, make a thumbnail with ImageIO's CGImageSourceCreateThumbnailAtIndex first and pass that in, so you never decode the full image just to throw most of it away.

Step 2: Cluster in Lab, not RGB

k-means groups points by distance. In RGB, distance doesn't match what your eye sees: two greens that look nearly identical can be further apart in RGB than a green and a grey that look nothing alike. CIE Lab was designed so that straight-line distance roughly tracks perceived difference, which is exactly what clustering needs.

The conversion is sRGB → linear RGB → XYZ (D65 white point) → Lab:

struct Lab {
    var l: Double
    var a: Double
    var b: Double
}

private func toLinear(_ c: Double) -> Double {
    c <= 0.04045 ? c / 12.92 : pow((c + 0.055) / 1.055, 2.4)
}

private func toGamma(_ c: Double) -> Double {
    c <= 0.0031308 ? c * 12.92 : 1.055 * pow(c, 1 / 2.4) - 0.055
}

private let epsilon = 216.0 / 24389.0
private let kappa = 24389.0 / 27.0
private let white = (x: 0.95047, y: 1.0, z: 1.08883)   // D65

extension Lab {
    init(r: UInt8, g: UInt8, b: UInt8) {
        let rl = toLinear(Double(r) / 255)
        let gl = toLinear(Double(g) / 255)
        let bl = toLinear(Double(b) / 255)

        let x = (0.4124564 * rl + 0.3575761 * gl + 0.1804375 * bl) / white.x
        let y = (0.2126729 * rl + 0.7151522 * gl + 0.0721750 * bl) / white.y
        let z = (0.0193339 * rl + 0.1191920 * gl + 0.9503041 * bl) / white.z

        func f(_ t: Double) -> Double { t > epsilon ? cbrt(t) : (kappa * t + 16) / 116 }
        let fx = f(x), fy = f(y), fz = f(z)

        self.init(l: 116 * fy - 16, a: 500 * (fx - fy), b: 200 * (fy - fz))
    }

    /// Back to 8-bit sRGB, clamped to the displayable range.
    var rgb: (r: UInt8, g: UInt8, b: UInt8) {
        let fy = (l + 16) / 116
        let fx = fy + a / 500
        let fz = fy - b / 200
        func inverse(_ t: Double) -> Double {
            let cubed = t * t * t
            return cubed > epsilon ? cubed : (116 * t - 16) / kappa
        }
        let x = inverse(fx) * white.x
        let y = inverse(fy) * white.y
        let z = inverse(fz) * white.z

        let r =  3.2404542 * x - 1.5371385 * y - 0.4985314 * z
        let g = -0.9692660 * x + 1.8760108 * y + 0.0415560 * z
        let b =  0.0556434 * x - 0.2040259 * y + 1.0572252 * z

        func byte(_ c: Double) -> UInt8 {
            UInt8((min(max(toGamma(c), 0), 1) * 255).rounded())
        }
        return (byte(r), byte(g), byte(b))
    }

    var chroma: Double { (a * a + b * b).squareRoot() }
}

I checked this pair of functions by converting every pixel of a test image to Lab and back. The worst error was far below one 8-bit step, so the round trip is effectively lossless.

Step 3: k-means with a seeded k-means++ start

Plain k-means picks random starting centres, which has two problems for a UI feature. First, bad starts give bad clusters. Second, the same photo can give a different answer every time you open it, which looks like a bug to the user.

k-means++ fixes the first problem by spreading the starting centres out: each new centre is picked with probability proportional to its squared distance from the nearest existing one. A tiny seeded random generator fixes the second.

struct SplitMix64: RandomNumberGenerator {
    private var state: UInt64
    init(seed: UInt64) { state = seed }

    mutating func next() -> UInt64 {
        state &+= 0x9E3779B97F4A7C15
        var z = state
        z = (z ^ (z >> 30)) &* 0xBF58476D1CE4E5B9
        z = (z ^ (z >> 27)) &* 0x94D049BB133111EB
        return z ^ (z >> 31)
    }
}

struct Cluster {
    var center: Lab
    var count: Int
}

private func distanceSquared(_ p: Lab, _ q: Lab) -> Double {
    let dl = p.l - q.l, da = p.a - q.a, db = p.b - q.b
    return dl * dl + da * da + db * db
}

func kMeans(_ points: [Lab], k: Int, iterations: Int = 12, seed: UInt64 = 42) -> [Cluster] {
    guard k > 0, points.count >= k else { return [] }
    var rng = SplitMix64(seed: seed)

    // k-means++ seeding
    var centers = [points[Int.random(in: 0..<points.count, using: &rng)]]
    var nearest = points.map { distanceSquared($0, centers[0]) }
    while centers.count < k {
        let total = nearest.reduce(0, +)
        guard total > 0 else { break }          // every pixel is identical
        var target = Double.random(in: 0..<total, using: &rng)
        var chosen = points.count - 1
        for (i, d) in nearest.enumerated() {
            target -= d
            if target <= 0 { chosen = i; break }
        }
        centers.append(points[chosen])
        for i in points.indices {
            nearest[i] = min(nearest[i], distanceSquared(points[i], points[chosen]))
        }
    }

    // Lloyd iterations
    var assignment = [Int](repeating: -1, count: points.count)
    var counts = [Int](repeating: 0, count: centers.count)
    for _ in 0..<iterations {
        var changed = false
        for (i, p) in points.enumerated() {
            var best = 0
            var bestDistance = Double.infinity
            for (c, center) in centers.enumerated() {
                let d = distanceSquared(p, center)
                if d < bestDistance { bestDistance = d; best = c }
            }
            if assignment[i] != best { assignment[i] = best; changed = true }
        }

        var sums = [Lab](repeating: Lab(l: 0, a: 0, b: 0), count: centers.count)
        counts = [Int](repeating: 0, count: centers.count)
        for (i, p) in points.enumerated() {
            let c = assignment[i]
            sums[c].l += p.l; sums[c].a += p.a; sums[c].b += p.b
            counts[c] += 1
        }
        for c in centers.indices where counts[c] > 0 {
            let n = Double(counts[c])
            centers[c] = Lab(l: sums[c].l / n, a: sums[c].a / n, b: sums[c].b / n)
        }
        if !changed { break }
    }

    return zip(centers, counts)
        .map { Cluster(center: $0, count: $1) }
        .sorted { $0.count > $1.count }
}

With 4,096 points, k = 5 and at most 12 iterations, this is around 250,000 distance checks. That's nothing. It usually converges well before the iteration cap.

Why k = 5? It's a trade-off. Too few and the sea and sky merge into one blue. Too many and you split one wall into "lit" and "shadow" versions. Five has been a good default for photos; for a palette strip you might want six or seven.

Step 4: Decide what "main" means

On the beach image, the clusters came out as sky blue (about 42% of pixels), sand (36%), sea teal (11%), umbrella orange (7%) and a small brown group from the poles and the edges where colours blend.

The biggest cluster wins here, and that's the right answer. But on many real photos, the biggest cluster is something dull: a grey pavement, a white wall, a dark shadow. People don't describe a photo of a red door on a grey street as "grey". They notice the colour.

So I score clusters by size, weighted by how colourful they are:

func dominantColor(in clusters: [Cluster]) -> Lab? {
    func score(_ cluster: Cluster) -> Double {
        let colourfulness = 0.35 + min(cluster.center.chroma, 60) / 60
        return Double(cluster.count) * colourfulness
    }
    return clusters.max { score($0) < score($1) }?.center
}

A fully grey cluster keeps 35% of its weight; a strongly coloured one gets up to 1.35×. The constants are taste, not science, so tune them on your own test photos. On the beach image the scoring doesn't change the winner, but it pulls the small orange cluster level with the much bigger teal one, which is closer to how a person ranks them.

A couple of guards I'd add in production:

• Very dark or very bright clusters. Near-black and near-white have low chroma anyway, but you may want to skip clusters with l < 8 or l > 95 completely.
• Black-and-white photos. If every cluster has low chroma, don't force a colour. Return the biggest cluster and let it be grey. That's honest.

Putting it together

func mainColor(of image: CGImage) -> (r: UInt8, g: UInt8, b: UInt8)? {
    let pixels = samplePixels(from: image)
    let clusters = kMeans(pixels, k: 5)
    return dominantColor(in: clusters)?.rgb
}

Because the seed is fixed and the input is downsampled the same way each time, the same photo always returns the same colour.

What about CIKMeans?

Core Image has had a CIKMeans filter since iOS 14. It runs on the GPU and returns the cluster means as a small image. It's a good choice if you're already in a Core Image pipeline. Two things to know: it clusters in the working colour space, not a perceptual one, so you may see the RGB distance problem above; and reading the result back still means rendering a tiny image into a bitmap. For a few thousand pixels, the CPU version above is fast enough, easy to debug, and gives you control over the distance and the scoring.

Where this ended up

This is the kind of problem behind the Color Walk cards in BatchMark, my iPhone app for batch watermarks, frames and colour cards. You pick a photo, the app pulls out its colours, and you add a place and a date. Everything runs on the device, which is one more reason a small sample size matters. If you're curious what the finished cards look like, the Color Walk page has examples.

Whether or not you build colour cards, the general lesson holds for many image tasks. Shrink the input before you do anything clever, do the maths in a space that matches human perception, make the result deterministic, and test on images where you already know the right answer. A synthetic test image like the beach scene takes five minutes to make and catches most mistakes before a user does.

Disclosure: I'm an independent developer, and BatchMark (灵感图像大师 in Chinese) is my own app. It's free to download on the App Store, with optional paid features.