Pixel Map for LED Walls: How the Canvas Maps to Cabinets
By VJ Ries · Published 2026-07-12 · Updated 2026-08-01 · 9 min read
A pixel map is the mapping of a content canvas onto the physical pixels of an LED wall. It tells the processor which slice of the image belongs to each cabinet, and where that cabinet sits in the picture. Get it right and content lands exactly where it should, at native resolution; get it wrong and the same footage shows up offset, stretched, mirrored, or split across a seam. Building one starts with arithmetic. Cabinet pixel dimensions times the cabinet grid gives the wall's total resolution, which is the canvas your media server should output.
What is a pixel map for an LED wall?
Content is one flat image; the wall is a grid of physical tiles. Connecting the two is a pixel map, the processor's lookup table for the picture: for every cabinet on the wall, it records which rectangle of the content canvas that cabinet shows and where the cabinet sits in the overall image. The pixel map lives in the LED processor rather than in the media server.
Follow a single pixel of content from playback to the wall and the whole system falls into order:
- Content canvas, the image your media server or playback machine renders, one flat rectangle measured in pixels.
- Processor, where the pixel map lives, takes that canvas and decides which rectangle of it feeds each data port and each cabinet.
- Cabinets, the physical tiles, each a fixed block of pixels that displays its assigned slice of the canvas.
- Receiving cards, inside each cabinet, drive the actual LEDs for that block of pixels.
Why the pixel map matters
The map is the difference between a picture and a scrambled picture, and when it is wrong, every failure looks like a different problem but traces back to the same table:
- Offset, content starts one cabinet or one row off, so a logo that should be centered hangs half off the edge.
- Stretched or squashed, the canvas resolution does not match the wall, so the processor scales it and geometry distorts.
- Mirrored or rotated, a cabinet mapped with the wrong origin or orientation sends the right pixels to the wrong place.
- Seam or gap, two cabinets map to overlapping or non-adjacent slices, leaving a doubled strip or a black line through the image.
- Wrong zone, on a multi-region wall, the ticker content lands where the IMAG should be.
None of these are hardware faults. Panels fine. Cables fine. Content fine. The map is telling good pixels to go to the wrong place, which is exactly why the fix is checking the map before you start swapping cabinets on show day.
Step 1: get the wall's total resolution
The map is built on one number: the wall's total resolution in pixels. That is pure arithmetic. Every cabinet carries a fixed pixel array (read it off the datasheet, for example 256 by 256 pixels). The wall is a grid of those cabinets. Multiply through:
Wall width: 10 cabinets × 256 px = 2560 px Wall height: 6 cabinets × 256 px = 1536 px Wall canvas: 2560 × 1536 px Total pixels: 2560 × 1536 = 3,932,160 px (about 3.9 megapixels)
This 2560 × 1536 figure is the whole point of the exercise. It is the exact canvas size your content should be authored and output at for a one-to-one map, one content pixel per wall pixel.
Notice what drives the resolution: the pixel array per cabinet, a function of pixel pitch rather than the physical size of the wall; two walls the same physical size can have very different resolutions, and the same 10 by 6 grid of cabinets produces wildly different canvases depending on how many pixels each cabinet packs:
| Cabinet pixel array | 10 × 6 grid wall resolution | Roughly |
|---|---|---|
| 128 × 128 px | 1280 × 768 px | Below HD width; coarse pitch |
| 192 × 192 px | 1920 × 1152 px | HD width but taller than 1080; the wall is not 16:9 |
| 256 × 256 px | 2560 × 1536 px | Above HD; fine pitch |
How that pixel count then splits across processor data ports, and how many cabinets a single port can drive, is the data-path side of the job: it has its own math and its own limits, covered in how many panels a data port can drive and in the product notes on processor port limits. For the pixel map, all you need first is the total: the canvas the content has to fill; the physical grid itself comes from your cabinet layout.
Step 2: match the content canvas to the wall
Your target canvas is the wall resolution. Author and output content at that exact resolution and every wall pixel gets its own content pixel. Sharpest possible image, no scaling artifacts, no surprises. The trap is assuming a standard broadcast resolution fits. LED walls are almost never 16:9, so 1920 by 1080 rarely maps cleanly.
Wall aspect: 2560 ÷ 1536 = 1.67 (that is 5:3, not 16:9) 16:9 source aspect: 1920 ÷ 1080 = 1.78 Stretch to fill horizontally: 2560 ÷ 1920 = ×1.33 Stretch to fill vertically: 1536 ÷ 1080 = ×1.42 Different scale factors = distortion: a circle becomes an oval
To keep the geometry honest, author natively at 2560 × 1536, or place the 16:9 content inside that canvas with pillarbox/letterbox padding instead of stretching it edge to edge.
Zones and multi-source walls
Small walls are one canvas driven by one source. Bigger and more complex walls get split into zones: independent rectangles of the wall fed by different processors, different content regions, or different show segments. A common example is a main IMAG zone with a lower ticker or side scenic panels. Each is mapped to its own slice of the canvas and often its own playback output.
Zones are where naming discipline pays off. Give every zone a stable name. Keep it identical across the diagram, the wall layout, the wiring plan, and the media-server outputs. When a zone name means one thing to the content op and another to the LED tech, content ends up in the wrong region. That is a slow, embarrassing thing to debug live.
The media-server side, tool-neutral
Whatever drives the wall, a media server, a presentation switcher, or a laptop running playback, the job at the output is the same: produce a canvas whose resolution matches the wall canvas so the processor can map it one-to-one. You can also output a scaled canvas and let the processor scale to fit, but native resolution is always sharpest and removes one whole class of soft-image complaints. The pixel map lives on the processor. The media server's contribution is simply feeding it a correctly sized, correctly framed image.
How to build a pixel map, start to finish
- Confirm the exact cabinet grid (columns × rows) and each cabinet's pixel array from the datasheet.
- Multiply to get the wall's total resolution, the canvas size in pixels.
- Set the media-server or playback output to that resolution, or a known scale of it, and set the content aspect ratio to match.
- Define the origin corner and orientation, and confirm both against your processor's convention.
- If the wall splits across processors or content regions, define zones and name each one consistently across diagram, wall, and wiring.
- Assign each cabinet or zone its slice of the canvas: x/y offset plus width and height in pixels.
- Export the map, hand it to the content team and the LED tech, and verify it in the processor software once cabinets are live.
Common pixel-map mistakes
- Canvas mismatch, authoring content at 1920 × 1080 for a wall that is a different resolution and aspect, so everything is scaled soft or stretched out of shape.
- Gaps and overlaps, a cabinet mapped to the wrong offset, usually an off-by-one in cabinet pixel size or grid position, leaves a black seam or doubles a strip of the image.
- Orientation or origin flip, top-left versus bottom-left origin, or a physically rotated cabinet not accounted for, sends the correct pixels to the wrong spot.
- Stale map after an as-built change, a cabinet swapped or a row removed on site, but the map still describes the planned grid, so the content op works from a wall that no longer exists.
Build the pixel map in WireFlow
Software should do exactly the arithmetic above the instant you change the wall. WireFlow's LED wall builder computes the wall's total resolution from the catalog panel and your cabinet grid, and produces a pixel map view that aligns content tiles to physical cabinets, so the content team and the processor tech design against the same picture. It is a public tool. No account needed. Export specifics and zone handling live in the pixel map and zones guide; verify export settings against your own processor pipeline.
One piece of the LED prep packet, the map sits alongside the power draw the distro has to carry and the preproduction checklist of everything to confirm before the truck loads. Plan them together in one project and the content, power, and data stories all describe the same wall. The rest of the LED wall guides live in the LED walls cluster.
Frequently asked questions
- What is a pixel map on an LED wall?
- It is the mapping that tells the LED processor which part of the content canvas each cabinet displays, and where that cabinet sits in the overall image. The content is one flat picture. The wall is a grid of tiles. The pixel map connects them. It lives on the processor, not the media server.
- What resolution should my content be for an LED wall?
- Match the wall's total resolution. Cabinet pixel array times the cabinet grid. A 10 by 6 grid of 256 by 256 cabinets is 2560 by 1536 pixels, so content authored at 2560 by 1536 maps one-to-one for the sharpest image. LED walls are rarely 16:9, so check the aspect ratio before assuming 1920 by 1080 will fit.
- Why is my LED wall content offset or in the wrong place?
- Almost never a hardware fault. The pixel map is assigning cabinets the wrong slice or the wrong offset, or the origin corner does not match your processor's convention. Load a numbered test pattern to see the flip or offset, then correct the map and confirm the origin corner against the processor documentation.
- What is the difference between a pixel map and a data or daisy-chain map?
- A pixel map is about the picture: which canvas pixels each cabinet shows and where it sits. The data map is about bandwidth and cabling: how many pixels a processor port can carry and in what chain order the cabinets connect. You need both. They are separate calculations. See how many panels a data port can drive for the data side.
- Do I make the pixel map in WireFlow or on the processor?
- You plan and document it in preproduction: WireFlow computes the wall resolution and produces a pixel map view for the content and LED teams. The processor software still applies and verifies the actual map on site. Brightness, calibration, and any as-built cabinet changes get handled there. Treat the WireFlow map as the plan the processor is loaded to match.
Calculate your LED wall in WireFlow
Pick a panel, set the wall size, and get cabinet counts, pixel map, power load, and data paths, before anything ships to site.