Generate a DataMatrix code as PNG bytes or pixel data in .NET

When a DataMatrix generator built on System.Drawing meets a .NET 7 migration, it stops: the drawing stack is Windows-only from .NET 6 on, and your old generator drew through it. The fix is to skip raster drawing entirely. ZXing.Net's DataMatrixWriter hands you the symbol as a module matrix, and a few lines turn that matrix into the two things engineers actually ask for: a raw pixel buffer, or PNG bytes wrapped in a base64 string. This guide builds both paths end to end, sizes them for a 300 × 300 image, and shows the checks that catch a flipped or blank output before it reaches your line.

What you need

• The ZXing.Net package from NuGet. Its core encoder is pure .NET: no GDI+ and no platform-specific build.
• .NET 7 or later, on Windows, Linux or in a container.
• The payload string that goes into the symbol.
• The consumer's expectation: raw pixels or an encoded file. The byte math differs by more than a factor of a hundred, so settle it first.

The old path failed twice over. System.Drawing.Common draws only on Windows from .NET 6 on. And its indexed pixel formats — Format8bppIndexed is the one that bites in barcode work — make a plain buffer copy awkward, because you first have to walk palette-indexed bytes. The matrix path below never creates an indexed image, so there is nothing to convert.

Choose the output: pixel buffer, PNG bytes or SVG

Three shapes cover every request to hand over a DataMatrix as bytes. Decide by consumer, not by habit.

Send PNG bytes whenever the consumer accepts a file: an API body, a database field, a message queue. Hold the raw buffer when the other end indexes pixel values directly: a decoder working on in-memory arrays, a print head, display code. Pick SVG text for label masters that must scale cleanly. Base64 is not a fourth option; it is the transport wrapper over any of the three.

Generate the module matrix, then expand it to pixels

1. Reference ZXing.Net in the project that used to call DataMatrix.Net.
2. Create the writer: new ZXing.DataMatrixWriter().
3. Ask for the symbol at the size you want. The call writer.encode(content, BarcodeFormat.DATA_MATRIX, 300, 300) returns a module matrix that reports its width and height and answers true for every black module, false for every white one. DataMatrixWriter, BarcodeFormat.DATA_MATRIX and this encode overload are the library's own API; the width and height fields and the [x, y] module look-up are its public surface in current builds.
4. Walk the matrix row by row into one byte per pixel: 0 for black, 255 for white.
5. Call Convert.ToBase64String on the buffer when the caller wants a string.

using ZXing;

var content = "LUMA-4471-B";                        // the payload that goes into the symbol
var writer  = new DataMatrixWriter();
var matrix  = writer.encode(content, BarcodeFormat.DATA_MATRIX, 300, 300);

var gray = new byte[matrix.Width * matrix.Height];  // 8-bit grayscale: 300 * 300 * 1 = 90,000 bytes
for (int y = 0; y < matrix.Height; y++)
    for (int x = 0; x < matrix.Width; x++)
        gray[y * matrix.Width + x] = (byte)(matrix[x, y] ? 0 : 255);

string base64 = Convert.ToBase64String(gray);       // 90,000 bytes in, 120,000 characters out

The matrix comes back at the requested 300 × 300. The library scales the symbol up in whole-module steps and centers it, so the pixel pitch follows the symbol size your payload produces. The same integer-scaling behavior, worked through for QR, is in the QR code quiet zone and integer module scaling guide. If you also build 1D test targets, the EAN-13 bitmap guide follows the same buffer discipline.

Wrap the buffer in PNG bytes

A PNG is your buffer plus a header, per-row filter bytes and compressed streams, so any encoder that accepts a byte buffer with width and height works.

1. Pick a pure .NET PNG writer from NuGet, or an imaging library such as SkiaSharp asked for PNG output. Nothing that requires a System.Drawing Image.
2. Hand it the gray buffer, the width and height, and the 8-bit grayscale format.
3. Take the returned byte array. That array is the PNG file, byte for byte.
4. Call Convert.ToBase64String on it when the caller wants a string.

// pngEncoder and gray8 stand in for the names your chosen encoder uses:
// each takes buffer, width, height and format, and returns bytes
byte[] png    = pngEncoder.Encode(gray, 300, 300, gray8);
string base64 = Convert.ToBase64String(png);

The size collapse is the payoff. A DataMatrix row is long runs of a single byte value, and PNG compresses each row before storing it, so the 90,000-byte buffer typically lands between 300 and 800 bytes of PNG. If the receiving decoder rejects those bytes, the usual cause is a mismatch between file bytes and raw pixels — the same mismatch the QR code image data type guide untangles.

