What causes "formato sem limpeza sem perda aqui — só JPEG, PNG e WebP" in tonhowtf/omniget?

Check the file's real format (magic bytes) before calling and only pass JPEG/PNG/WebP

formato sem limpeza sem perda aqui — só JPEG, PNG e WebP

Error message

formato sem limpeza sem perda aqui — só JPEG, PNG e WebP

What it means

Format whitelist in strip_bytes: the input bytes were sniffed, but only JPEG, PNG and WebP have lossless metadata-strip implementations; any other image kind (or undetectable data) reaches this guard and is refused rather than risk corrupt output.

Solutions

Check the file's real format (magic bytes) before calling and only pass JPEG/PNG/WebP
Convert unsupported formats to one of the supported ones first (e.g. via ffmpeg/ImageMagick)
Show a user-facing message listing supported formats instead of surfacing the raw error

Example fix

// before
let out = exif::strip_bytes(&bytes)?;
// after
let out = match exif::strip_bytes(&bytes) {
    Ok(o) => o,
    Err(_) => return Err(anyhow!("arquivo nao suportado: use JPEG, PNG ou WebP")),
};

Defensive patterns

Strategy: validation

Validate before calling

// rust
fn is_supported_image(data: &[u8]) -> bool {
    data.starts_with(&[0xFF, 0xD8])            // JPEG
        || data.starts_with(&[0x89, b'P', b'N', b'G']) // PNG
        || (data.len() > 12 && &data[0..4] == b"RIFF" && &data[8..12] == b"WEBP") // WebP
}

Try / catch

match exif::strip_bytes(&bytes) {
    Ok(clean) => clean,
    Err(e) => return Err(anyhow!("formato nao suportado (use JPEG/PNG/WebP): {e}")),
}

Prevention

Detect format by magic bytes, never by file extension
Filter or convert unsupported formats before batch EXIF removal
Handle 0-byte and HTML error-page bodies from failed downloads

When it happens

Trigger: Calling strip_bytes with bytes whose leading magic is not FFD8 (JPEG), 89 50 4E 47 (PNG) or RIFF....WEBP — e.g. GIF, BMP, TIFF, HEIC, SVG, or an empty/garbage buffer.

Common situations: User drops an unsupported image type into a bulk EXIF-removal feature; file has wrong extension but is detected by content; input is actually HTML or a 0-byte file from a failed download.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of tonhowtf/omniget@8600b91f42 (2026-09-12). Data as JSON: /api/errors/177fa2945a781dbc. Report an issue: GitHub.

Appendix: source

Thrown at src-tauri/omniget-core/src/core/tools/exif.rs:294

            if &fourcc == b"VP8X" && body.len() > start + 8 {
                body[start + 8] &= !(0x08 | 0x04);
            }
        }
        i = end;
    }
    let mut out = Vec::with_capacity(body.len() + 8);
    out.extend_from_slice(b"RIFF");
    out.extend_from_slice(&(body.len() as u32).to_le_bytes());
    out.extend_from_slice(&body);
    Ok(out)
}

pub fn strip_bytes(data: &[u8]) -> anyhow::Result<Vec<u8>> {
    match kind_of(data) {
        Some(Kind::Jpeg) => strip_jpeg(data),
        Some(Kind::Png) => strip_png(data),
        Some(Kind::Webp) => strip_webp(data),
        None => Err(anyhow!(
            "formato sem limpeza sem perda aqui — só JPEG, PNG e WebP"
        )),
    }
}

#[derive(Debug, Clone, Deserialize)]
pub struct StripOptions {
    pub inputs: Vec<String>,
    /// Sobrescreve o arquivo original em vez de criar uma cópia limpa.
    #[serde(default)]
    pub in_place: bool,
    #[serde(default)]
    pub output_dir: String,
    #[serde(default)]
    pub suffix: String,
}

#[derive(Debug, Clone, Serialize)]

View on GitHub (pinned to 8600b91f42)