Smart Image Encoder Benchmark & Quality Standards

Name: IMAGEEE Smart Encoder RGB Reference — JPEG, WebP, AVIF, and PNG (2026-07-30)
Creator: IMAGEEE

Last updated: July 31, 2026

1. Scope and purpose

This page defines how IMAGEEE evaluates output quality, user safety, and operational reliability across image and PDF workflows. The goal is not to maximize feature count alone, but to provide predictable results under practical constraints such as browser compatibility, source quality variance, and upload limits in downstream platforms.

2. Validation approach

Validation combines automated checks and human review. Automated checks enforce syntax consistency, route and metadata contracts, extension mapping integrity, timeout and error handling, and API hardening guardrails. Human review focuses on visual fidelity, metadata behavior, and workflow-specific correctness in representative cases such as HEIC camera files, compressed web images, scanned PDFs, and animation sources.

3. Quality acceptance criteria

A change is accepted when it improves or maintains output correctness for supported formats, does not regress privacy and deletion guarantees, and keeps operational error rates within expected bounds. If a change improves one format but degrades another, the tradeoff is documented and fallback guidance is provided in the corresponding guide pages.

Exact-reconstruction claims require stronger proof than a visually similar preview. The reversible JPEG to JXL route publishes an output only after reconstructing the original JPEG bytes and matching their SHA-256 digest; a failed proof is an error, not a lossy replacement.

4. Reproducible smart-encoder reference

On July 30, 2026, the checked-in benchmark generator created three deterministic 640×400 RGB fixtures and passed each fixture through the production image_ops.py smart JPEG, WebP, AVIF, and PNG encoder dispatcher. Every encoded result was decoded back to RGB before measurement. It ran in a pinned AWS Lambda Python 3.13 environment on Linux x86_64 (Python 3.13.14), with the exact production dependency pins including Pillow 12.1.0, pillow-avif-plugin 1.5.5, and NumPy 2.2.2. The base image was public.ecr.aws/lambda/python@sha256:db0a8819d1529a640fbf1ca59378e7fa0ba08f2660389f1c76790362abdac8e9; lambda/requirements.txt SHA-256 was e30c9a2e13dc5d3e3250068a62e7c5f1972a1a73376eb87556cb60377564642d; and image_ops.py SHA-256 was 2a1820c337ceb05b44b0332e4b66eaf9a1bba5f843d4d497f03c6c3e074b1d0b.

“Source PNG ratio” is encoded bytes divided by the deterministic source PNG bytes, so a value below 1 is smaller than that source file. RGB PSNR is calculated from mean squared error across all decoded RGB samples; an exact match has mathematically infinite PSNR. RGB MAE is the mean absolute channel error, where lower is closer to the source.

Fixture	Format	Bytes	Source PNG ratio	RGB PSNR	RGB MAE	Smart decision
Photo-like	JPEG	28,376	0.089015×	38.1823 dB	2.360632	`noisy_photo_guard`
Photo-like	WebP	15,500	0.048623×	37.7602 dB	2.545540	`noisy_photo_guard`
Photo-like	AVIF	36,315	0.113919×	40.1922 dB	1.828331	`noisy_photo_guard`
Photo-like	PNG	139,581	0.437863×	42.2724 dB	1.091312	`quantized_balanced`
Flat UI	JPEG	19,310	5.493599×	37.0150 dB	1.150984	`smooth_graphic_balance_webp_lossless_auto`
Flat UI	WebP	1,474	0.419346×	∞ (exact)	0.000000	`smooth_graphic_balance_webp_lossless_auto`
Flat UI	AVIF	2,417	0.687624×	36.9669 dB	0.914988	`smooth_graphic_balance_webp_lossless_auto`
Flat UI	PNG	2,562	0.728876×	∞ (exact)	0.000000	`quantized_balanced`
Line art	JPEG	60,810	8.917730×	46.8271 dB	0.392359	`line_art_text_guard_grayscale_webp_lossless_auto`
Line art	WebP	2,428	0.356064×	∞ (exact)	0.000000	`line_art_text_guard_grayscale_webp_lossless_auto`
Line art	AVIF	3,181	0.466491×	∞ (exact)	0.000000	`line_art_text_guard_grayscale_webp_lossless_auto`
Line art	PNG	4,016	0.588943×	∞ (exact)	0.000000	`quantized_balanced`

