What causes "Invalid LZF compressed data." in lutzroeder/netron?

Re-create or re-export the HDF5 file, ideally verifying with h5dump that the LZF chunk decodes with the reference implementation.

lutzroeder/netron · error · Error

Invalid LZF compressed data.

Error message

Invalid LZF compressed data.

What it means

While decompressing an LZF-compressed HDF5 chunk, the decoder encountered a literal run whose declared length (control byte < 32, encoded as c+1) runs past the end of the compressed input buffer. The compressed byte stream is malformed, so the decompressor refuses to continue rather than emit garbage data.

Source

Thrown at source/hdf5.js:1478

        }
    }

    _deflate(input) {
        const archive = zip.Archive.open(input);
        return archive.entries.get('').peek();
    }

    _lzf(input) {
        let i = 0;
        let o = 0;
        while (i < input.length) {
            let c = input[i++];
            if (c < (1 << 5)) {
                c++;
                i += c;
                o += c;
                if (i > input.length) {
                    throw new Error('Invalid LZF compressed data.');
                }
            } else {
                let length = c >> 5;
                if (i >= input.length) {
                    throw new Error('Invalid LZF compressed data.');
                }
                if (length === 7) {
                    length += input[i++];
                    if (i >= input.length) {
                        throw new Error('Invalid LZF compressed data.');
                    }
                }
                const ref =  (o - ((c & 0x1f) << 8) - 1) - input[i++];
                if (ref < 0) {
                    throw new Error('Invalid LZF compressed data.');
                }
                o += length + 2;
            }

View on GitHub (pinned to d8a543f5f8)

Solutions

Re-create or re-export the HDF5 file, ideally verifying with h5dump that the LZF chunk decodes with the reference implementation.
If you control writing, use a well-tested LZF filter build or switch to a lossless standard filter (gzip/SZIP) that this reader also supports.
Check for truncated transfer of the file (checksum the original).
If only some chunks are bad, isolate the failing dataset and re-write just that dataset.

Example fix

null

Defensive patterns

Strategy: try-catch

Validate before calling

function isPlausibleLzfChunk(buf, expectedDecompressedSize) {
  // basic sanity: non-empty and not all-zero payload
  return buf && buf.length > 0 && buf.some(b => b !== 0) && expectedDecompressedSize > 0;
}

Try / catch

try {
  data = decompressLzf(chunk, outSize);
} catch (e) {
  if (/Invalid LZF compressed data/.test(e.message)) {
    // surface 'dataset chunk is corrupted' and continue with other datasets
  } else throw e;
}

Prevention

Verify written files with h5dump after creating them with the LZF filter.
Use well-established LZF filter builds when writing HDF5.
Read datasets individually so one bad chunk doesn't abort the whole file view.

When it happens

Trigger: Decompressing a chunk stored with HDF5's LZF filter where the literal-run length pushes the input index beyond input.length. Triggered by dataset reads (the chunk is fetched and inflated) on any dataset created with the LZF compression filter.

Common situations: Corrupted .h5 files where chunk payloads are damaged, files produced by a buggy/alternative LZF compressor, truncated chunk data at the end of the file, or reading data whose chunk was never fully written (crashed writer). Rarely, version mismatches in the LZF filter format itself.

Related errors

AI-assisted analysis of lutzroeder/netron@d8a543f5f8 (2026-08-27). Data as JSON: /api/errors/a843ed01b7d9efc5. Report an issue: GitHub.