Riducly guide
Riducly image compression benchmark methodology
The reproducible method Riducly will use to measure file-size reduction, visual fidelity and processing reliability before publishing performance claims.
Why a published method comes before a percentage claim
Compression results depend on source format, dimensions, photographic detail, transparency, previous encoding and selected output settings. A single best-case file cannot support a general saving claim. Riducly therefore does not publish a fixed reduction percentage until a versioned corpus and repeatable test run are available. This page defines the protocol in advance so future results can be challenged, reproduced and compared without changing the rules after seeing the outcome. Reports must show distributions and sample counts, separate same-format compression from conversion, and keep failed or enlarged outputs visible rather than silently excluding them.
Source corpus and licensing requirements
The corpus must contain lawfully reusable originals with documented provenance. It should balance photographs, screenshots, illustrations, logos, gradients, text-heavy graphics, transparent assets and difficult high-frequency detail. Each category needs multiple dimensions and file sizes, including already optimized files. Near-duplicates, thumbnails derived from another sample and files previously processed by Riducly must be identified so they do not inflate the dataset. The published manifest will include a stable sample ID, license or source, category, format, dimensions, bytes and cryptographic checksum. Customer uploads and private feedback images must never become benchmark inputs.
Test matrix and controlled environment
Every eligible sample is processed with the same released Riducly version and a declared runtime. The matrix records compression mode, maximum dimension, output format, encoder version and whether execution was local or server-side. Same-format tests retain original dimensions unless a resize experiment is explicitly labeled. Conversion tests are reported separately because format capability, transparency and metadata rules differ. Runs use a clean profile and fixed machine or container resources; warm-up runs are discarded before timed repetitions begin. Reports record the application commit, Node.js and browser versions, operating system, CPU architecture, repetitions and any random seed.
File-size and quality measurements
For each output, the harness records input bytes, output bytes and the signed percentage change calculated from those exact files. Quality evaluation uses decoded pixels at equal dimensions. Lossless outputs require pixel equality where the color pipeline permits it. Lossy photographic results should include PSNR and at least one suitable perceptual metric, accompanied by visual crops for failure patterns such as ringing, blocking, banding and edge halos. Alpha-channel fidelity is measured separately for transparent assets. Reports publish median, quartiles, minimum, maximum, enlargement rate and failure categories; metadata removal is described as behavior, not counted as visual compression quality.
Reproducibility and result artifacts
A valid benchmark release includes the corpus manifest, configuration matrix, machine-readable result table, calculation code and exact command needed to rerun the analysis. Generated images may be published only when their source licenses allow redistribution; otherwise the manifest explains how another reviewer can obtain the original. Checksums connect every result row to the exact input and output. Raw results remain immutable while summaries are generated from them. Excluded cases and exclusion reasons are machine-readable. Manual visual review records the reviewer, display conditions and rubric so subjective observations are not presented as objective scores. Previous reports remain archived when codecs or defaults change.
Reporting rules, limitations and current status
Published summaries must name the tested Riducly version and date, describe corpus composition and state that other images may behave differently. Results may support only a narrowly worded claim whose statistic, population and settings appear beside it. The report distinguishes savings caused by resizing, metadata removal, same-format re-encoding and conversion. It also discloses that perceptual metrics are imperfect, browser and server codecs can differ, and speed on one machine does not guarantee speed elsewhere. This page currently publishes the method, not completed results. Until a versioned corpus, raw table and reproducible command are independently reviewed, savings remain variable and no fixed percentage claim is supported.