Guida Riducly
Metodologia benchmark di compressione Riducly
Il metodo riproducibile che Riducly userà per misurare riduzione del peso, fedeltà visiva e affidabilità prima di pubblicare affermazioni sulle prestazioni.
Perché il metodo viene prima di una percentuale
I risultati dipendono da formato sorgente, dimensioni, dettaglio fotografico, trasparenza, codifiche precedenti e impostazioni di uscita. Un solo file favorevole non sostiene un'affermazione generale. Riducly non pubblica quindi una percentuale fissa finché non esistono un corpus versionato e un'esecuzione ripetibile. Questa pagina definisce il protocollo in anticipo, affinché i risultati futuri possano essere contestati, riprodotti e confrontati senza cambiare le regole dopo aver visto l'esito. I rapporti devono mostrare distribuzioni e numerosità, separare compressione e conversione e includere fallimenti o output più grandi.
Corpus sorgente e requisiti di licenza
Il corpus deve contenere originali riutilizzabili legalmente e con provenienza documentata. Deve bilanciare fotografie, screenshot, illustrazioni, loghi, gradienti, grafica con testo, risorse trasparenti e dettagli ad alta frequenza difficili. Ogni categoria richiede più dimensioni e pesi, inclusi file già ottimizzati. Quasi-duplicati, miniature derivate e file già elaborati da Riducly devono essere identificati per non gonfiare il dataset. Il manifesto pubblicato includerà ID stabile, licenza o fonte, categoria, formato, dimensioni, byte e checksum crittografico. Caricamenti dei clienti e immagini private ricevute con il feedback non devono mai diventare input del benchmark.
Matrice di test e ambiente controllato
Ogni campione idoneo viene elaborato con la stessa versione rilasciata di Riducly e un runtime dichiarato. La matrice registra modalità, dimensione massima, formato di uscita, versione dell'encoder e percorso locale o server. I test nello stesso formato mantengono le dimensioni originali salvo esperimenti di ridimensionamento esplicitamente etichettati. Le conversioni sono riportate a parte perché capacità, trasparenza e metadati cambiano. Le esecuzioni usano profilo pulito e risorse fisse; i passaggi di riscaldamento vengono esclusi prima delle ripetizioni cronometrate. Il rapporto registra commit, versioni Node.js e browser, sistema operativo, architettura CPU, ripetizioni ed eventuale seed casuale.
Misure di peso e qualità
Per ogni output il sistema registra byte iniziali, byte finali e variazione percentuale con segno calcolata sui file esatti. La qualità usa pixel decodificati alle stesse dimensioni. Gli output lossless richiedono uguaglianza dei pixel dove la pipeline colore lo consente. I risultati fotografici lossy devono includere PSNR e almeno una metrica percettiva adatta, insieme a ritagli visivi per difetti come ringing, blocchi, banding e aloni. La fedeltà alpha viene misurata separatamente sulle immagini trasparenti. Il rapporto pubblica mediana, quartili, minimo, massimo, tasso di aumento e categorie di errore; la rimozione dei metadati è un comportamento, non una misura di qualità visiva.
Riproducibilità e artefatti dei risultati
Un rilascio valido include manifesto del corpus, matrice di configurazione, tabella machine-readable, codice di calcolo e comando esatto per ripetere l'analisi. Le immagini generate possono essere pubblicate soltanto se la licenza sorgente consente la redistribuzione; altrimenti il manifesto spiega come ottenere l'originale. I checksum collegano ogni riga a input e output esatti. I dati grezzi restano immutabili e i riepiloghi vengono generati da essi. Casi esclusi e motivazioni sono leggibili dalle macchine. La revisione visiva annota revisore, condizioni dello schermo e rubrica, evitando di presentare osservazioni soggettive come punteggi oggettivi. I rapporti precedenti restano archiviati quando cambiano codec o predefiniti.
Regole, limiti e stato attuale
Ogni riepilogo deve indicare versione e data di Riducly, descrivere il corpus e chiarire che altre immagini possono comportarsi diversamente. Un risultato sostiene soltanto affermazioni ristrette con statistica, popolazione e impostazioni visibili accanto. Il rapporto distingue risparmi dovuti a ridimensionamento, rimozione metadati, ricodifica e conversione. Dichiara inoltre che le metriche percettive sono imperfette, codec browser e server possono differire e la velocità su una macchina non garantisce la stessa prestazione altrove. Questa pagina pubblica oggi il metodo, non risultati completi. Finché corpus versionato, tabella grezza e comando riproducibile non saranno revisionati, i risparmi restano variabili e nessuna percentuale fissa è supportata.