How Many Pixels Fit in a DMX Universe?

One DMX universe fits 170 RGB pixels (using 510 of its 512 channels) or 128 RGBW pixels (using all 512 channels exactly). The reason: a universe carries 512 control channels, each pixel consumes one channel per colour emitter, and almost all controllers and software refuse to split a pixel across a universe boundary, so the count rounds down to a whole pixel.

Those two numbers are the planning constants for every pixel project, from a single strip to an architectural facade. Here is the arithmetic behind them and how to apply it.

The arithmetic

DMX512 (formally ANSI E1.11) delivers up to 512 data slots per packet, which lighting software presents as channels 1 to 512. A universe is one such block of 512 channels, whether it travels down an XLR cable or inside an Art-Net or sACN packet. Each channel holds one number from 0 to 255: how bright, how red, how blue.

A pixel is just a fixture that needs one channel per colour emitter at 8-bit depth:

• RGB pixel: 3 channels. 512 ÷ 3 = 170.67, so 170 whole pixels, occupying channels 1 to 510.
• RGBW pixel: 4 channels. 512 ÷ 4 = 128 exactly, occupying channels 1 to 512 with nothing spare.
• Single-colour pixel (for example a white-only dot): 1 channel, so 512 pixels per universe.

At 16-bit depth each colour uses two channels (a coarse byte and a fine byte) for smoother dimming, so every count halves.

Why 170 and not 170.67

Pixel number 171 in an RGB layout would need channels 511, 512, and 513. Channel 513 does not exist, and mainstream pixel software will not put a pixel's red on one universe and its green and blue on the next: the two universes can arrive at slightly different times, so the pixel's colours would update out of step. A pixel is addressed as an indivisible 3-channel or 4-channel block, the fraction is discarded, and channels 511 and 512 sit unused in every fully packed RGB universe. Two spare channels per universe is the accepted cost of keeping pixels whole. (A few niche firmwares can wrap a pixel across universes, but never design a system that depends on it: it breaks patch portability between tools.)

Pixels per universe at a glance

Note the pattern: 3-channel and 6-channel pixels always leave 2 channels spare, while 1, 2, 4, and 8-channel pixels divide 512 with no remainder. 8-bit is the norm for pixel strip and pixel dots; assume 8-bit unless your software and controller both explicitly offer 16-bit output.

Not all software fills the universe

170 is the practical maximum, and most modern tools use it, often expressed as "510 channels per universe" so the boundary always lands cleanly between RGB pixels. But you will meet other conventions in the wild:

• Some software and controllers default to a round figure such as 150 pixels (450 channels) per universe, trading capacity for easier mental arithmetic.
• Some patch workflows start each physical fixture (a 1 m strip segment, a tile) on a fresh universe, deliberately leaving channels unused so a fixture never straddles a boundary.
• Some sequencing tools let you set channels-per-universe yourself; 510 is the usual choice for RGB, 512 for RGBW.

None of these are wrong. The universe itself always has 512 channels; these are packing choices, not protocol limits. What matters is that the sending software and the receiving controller agree on the same channels-per-universe figure, otherwise everything after the first boundary shifts along the strip and the display tears at each universe.

Planning: from pixel count to hardware

Universe count is the currency of pixel planning. Divide your pixel count by 170 (RGB) or 128 (RGBW), round up, and that is your universe budget. Then check it against the per-port and per-unit capacity of your controller.

On an Ethernet-to-pixel controller (a device that receives Art-Net or sACN over a network and drives the strip directly), universes are allocated per physical output. ENTTEC's OCTO MK2 drives 8 universes across 2 outputs (4 per output, up to 680 RGB pixels each), and its overdrive mode raises that to 16 universes, which works out to 2,720 RGB or 2,048 RGBW pixels from one unit. The OCTO MK3 extends this to 32 universes across up to 4 outputs, rated for up to 5,440 RGB or 4,096 RGBW pixels per device. Notice that the datasheet figures are exact multiples of the constants: 5,440 is 32 × 170. When any controller quotes a pixel count, dividing it by 170 tells you immediately how many universes of network capacity it consumes. If sending universes over a network is new to you, Art-Net explained covers how universes are numbered and carried over Ethernet.

On the software side, ENTTEC's ELM pixel-mapping software handles the universe packing for you: you draw the fixture, and it allocates whole pixels to universes automatically. ELM's installer is free to download, so you can build and verify your patch before committing to hardware; the licence sets how many universes you can output, and full licences come bundled with ENTTEC pixel controllers.

Worked example

You have 5 m of 60 pixels/m RGB strip: 300 pixels, needing 300 × 3 = 900 channels.

• Universe 1: pixels 1 to 170, channels 1 to 510 (channels 511 to 512 unused).
• Universe 2: pixels 171 to 300, that is 130 pixels on channels 1 to 390 (122 channels unused).

Total: 2 universes. The same strip in RGBW (60 px/m, 4 channels each) would need 1,200 channels: universe 1 takes pixels 1 to 128, universe 2 takes 129 to 256, universe 3 takes the remaining 44, so 3 universes. Dense strip burns through capacity fast: a 10 m run of 144 px/m RGB strip is 1,440 pixels, and 1,440 ÷ 170 = 8.47, so budget 9 universes and confirm your controller has that much headroom across its ports.

Quick reference

• 1 universe = 512 channels, always.
• RGB pixels: divide pixel count by 170 and round up to get universes needed.
• RGBW pixels: divide by 128 and round up.
• A pixel never spans two universes; spare channels at the end of a universe are normal.
• Sender patch and controller configuration must agree on channels per universe, or colours shift down the strip.