BabylonJS/Babylon.js · error · Error

Unsupported file format

Error message

Unsupported file format

What it means

After reading the EXR version bytes, GetExrHeader validates specData (byte 5, the version 'flags' field). Bit 0x02 (tiled) and 0x04 (long names / multi-part markers) are tolerated; any other flag bit set (e.g. 0x08 non-image/deep data or 0x10 multipart) means the file uses a format feature this parser cannot read, so it throws 'Unsupported file format'.

Source

Thrown at packages/dev/core/src/Materials/Textures/Loaders/EXR/exrLoader.header.ts:125

        const attributeName = ParseNullTerminatedString(dataView.buffer, offset);

        if (!attributeName) {
            keepReading = false;
        } else {
            const attributeType = ParseNullTerminatedString(dataView.buffer, offset);
            const attributeSize = ParseUint32(dataView, offset);
            const attributeValue = ParseValue(dataView, offset, attributeType, attributeSize);

            if (attributeValue === undefined) {
                Logger.Warn(`Unknown header attribute type ${attributeType}'.`);
            } else {
                headerData[attributeName] = attributeValue;
            }
        }
    }

    if ((specData & ~0x04) != 0) {
        throw new Error("Unsupported file format");
    }

    return { version: version, spec: spec, ...headerData };
}

View on GitHub (pinned to 0592b347b8)

Solutions

1. Re-export as a single-part, scanline EXR without deep data or extra parts
2. Flatten the file with a converter: `oiiotool deep.exr --flatten -o flat.exr` or `exrmultipart -combine`
3. Check the file with exrheader to see the version flags (deep/multipart/tiled)
4. Split multi-part files into separate single-part EXRs before loading

Example fix

// before: multipart deep EXR from Nuke
// after: flatten to a plain single-part scanline EXR
// oiiotool multipart.exr --flatten --compression zip -o simple.exr

// EXR byte 5 holds version flags; this loader only tolerates tiled (0x200 is *not* the flag here) —
// practically: reject deep/multipart files by checking flags beyond 0x04
const dv = new DataView(buf);
const flags = dv.getUint8(5);
if ((flags & ~0x04) !== 0) throw new Error("EXR uses unsupported version flags (deep/multipart?) — flatten it first");

function isSimpleExrVariant(buf: ArrayBuffer): boolean {
  if (buf.byteLength < 6) return false;
  const flags = new DataView(buf).getUint8(5);
  return (flags & ~0x04) === 0;
}

try {
  await loader.loadAsync(file);
} catch (e) {
  if (/Unsupported file format/.test(String(e))) {
    console.warn("Deep/multipart EXR detected — flattening");
    return loadFlattenedExr(url);
  }
  throw e;
}

When it happens

Trigger: Raised in GetExrHeader when (specData & ~0x04) != 0 — i.e. the EXR version field sets unsupported flags: deep/latent data files (flag 0x400/0x800 per OpenEXR spec bits beyond this parser's mask), or multipart (0x200) / deep (0x800) exports depending on the mask, while only single-part scanline/tiled simple files are supported.

Common situations: Deep compositing EXRs from Nuke/Houdini, multi-part EXRs combining beauty and AOV passes, or files written by newer OpenEXR libraries with extra version flags.

Related errors

• EXRLoader.parse: file contains unsupported data channels.
• Unsupported pixelType ${decoder.type} for ${header.compressi
• Error in HufUnpackEncTable
• Invalid table entry
• hufDecode issues

AI-assisted analysis of BabylonJS/Babylon.js@0592b347b8 (2026-08-30). Data as JSON: /api/errors/84171484cd009158. Report an issue: GitHub.