Color blind simulator for images

What this color blind simulator changes

A color blind simulator transforms the RGB values in an image so you can inspect where colors that looked separate in the original begin to converge. That is useful for charts, maps, status labels, product swatches, diagrams and any interface that uses hue to carry meaning. Move the comparison control across the result instead of relying on memory: the edge makes changes in labels, series and adjacent regions much easier to locate.

The transform here follows the color-vision model published by Gustavo Machado, Manuel Oliveira and Leandro Fernandes. The browser decodes each sRGB channel into linear light, applies the selected 3 × 3 matrix, clamps values back to the displayable range and encodes the result as sRGB again. Applying the same matrix directly to the nonlinear bytes produces a substantially different—and incorrect—result. The implementation is checked against an independent asymmetric pixel corpus rather than against a screenshot that could hide a channel swap or rounding error.

Protan and Deutan are model families, not universal views

Protan and Deutan describe two red–green color-vision-deficiency families. The model can represent a continuous set of anomalous-trichromacy settings and their published endpoint. The strength control interpolates between the authors’ neighboring matrix samples. A value of 100 therefore means “the endpoint of this model,” not “100 percent color blind,” and it does not measure the severity of a real person.

A simulated image is never a promise that everybody in a category sees exactly those pixels. People differ, displays differ, ambient light changes perception, and a browser preview cannot reproduce the entire visual system. Use the result to find fragile design decisions: two lines distinguished only by red and green, a warning shown only by its fill, or text that disappears into a colored panel. Then correct the design with redundant cues such as labels, shapes, patterns or position.

Why the Tritan option says model approximation

The blue–yellow option has a deliberately longer name: Tritan model approximation. The Machado paper explains that its tritanomaly result is an approximation and does not establish the model as a tritanopia simulator. This route keeps that scientific boundary visible in the control and in the receipt. It does not quietly replace “approximation” with a stronger medical label because a shorter label would rank or scan better.

That makes the option useful for exploratory design review while keeping its limit honest. If your work depends specifically on a validated tritanopia projection, use a workflow with a separately implemented and verified tritanopia model such as the piecewise Brettel method. Do not treat this route’s Tritan output as that method, and do not use any of the three previews to decide whether a person has a color-vision deficiency.

A simulation is not a WCAG contrast check

WCAG’s use-of-color requirement asks whether color is the only visual means used to convey information, prompt a response or distinguish an element. A simulation can reveal likely failures of that design choice, but it cannot inspect the surrounding interaction or decide whether another cue is sufficient. The contrast requirements are a different measurement: they compare relative luminance for text, controls and graphical objects under defined rules. An image that remains understandable in every preview can still contain low-contrast text.

Review the original and all relevant model views, then check the actual page with keyboard, zoom and assistive-technology workflows. For categorical graphics, print the series names, vary marker shapes or line dashes, and verify that a grayscale view still leaves a usable structure. For state controls, pair color with text or an icon whose meaning is available to assistive technology. Those changes help far beyond any single simulated condition.

If you first need a compact, coverage-ranked set of source colors, use the color palette from image extractor. It analyzes every decoded pixel locally; this simulator then answers the separate question of how those colors change under a selected vision model.

Local pixels, explicit output limits

The selected image is decoded and transformed in a browser worker. Work is divided into bounded row chunks, so progress is the number of actual pixel rows completed rather than an animated estimate. Alpha bytes are copied exactly, and the result is encoded as a PNG in the same tab. No selected image is posted to CreatorValet or to the model authors.

The exported PNG contains the decoded canvas pixels. It does not promise to preserve an embedded ICC profile, camera metadata, animation, original JPEG compression or the source file format. A GIF is treated as the frame the browser decodes for the canvas, not as a new simulated animation. Keep the original file as the source of record and use the download as a review artifact.

Sources and reproducibility

The model is documented in Machado, Oliveira and Fernandes (2009), with the sampled matrices and interpolation rule in the authors’ UFRGS supplement. The distinction between simulation and accessible use of color follows W3C’s explanation of WCAG 2.2 Success Criterion 1.4.1. The US National Eye Institute’s color-blindness guidance describes professional testing. For questions about your own vision, the appropriate next step is an eye-care professional, not an uploaded image or an online preview.