Rendered readability of CKey designs on screens: tone, contrast, vignettes, mark shape and the room around the display

Introduction

A CKey symbol is a two-dimensional optical code. A rounded square frame with four corner finders surrounds a field of square modules on the outside, and rings and radial rays in the centre. Like other matrix codes, it can be styled: the background, ink and accent colours, a radial background vignette, a metallic sheen on the ink, and the shape of the modules (rounded square, square, circle or diamond). The published design catalogue at openckey.org offers about twenty such designs, each certified by a modelled scan before publication.

In informal use on displays, some designs read from much further away than others, and the pattern was not explained by contrast alone. The best-reading designs shared visible traits: several have a dark, vignetted background, and one light design (Plum) uses round marks and an accent colour. This paper asks which of these traits actually matter for readability on screens, why, and what a designer should do about it.

We deliberately keep to the rendered symbol and its environment: colours, tone, shape and surroundings. Decoding software differs between readers and changes over time. Where a result depends on how a reader judges dark and light, we say so in general terms (Section 5.3), but we do not evaluate particular readers.

Background

Relative luminance and contrast ratio

Displays and image files encode colour in sRGB. Perceived tone and camera exposure act on linear light, so every quantity below is computed after the sRGB transfer function is undone [1]. For an 8-bit channel value $v$:

and the relative luminance of a colour is

The contrast ratio between two colours with luminances $Y_{\text{hi}} \ge Y_{\text{lo}}$ is the familiar web-accessibility measure [2]:

which runs from 1:1 (identical) to 21:1 (black on white).

How visible a change of tone is

To ask whether a design "still looks like" black on white after softening, we use the CIEDE2000 colour difference [3]. For neutral greys the chroma and hue terms vanish and $\Delta E_{00}$ reduces to a weighted lightness difference:

where $L^{*}$ is CIELAB lightness and $\bar L^{*}$ is the mean of the two. As a rule of thumb, a $\Delta E_{00}$ below about 1–2 is hard to see in isolation, and 2–4 is visible mainly when the two are side by side.

Frame-referenced and local tone decisions

To find a symbol, a reader has to decide which pixels are dark and which are light. A simple, fast and widely used approach takes one reference from the brightness distribution of the whole camera frame: a global threshold, as in Otsu's method [4], or a percentile rule. Local methods instead judge each pixel against its own neighbourhood [5]. Local methods cost more computation, but they are insensitive to what lies elsewhere in the frame. Section 5.3 shows that this distinction explains most of what follows.

Methods

Field observations

The field observations were made by the author over one evening on 2026-11-08. The setup:

• an iPhone running the Open CKey Scanner app;
• the codes shown on an older Samsung television and on a lower-resolution computer monitor, in an indoor room lit more dimly than the screens;
• every symbol a CKey Profile 0, version 1 code carrying the 20-byte payload https://openckey.org, rendered by openckey.org at its default on-screen size of about 10 cm (4 in).

For each design, the author recorded roughly the greatest distance at which the code read reliably. These observations are uncontrolled: viewing angle, hand motion and exposure varied, and the app's software changed during the evening. We therefore compare designs only within one sitting, never across sittings, and treat the distances as ordinal.

Controlled contrast series

To separate background tone from ink tone, the author tested five neutral-grey candidates with otherwise identical settings (round marks, same size, same display and position). For each, they recorded the furthest distance that read on three of three attempts, and whether reading was immediate or slow.

Simulation

To isolate one variable at a time, we built a minimal screen-and-camera model around the reference CKey renderer and decoder (core version 0.1.0-build.85).

1. Rendering. The symbol is rendered with the design's style (colours, vignette, sheen, accents, mark shape) at four times the target width, then area-averaged to the target width $S$ in camera pixels, with a random sub-pixel phase. Luminance is computed in linear light as above.
2. Scene. The symbol sits in the middle of a uniform screen page (linear luminance 0.92, the cream of the openckey.org page), $3S$ on a side. The page sits in a uniform room that fills the rest of a $6S \times 6S$ frame, so the room covers three quarters of the view. Room luminance is the main independent variable: 0.03 (a dim room), 0.10, 0.25, 0.50 and 0.90.
3. Camera. Auto-exposure scales the frame so its mean is 0.18 (mid-grey), as phones do when metering the whole scene. Values above 1.0 clip. The optics are a Gaussian blur with $\sigma = 0.6$ px. The sensor adds photon noise (variance $Y/800$) and read noise ($\sigma = 0.004$). The result is gamma-encoded to 8 bits.
4. Reading. The reference decoder looks for the symbol in the whole frame, fits its outline and decodes it. A read counts only if the full 20-byte payload comes back, so its Reed–Solomon and CRC-32C checks passed.
5. Measure. For each design and room, $S$ steps from 40 to 130 px in 6 px increments, with 12 trials per step. Each trial has a different noise seed and sub-pixel phase. The read floor is the smallest $S$ at which at least 9 of 12 trials read. Smaller is better, and "no read" means no size up to 130 px met that bar. A 130 px code here has about 4.2 camera pixels per module.

