A 200 KB Image Does Not Mean 200 KB of Decoded Pixel Memory

The built-in imagegen cover is a compact-file and expanded-pixel concept. It is not a measured 200 KB asset, compression ratio, or memory benchmark.

An image file reduced to 200 KB does not imply its decoded pixel data occupies 200 KB. It also does not establish the memory used by a game process or GPU. Decide whether the current goal concerns download bytes, image dimensions, or measured runtime allocation before evaluating an optimization.

The Resource Compression tool can help prepare delivery files. Record the output separately from pixel dimensions and runtime observations. No project benchmark is claimed here.

Define a calculable representation

MDN documents ImageData.data in RGBA order and specifies a Uint8ClampedArray for rgba-unorm8. For the limited model of one contiguous buffer containing four 8-bit channels per pixel, calculate width × height × 4 bytes. This excludes additional copies, object overhead, GPU allocations, mipmaps, and other pixel formats.

Work through three square images

• 1024 × 1024: 4,194,304 bytes, or 4 MiB.
• 2048 × 2048: 16,777,216 bytes, or 16 MiB.
• 4096 × 4096: 67,108,864 bytes, or 64 MiB.

Here, one MiB equals 1,048,576 bytes. These values describe only the stated RGBA8 model. They do not predict browser process memory, engine texture allocation, or peak loading usage. The encoded file can have a different size depending on its representation and content.

What changes when file bytes fall but dimensions stay fixed?

If a 2048-square image still expands into the same-sized RGBA8 representation, the single-buffer model remains 16 MiB. A smaller delivery file can reduce transfer bytes. Its percentage reduction does not establish the same percentage reduction in that pixel buffer.

This does not make encoding optimization pointless or prove that one format is faster. Decode behavior, caching, representation, and platform handling need observation in the target environment. The PNG, WebP, and AVIF guide discusses delivery choices; do not automatically apply a website-image choice to every engine texture.

Why halving both dimensions gives one quarter of the model

With the same pixel representation and number of buffers, changing 2048 × 2048 to 1024 × 1024 leaves one quarter as many pixels. The model therefore falls from 16 MiB to 4 MiB. That has a visual cost to assess: text, outlines, icons, and alpha edges may no longer meet display requirements.

Establish the intended display use and required resolution before resizing. Do not shrink every source merely to obtain a lower number. Preserve editable masters and compare delivery copies at the dimensions that matter.

Transparent space still belongs to this model

A fully transparent region remains part of width × height in the fixed, complete RGBA8 buffer considered here. It may encode compactly in a file, but that does not remove the corresponding positions from the same-sized buffer.

Trimming transparent borders may reduce dimensions, while also changing the reference space of an animation frame. Confirm a shared canvas or the real offset representation before optimizing a sequence. A smaller model is not useful if alignment is lost.

Keep three separate acceptance records

• Delivery file: format and actual byte count, explicitly identified as file or transfer observations.
• Image: real dimensions, alpha edges, and visual quality. Include the RGBA8 model only when its assumptions apply.
• Target runtime: actual project metrics under the same device, scene, and loading scope, with the measurement tool and metric identified.

If only file compression was tested, report the file change. Do not claim lower GPU allocation or a faster first load without measuring those outcomes. The visual compression review helps inspect the artwork; runtime performance remains a separate validation.