What causes "RGB image dimensions overflow: {width}x{height}" in run-llama/liteparse?

Validate/sane-check width and height (e.g. cap at a few tens of millions of pixels) before calling the OCR API.

run-llama/liteparse · error · std::io::Error

RGB image dimensions overflow

Error message

RGB image dimensions overflow: {width}x{height}

What it means

rgb_image computes the expected buffer size as width * height * 3 using checked arithmetic. If either multiplication would overflow usize, the declared dimensions cannot correspond to any real buffer, so the call is rejected with this InvalidInput error. This prevents overflow-based miscalculation of buffer lengths downstream.

Solutions

Validate/sane-check width and height (e.g. cap at a few tens of millions of pixels) before calling the OCR API.
Fix the upstream source that reports the oversized dimensions.
If huge images are legitimate, process them in tiles rather than passing full dimensions.

Example fix

// before: unchecked dimensions from external source
let (w, h) = header.dimensions();
ocr.recognize_sync(&buf, w, h)?;

// after: bounds check first
const MAX_DIM: u32 = 100_000_000;
if w > MAX_DIM || h > MAX_DIM {
    return Err(anyhow!("unreasonable image dimensions: {w}x{h}"));
}
ocr.recognize_sync(&buf, w, h)?;

Defensive patterns

Strategy: validation

Validate before calling

// Rust: sane upper bound on image dimensions
const MAX_DIM: u32 = 100_000_000;
fn dims_in_range(w: u32, h: u32) -> bool {
    w > 0 && w <= MAX_DIM && h > 0 && h <= MAX_DIM
}

Prevention

Bounds-check externally sourced width/height before use
Never trust image metadata from untrusted producers
Tile very large images instead of passing full dimensions

When it happens

Trigger: Calling the OCR recognize path with width/height values so large that width*height*3 exceeds the platform's usize maximum (practically, absurd dimensions like > ~1.7e15 pixels on 64-bit).

Common situations: Corrupt image metadata or a malicious/buggy OCR server reporting fantastical dimensions; integer-typed width/height read from an untrusted header without bounds checking.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors

AI-assisted analysis of run-llama/liteparse@22d2dd8cd7 (2026-09-08). Data as JSON: /api/errors/a1e4e3119caea83c. Report an issue: GitHub.

Appendix: source

Thrown at crates/liteparse/src/ocr/oar.rs:270

        eprintln!(
            "[oar-ocr] ignoring OcrOptions::language ({language:?}); recognition language is fixed by the model and character dictionary"
        );
    });
}

fn rgb_image(image_data: &[u8], width: u32, height: u32) -> Result<image::RgbImage, io::Error> {
    if width == 0 || height == 0 {
        return Err(io::Error::new(
            io::ErrorKind::InvalidInput,
            format!("invalid zero-sized RGB image: {width}x{height}"),
        ));
    }

    let expected_len = (width as usize)
        .checked_mul(height as usize)
        .and_then(|pixels| pixels.checked_mul(3))
        .ok_or_else(|| {
            io::Error::new(
                io::ErrorKind::InvalidInput,
                format!("RGB image dimensions overflow: {width}x{height}"),
            )
        })?;

    if image_data.len() != expected_len {
        return Err(io::Error::new(
            io::ErrorKind::InvalidInput,
            format!(
                "invalid RGB buffer length for {width}x{height}: expected {expected_len} bytes, got {}",
                image_data.len()
            ),
        ));
    }

    image::RgbImage::from_raw(width, height, image_data.to_vec()).ok_or_else(|| {
        io::Error::new(
            io::ErrorKind::InvalidInput,

View on GitHub (pinned to 22d2dd8cd7)