Download the bounded benchmark JSON and inspect the exact source fixtures: photo-like PNG, flat UI PNG, and line-art PNG.

Limitations: these synthetic fixtures cover one resolution and do not represent every camera, scan, illustration, or UI asset. PSNR and MAE do not measure subjective quality or compatibility. Byte counts can change with Pillow, codec, platform, or image_ops.py revisions. Runtime measurements are intentionally excluded. These results describe this fixed reference build; they are not a file-size, quality, or compression-ratio promise.

Metadata Cleanup Proof v1: synthetic container reference

The checked-in generator builds 16×12 synthetic JPEG, PNG, and WebP files with explicit metadata carriers, then removes those declared carriers without decoding or re-encoding the image payload. The checker parses the committed files, regenerates them byte for byte, validates every file SHA-256 digest, and requires the expected residual counts below to be zero.

JPEG: one EXIF APP1 segment, one XMP APP1 segment, and one comment segment become zero.
PNG: one eXIf chunk, one XMP iTXt chunk, and one comment tEXt chunk become zero.
WebP: one EXIF chunk and one XMP chunk become zero, and both corresponding VP8X metadata flags are cleared.

The inputs contain only conspicuously synthetic values and use no third-party source media. The recipe, source fixtures, scrubbed fixtures, and reference data are published under CC0-1.0: machine-readable reference JSON.

Inspect the paired files: JPEG source and JPEG scrubbed; PNG source and PNG scrubbed; WebP source and WebP scrubbed.

Scope limitation: this is a static, container-level reference, not a live IMAGEEE job result. It does not exercise upload, orientation correction, decoding, output encoding, or download, and it does not cover every metadata convention or malformed file. ICC color profiles, visible pixels, filenames, sidecars, and copies retained by another platform are outside this proof. Keep originals and independently inspect a representative downloaded result for critical work.

5. Privacy and safety baseline

IMAGEEE prioritizes short-term processing with automatic deletion. Metadata-sensitive workflows are expected to use EXIF cleanup and visual redaction where needed. Inputs that are corrupted, malformed, or outside supported constraints are rejected with explicit user-facing errors instead of partial silent output.

6. Incident and correction policy

Quality incidents are triaged by user impact: data integrity and privacy risks first, then workflow blocking defects, followed by non-blocking UX improvements. Corrections include code fixes, guardrail updates, and content updates. When policy, behavior, or reliability guidance changes materially, this page and related documentation are updated with a new date.

7. What users should do for critical jobs

For production-critical or regulated use, keep source originals, test representative samples first, verify results in the final destination environment, and store minimal run context (input type, options, timestamp, expected vs actual result). This practice reduces avoidable failures and accelerates incident resolution when edge-case files appear.

8. Related pages

For workflow-level recommendations see Guides and Workflow Checklists. For operator, legal, and privacy context see About, Contact, Terms, Privacy, Disclaimer, and Editorial Policy. For a worked integrity proof, see Reversible JPEG to JXL.

9. Who updates these standards

These standards are maintained by the IMAGEEE product and engineering team. Updates are triggered by measurable regressions, repeated support reports, workflow breakages in common environments, and policy changes that affect privacy or reliability. This page is intended to be operational documentation rather than a promotional page.

10. How updates are evaluated

Before release, candidate changes are reviewed against three checks: user impact reduction, regression risk to supported workflows, and operational maintainability. Changes that cannot pass all three checks are either revised or rolled back. When uncertainty remains, the safer behavior is chosen and documented with clear fallback guidance.

11. Review signals used before publishing major changes

High-visibility changes are checked against several practical signals: whether support reports become easier to reproduce, whether request IDs and structured errors remain actionable, whether privacy and deletion guarantees still match the published policy, and whether the page or tool remains useful without depending on ad placement. These are product review signals, not decorative documentation requirements.

12. Why this page exists

The purpose of this page is transparency. Users and reviewers should be able to identify how IMAGEEE defines quality, how incidents are handled, and how corrections are applied over time. This makes reliability claims testable against documented product behavior.