QUICKUPSCALE

PRACTICAL GUIDE

Pixel-art PNGs and transparency

Count visible colors versus RGBA values in a PNG

Start here

Choose the counting basis first. The actual 8×8 control produced 12 visible RGBA keys but only 10 visible RGB triples; All decoded RGBA produced 13 keys. Its declared raw source has 14 all-RGBA keys, because two hidden colors merged during browser decoding.

Expected result:

Both actual modes matched independent counts, ordering and swatch pixels from the browser readback. Visible included 48 pixels and excluded 16; All included all 64. Equal palette sizes do not imply unchanged channel values.

What you need

Download the original 8×8 alpha control. Its raw source declares 32 opaque, 16 partially transparent and 16 fully transparent pixels. Keep the original and source reference report when comparing them with actual browser results.

Tested with: Desktop Google Chrome 154.0.8037.44; browser UAData reports macOS platformVersion 27.0.1 and arm/64. Actual Cloudflare bundle cccc66d; independent window OffscreenCanvas reference and Python 3.14.8/Pillow 12.3.0 verification. No production-worker raw capture or physical-device acceptance.

1. Distinguish RGB triples from RGBA keys

Visible mode includes alpha above zero and counts all four bytes in each key. In the original raw source, (16,32,48,255), (16,32,48,128) and (16,32,48,1) share RGB but differ in alpha. That is why counting RGBA is a different question from counting RGB triples.

The declared source has 12 visible RGBA keys/10 RGB triples and two hidden alpha-zero tuples, for 14 all-RGBA keys. These source facts are retained in the project’s declared-source-rgba8 reports; they must not be relabelled actual browser counts.

2. Extract the visible decoded palette

In the palette extractor, choose alpha-control.png, select Visible decoded RGBA and press Extract colors. Save the ZIP and its separate report/PNG anchors before changing the mode.

The actual visible report includes 48 pixels/12 RGBA keys and excludes 16 transparent pixels. Independent counting finds 10 visible RGB triples. Its alpha categories are 32 opaque, 16 partial and 16 transparent.

Actual visible decoded RGBA swatch containing twelve entries
48×4px. Actual visible-mode swatch; partial-alpha entries retain separate RGBA keys.

3. Run All on the same original file

Select All decoded RGBA and run again, saving the new artifacts separately. The actual All report contains 13 keys and includes all 64 pixels. Its leading entry is [0,0,0,0] with 16 pixels: both original hidden RGB tuples decoded to that single transparent tuple.

Actual all-mode swatch containing thirteen decoded RGBA entries including one transparent entry
52×4px. Actual 13-entry All swatch; its transparent cell may look empty. The separate raw 14-key reference is 56×4.

Both runs’ saved reports, manifests and PNGs matched their ZIP members. The visible manifest and All manifest explicitly use worker-canvas-readback; neither claims to recover channel values lost before counting.

4. Report the measured boundary

Source-to-browser comparison found 24 changed pixel positions: 16 hidden-RGB positions and eight visible partial-alpha positions. Alpha values and opaque-RGBA values were unchanged. Visible key counts happened to remain 12/10, while All fell from 14 raw keys to 13 decoded keys.

The independent readback used a window OffscreenCanvas with the production bitmap options and canvas sequence. It was not an instrumented production-worker capture. Saved report/swatches matched that independently supplied plane exactly; the original source plane remained separate and unchanged.

For visible-art work, exclude alpha-zero pixels and say whether alpha participates in the key. For file analysis, use a decoder with an explicit channel contract. All decoded RGBA is an inspection of decoded values, not a hidden-RGB recovery mode or a general claim about PNG palette chunks.

Sources and next steps