The model does not include the display's pixel structure (sub-pixels, moiré), viewing angle, rolling shutter or motion. It is a model of tone and exposure, not of the whole optical chain. The source of the model is published alongside this paper (see Data and code).

Results

Field observations by design

Table 1. Published designs observed in the field (same sitting, same display), with their luminance contrast. Distances are approximate and ordinal.

Two patterns are visible. Every design with a dark background read well, and every dark-background design in the catalogue also has a vignette. Among light designs, readability does not rise with contrast: Plain, at the maximum 21:1, read worst.

Controlled contrast series

Table 2. Neutral-grey candidates with round marks. Contrast from Section 2.1; $\Delta E_{00}$ from pure white and pure black respectively.

Softening from 21:1 to the 14–16:1 range (A, B, D) produced backgrounds within about 2 $\Delta E_{00}$ of white, which look plain in isolation, and gave no loss. At 12:1 (E), readability was clearly worse. Once the phone was held square-on, Plain itself behaved like A, B and D. Viewing angle, not contrast, had been the main uncontrolled variable in Table 1's light-design results. Changing Plain's rounded-square marks to round marks increased its distance from about 5–10 cm to about 25 cm in the earlier, angle-uncontrolled sitting. This hints that mark shape interacts with the display's pixel grid (Section 6), a factor the simulation does not model.

Vignettes do not matter by themselves

Table 3. Simulated read floor (px; smaller is better) with a dim room (0.03), with and without a vignette. Every other setting is identical.

On both dark designs, a vignette changes nothing. Its apparent benefit in Table 1 is a confound: in the catalogue, vignette and dark background always come together. On Plain, a vignette that darkens the edge to grey makes an unreadable code readable, but only marginally (118 px). We show next that this works by changing the frame's brightness distribution, not because a vignette is good in itself. Adding accents, or switching Plum's round marks to rounded squares, made no difference in the simulation (all three Plum variants: no read).

The room around the display

Table 4. Simulated read floor (px) against room brightness. The screen page is 0.92 throughout.

Figure 1. Read floor against room brightness for a light and a dark design (data in Table 4). Hollow markers in the top band are rooms in which the design did not read at any size up to 130 px.

The dependence is strong and symmetric. Light designs fail when the room is much darker than the screen. Dark designs fail when the room is as bright as the screen or brighter, and they read best in a dark room. Changing the brightness of the screen page around the symbol (from 255 down to 40 in 8-bit grey) did not rescue Plain in a dim room. What matters is the tone that dominates the camera frame, not the tone just around the code.

A single number describes both standard designs. Let $Y_{\text{bg}}$ be the luminance of the symbol's background and $Y_{\text{scene}}$ the luminance that dominates the frame (here, the room). Define the background-to-scene ratio

Both designs read best at $\rho$ below about 5, degrade from about 10 to 20, and fail at about 30 or more. In plain terms: the symbol's background should be within about an order of magnitude of the brightness of the scene the camera sees.

No design reads in every room

Table 5. Simulated read floor (px) for candidate designs across rooms. "–" means no read up to 130 px.

None of the nine designs read in all five rooms. Plain covered the widest range (four of five rooms). Dark designs covered the three darker rooms. Mid-tone backgrounds did not straddle both regimes. They shifted where failure occurs, and with black ink they did worse than either extreme, so $\rho$ alone does not describe them: ink polarity matters too. Vignettes that fade to a contrasting edge never read, in any room.

Discussion

Why the published dark designs read so well on screens

Screens are usually brighter than the rooms they sit in, especially indoors in the evening. A camera that meters the whole scene then exposes for the room, and a light symbol's background ends up far brighter than the scene around it, with large $\rho$. A dark-background design keeps $\rho$ small in exactly those conditions. That, not the vignette, is why the vignetted designs topped Table 1. The same reasoning predicts that in a bright room, or in daylight, the dark designs would be the ones to fail. Table 5 confirms this in simulation.

Why softening contrast helps only a little