The shortcut: BarcodeWriterPixelData

ZXing.Net ships a class that merges encode and render in one call: ZXing.BarcodeWriterPixelData.

1. Construct ZXing.BarcodeWriterPixelData.
2. Set its format to BarcodeFormat.DATA_MATRIX, and put 300 and 300 into its options' width and height; add a margin of four modules to keep a quiet zone inside the image.
3. Call its Write method with the content string.
4. Read the returned pixel object: it carries the byte buffer with its width, height and pixel format. One byte per pixel means grayscale output, three means RGB, four means 32-bit.
5. Call Convert.ToBase64String on the buffer when the string is the goal.

The class runs the scaling loop from the previous section for you. Keep the raw-matrix path in reserve anyway: it lets you invert, crop or threshold pixels before anything encodes them, and it shows exactly where the bytes come from.

Worked example: the 300 × 300 migration call, sized end to end

Inputs, and where each comes from:

• Payload LUMA-4471-B, a part serial in the shape these generators usually carry.
• Requested output 300 × 300 pixels — the size your pre-migration two-liner already used.
• Buffer format 8-bit grayscale, one byte per pixel — the buffer this guide builds.
• base64 rule: four characters per three bytes, no line breaks.
• Symbol: a short alphanumeric payload yields a small square DataMatrix; take 24 × 24 modules with a 4-module margin, 32 modules across.

The rules in words: the buffer costs width times height times bytes per pixel, and base64 turns each group of three bytes into four characters.

The arithmetic:

• Buffer: 300 px × 300 px × 1 byte = 90,000 bytes.
• base64: 90,000 / 3 = 30,000 groups; 30,000 × 4 = 120,000 characters, with no '=' padding because 90,000 divides by three exactly.
• Module pitch: 300 px / 32 modules ≈ 9.4 px per module.
• PNG: the same 90,000 bytes compressed, typically 300-800 bytes; base64 of that is 400-1,100 characters, about 1 kB of text.

Decision: send the PNG. About 1 kB of text moves instead of 120,000 characters — better than a hundred times smaller on the wire. Keep the 90,000-byte raw buffer only when the consumer indexes pixels directly: a decoder fed in-memory arrays, a print head, or a display. The threshold reads: if the receiver accepts a file format, PNG wins; raw only when it must have pixels.

Read the bytes back before you trust them

Generation code hides its bugs well: a flipped or inverted buffer still looks like a perfect symbol. Two checks catch everything.

First, decode it. Feed the PNG through the production pipeline — the same one described in camera barcode decoding: from image to validated data — and expect the payload on the first frame. A freshly generated symbol that fails to decode points at your buffer math, not at the content.

Second, look at the finder pattern. A DataMatrix prints a solid L along its left and bottom edges and an alternating dashed border on top and right. An L along the top means the rows are in bottom-up order: flip the row loop. An all-white or all-black image means the polarity or the bytes-per-pixel scaling is off.

For a line-side target, put the PNG on a screen or print it at 300 dpi or better, and read it with real hardware — any of these fixed code readers:

The MV-ID3013PM-12M-WBN pairs a 12 mm focal length with a 1.3 MP sensor on Fast Ethernet. The LS-CRD-0028 reads 2560 × 2048 frames at 30 fps and up to 60 codes per second through an 8 mm lens. The LS-CRD-0047 reads at 60-120 mm over USB 2.0, which suits a bench fixture for print tests. Wire the reader to a part-present trigger instead of free-run; the GPIO trigger guide covers the pin and the setting. Reading distance versus module size follows the same geometry as any 1D symbol, worked out in the Code 128 module size guide.

Common mistakes and the checks that catch them

• All-white or all-black output: the polarity or the bytes-per-pixel scaling is wrong. gray[0] must read 255 (top-left margin) and the buffer length must equal width × height.
• Perfect on screen, dead on the line: the symbol fell to one or two pixels per module after scaling. Re-request a larger image rather than letting the consumer shrink it.
• Decoder rejects the bytes: it expects a file's bytes, not a raw buffer, or the reverse. Match the consumer before you touch the generator.
• Two '=' at the end of the base64 string: correct padding for an odd byte count, not corruption.
• Reaching for System.Drawing just for the encoder: it draws only on Windows from .NET 6 on, so the container build breaks. Keep the generator pure .NET.

Where this leaves you

Pick the output by consumer, generate the matrix, and decode your own bytes back once before the first production run. When the check moves from the bench to the line, the camera finder narrows readers by interface, resolution and mount, and cameras that decode in-device are listed under smart cameras. More on the reading side sits on the code-reading topic page.

If the reading side needs a second opinion, the contact page is the direct route to us.