Images & photos · Social Image Resizer
Display P3, sRGB and the Canvas: Why Colours Can Shift When You Resize
· Background
colour-management canvas image-quality
Many phones capture in the wide Display P3 colour space, while browser canvases and most social feeds assume sRGB, so re-encoding an image can change how saturated it looks. This post explains colour spaces, embedded profiles and what to check after a resize.
The sunset that lost its punch — the concrete symptom of a wide-gamut photo re-encoded for the web
A saturated sunset can look flatter after a browser resize, but the symptom alone does not identify one colour conversion. The source may carry a profile, the browser may interpret it, the canvas may use its own colour space and the new encoded file may omit metadata needed by another viewer.
ToolAcre’s limitation is carefully worded: colour profiles are not preserved through canvas, so an image with an unusual embedded profile may shift slightly. It does not promise a fixed sRGB conversion algorithm. This article follows that narrower evidence and recommends direct comparison instead of a universal diagnosis.
sRGB and Display P3 are useful concepts, but phone capture behavior is outside repository evidence
A colour space defines how numerical channel values map to colours. sRGB is widely used for web imagery, while Display P3 covers a wider region for some colours. “Wider” does not mean every photograph uses that extra range, and the repository does not establish which phones capture P3 by default.
Two files can contain identical channel numbers and render differently when interpreted under different profiles. Conversely, a colour-managed conversion can change numbers while preserving visual appearance. That is why copying pixel values or glancing at saturation is not enough to describe the whole colour path.
Embedded ICC profiles — how a file tells a viewer which space its numbers mean, and what happens when the profile is missing
An embedded ICC profile provides interpretation information to a colour-managed viewer. If a profile is absent, software applies its own default assumptions. Social Image Resizer does not extract a source profile and does not pass one to encodeCanvas; the new Blob is created from the rendered canvas.
The omission is different from proving that every output is tagged sRGB. To know what a specific browser encoder wrote, inspect the file. To know whether appearance remained acceptable, compare rendered originals and outputs under controlled conditions. Metadata evidence and visual evidence answer related but distinct questions.
The tool does not preserve source profiles; exact canvas colour conversion is browser-controlled
The workbook says canvases work in sRGB by default. Browser canvas APIs have evolving colour-management capabilities, and this app does not request an explicit colourSpace option on context creation or encoding. Exact decode, conversion and output behavior therefore belongs to the browser implementation.
The safe product claim is that source profiles are not preserved by this workflow. Record the browser and version when colour matters. Another engine may interpret or encode the same source differently even though both execute the same renderFrame call and return the same dimensions.
Destination feed and screen colour behavior must be observed rather than generalised
It would also be too broad to say most feeds and screens make the shift invisible. The repository contains no destination or display population evidence. A colour change can be negligible for one audience and critical for brand graphics, artwork or product photography. Acceptance belongs to the actual delivery context.
Compare on a representative screen at normal brightness and in the destination preview when possible. Keep the original visible beside the local output so memory does not substitute for evidence. If exact brand colour is mandatory, use a colour-managed production workflow with explicit profiles and proofing controls.
Worked example: compare one profiled source and output without prescribing two screen results
Choose a non-sensitive source with a known embedded profile and saturated but natural colours. Inspect its profile, resize it through ToolAcre and inspect the output. View both files side by side in the same colour-managed application and browser. Note any changes without assigning them to an unverified stage.
Repeat on a second screen only if that screen is part of the real audience or review workflow. The goal is not to produce a predetermined P3-versus-sRGB result. It is to gather file and appearance evidence for the specific source, browser encoder and displays involved.
What this does not cover — professional colour management, soft proofing and HDR formats; the Social Image Resizer's technical notes describe how it handles profiles
Professional soft proofing, HDR formats and calibrated print delivery are outside this app. Input is limited to browser-decodable JPEG, PNG and WebP, and output uses browser canvas encoders. There is no profile selector, rendering-intent control or monitor calibration step.
Those needs call for dedicated colour-managed software. ToolAcre remains appropriate for quick social derivatives when observed output is acceptable. Knowing its profile boundary helps teams decide which images are routine and which require a stricter colour pipeline.
Takeaway: know the space your file is in — the Social Image Resizer re-encodes in the browser, so compare the output with the original on the screen your audience uses
Know the profile status of the source and treat the resized file as a new colour artifact. The app can prove that it redraws pixels and does not deliberately preserve the source profile; it cannot promise one exact conversion across all browsers or destinations.
Compare, inspect and document. If the output passes on representative screens and in the destination, the evidence supports the delivery. If it fails, return to a controlled colour workflow rather than trying to fix saturation blindly with another canvas export.