Maximum contrast does not hurt readability in itself. Once viewing angle was controlled, Plain matched the softened candidates (Table 2). Softening to 14–16:1 is harmless and nearly invisible, since a background of 246 is 1.8 $\Delta E_{00}$ from white. It gives a little headroom against clipping on bright displays. Going below about 13:1 costs reliability. The useful band for screen designs is therefore about 14–16:1, with 13:1 as a floor.

What this implies for readers

The pattern in Tables 4 and 5 is what one expects when dark and light are judged against the brightness distribution of the whole frame (Section 2.3). When most of the frame is a room much darker or brighter than the symbol's background, a whole-frame reference sits in the wrong place for the symbol. When we repeated the simulation reading only the symbol and a margin of one third of its width around it, every design in Table 4 read in both the dark room (Plain and Plum from 94 px, Midnight from 100 px) and the bright room (106 to 118 px).

This is a property of how a reader references tone, not of the symbol. A reader that judges tone locally, or reads a region of interest around the code, removes most of the dependence on the room, and with it most of the advice that follows. Until such readers are universal, design choices can compensate.

Practical guidance

1. Match the background to the scene. For codes that will mostly be shown on screens viewed indoors, prefer a dark background with light ink. For print, and for screens in bright places, prefer a light background with dark ink. Aim for a background-to-scene ratio $\rho$ below about 10. Above about 30, expect failure with readers that reference the whole frame.
2. Do not rely on mid-greys to cover both cases. In our tests they narrowed the working range rather than widening it.
3. Keep contrast between about 14:1 and 16:1 for screen designs, and above 13:1 in any case. Neutral pairs such as background (246, 246, 246) with ink (28, 28, 28) look like plain black on white and gave full readability.
4. Treat vignettes as decoration. They neither help nor hurt a dark design. Never fade a light background to a dark edge, or a dark one to a light edge: every such design in Table 5 failed in every room.
5. Accents and mark shape: accents had no measurable effect in our tone model. Round marks may help on displays, where they appeared to reduce failures in the field, but this needs a controlled test that includes the display's pixel structure.
6. For print, keep maximum contrast. Paper does not emit light: it sits at about the brightness of its surroundings, which keeps $\rho$ small, and lower contrast only costs margin in poor light.

Limitations

The field observations come from one observer, one phone, two displays and one evening. Distances were estimated and conditions were not fully controlled. The simulation models tone, exposure, blur and noise only: no display sub-pixels or moiré, no viewing angle, no motion. Its absolute numbers (read floors in pixels) belong to the model and should not be read as distances. Only Profile 0 version 1 with one payload was tested, and with one reference decoder version; denser versions have finer marks and may respond differently. The background-to-scene ratio is an empirical descriptor fitted to two high-contrast designs, and mid-tone designs did not follow it. We welcome replications, especially field measurements in bright rooms and daylight, through the field-test programme at openckey.org.

Data and code

• Simulation: the parameters are as stated in Section 3.3. The C++ source of the simulation, which links the reference CKey core, is published at openckey.org/findings/supplementary/ocf-2026-001-simulation.cpp.
• Reproducibility: the random seeds are fixed per size step, so the published tables are reproducible exactly with core version 0.1.0-build.85.
• Design colours: the colours of every published design are in the openckey.org design catalogue.

References

1. International Electrotechnical Commission. IEC 61966-2-1:1999. Multimedia systems and equipment: Colour measurement and management, Part 2-1: Default RGB colour space, sRGB. 1999.
2. World Wide Web Consortium. Web Content Accessibility Guidelines (WCAG) 2.1, definitions of relative luminance and contrast ratio. W3C Recommendation, 2018. https://www.w3.org/TR/WCAG21/
3. Sharma, G., Wu, W., and Dalal, E. N. "The CIEDE2000 color-difference formula: Implementation notes, supplementary test data, and mathematical observations." Color Research & Application 30(1), 21–30, 2005.
4. Otsu, N. "A threshold selection method from gray-level histograms." IEEE Transactions on Systems, Man, and Cybernetics 9(1), 62–66, 1979.
5. Sauvola, J., and Pietikäinen, M. "Adaptive document image binarization." Pattern Recognition 33(2), 225–236, 2000.

@misc{ocf2026000001,
  author       = {Caleb Owen},
  title        = {{Rendered readability of CKey designs on screens: tone, contrast, vignettes, mark shape and the room around the display}},
  year         = {2026},
  howpublished = {Open CKey Findings},
  number       = {OCF-2026-000001},
  version      = {1},
  url          = {https://findings.openckey.org/p/rendered-readability-of-ckey-designs-on-screens},
  note         = {Licensed under CC BY 4.0}
}