A map pixel is one byte, and two of its bits are brightness
61 base colours × 4 shades = 244 colours from a 16,384-byte array. Only one of the four shades is the block's real colour; the other three are darkened to 86%, 71% and 53%.
Every filled map in Minecraft is the same size on disk: a colors byte array of exactly 16,384 entries, which is 128 × 128. That is true of a scale-0 map covering 128 blocks and a scale-4 map covering 2,048 blocks — the pixel count never changes. Everything else about map art follows from that one fact.
The byte splits in two
Each of those 16,384 bytes is not a colour. It is a base colour and a shade packed together:
baseColorId = colorId >> 2 // 0–63
shadeIndex = colorId & 3 // 0–3So the low two bits are brightness and the rest is which block you are looking at. With 61 base colours defined (id 0 is the transparent/unexplored slot), the highest byte a real map holds is 61 × 4 + 3 = 247.
61 × 4 = 244 distinct colours, which is the entire palette available to map art. Not 61, and not 256.
Only one shade is the block's actual colour
The four multipliers are not evenly spaced, and one of them is 1.0:
| shade index | multiplier | as a percentage |
|---|---|---|
| 0 | 180 / 255 | 70.6% |
| 1 | 220 / 255 | 86.3% |
| 2 | 255 / 255 | 100% |
| 3 | 135 / 255 | 52.9% |
Shade 2 is the block's texture colour, untouched. The other three are darker versions of it, and the darkest — shade 3 — is only just over half brightness.
This is why staircased map art looks so different from a flat one. A flat build can only ever produce one of these four per block, so a flat map has 61 colours available. Varying the height unlocks the other three shades of every block and takes you to 244. The palette does not get wider — you get no new hues — it gets four times deeper in value, which is exactly what dithering needs.
Note also that the shade ordering is not monotonic: index 3 is the darkest, not the brightest. Sorting by index and expecting a gradient gets you 71%, 86%, 100%, 53%.
Scale multiplies area, never resolution
The scale field runs 0–4, and the ground it covers is 128 × 2^scale blocks on a side:
| scale | blocks covered | one map pixel is |
|---|---|---|
| 0 | 128 × 128 | 1 block |
| 1 | 256 × 256 | 2 × 2 blocks |
| 2 | 512 × 512 | 4 × 4 blocks |
| 3 | 1,024 × 1,024 | 8 × 8 blocks |
| 4 | 2,048 × 2,048 | 16 × 16 blocks — exactly one chunk |
A scale-4 map covers 256 times the area of a scale-0 map using the same 16,384 bytes. That is the whole reason map art has to be built at scale 0: at any other zoom, one pixel is an average of several blocks and the image you carefully placed is resampled away.
The scale-4 row is worth remembering for a different reason — one pixel is precisely one chunk, which makes a fully-zoomed map a usable chunk grid.
What this means for a corrupt file
If a map_<id>.dat has a colors array that is not 16,384 bytes, it is not a map with missing pixels — it is not a readable map at all. There is no partial-length form. The array is always full-size, with unexplored areas stored as colour id 0 rather than omitted.