Calculateur PAR

Ce calculateur accepte le ratio d'aspect d'affichage comme deux parties positives ainsi que la largeur et la hauteur en pixels de la trame codée, puis renvoie PAR = (display aspect × height) / width, la fraction PAR réduite, les ratios de stockage et d'affichage correspondants, et un indicateur de pixel carré. Toute dimension nulle ou négative échoue avec invalid_input plutôt qu'un rapport absurde.

Ce qu'est le ratio d'aspect pixel et en quoi il diffère du ratio d'affichage

MPEG-4 écrit la même identité PAR = (DAR × height) / width. Cette page répond à la recherche « calculateur de ratio d'aspect pixel », non à celle d'un réducteur générique qui ne simplifie width:height que par le PGCD.

Formule, contrat d'entrée et sort lorsqu'une dimension est invalide

Les chaînes de chiffres qui s'analysent en nombres finis sont admises afin qu'une valeur collée depuis une sonde n'exige pas une seconde conversion. Les entrées à valeur entière dans la plage des entiers sûrs sont réduites par l'algorithme d'Euclide, si bien que 1920×1080 en 16:9 renvoie PAR 1:1 et 720×480 en 4:3 renvoie PAR 8:9. Les dimensions nulles ou négatives échouent avec un message indiquant que toute dimension de pixel et d'aspect d'affichage doit être strictement positive ; ces échecs ne sont pas facturés. Si vous avez besoin de la table analogique active ITU-R BT.601 qui cite 10:11 pour le NTSC 4:3, passez 704 comme width au lieu de 720 — l'identité s'applique toujours au raster que vous fournissez, jamais à une hypothèse cachée de 704 échantillons. Envoyez quatre nombres finis obligatoires : width et height de la trame codée en pixels, et dar_width plus dar_height pour le ratio d'aspect d'affichage (le 16 et le 9 de 16:9). Les alias pixel_width, storage_width et w sont acceptés pour width ; pixel_height, storage_height et h pour height ; display_width, dar_w et aspect_w pour dar_width ; display_height, dar_h et aspect_h pour dar_height. Le moteur calcule l'aspect de stockage comme width / height, l'aspect d'affichage comme dar_width / dar_height, et l'aspect pixel comme aspect d'affichage / aspect de stockage, ce qui équivaut à (dar_width × height) / (dar_height × width). Champs manquants, chaînes vides, texte non numérique, NaN, Infinity et magnitudes au-delà d'un billion échouent avec invalid_input en nommant le champ. En succès, le JSON répète les quatre entrées, signale pixel_aspect_ratio comme nombre stable à douze décimales, signale par_width, par_height et la chaîne par, signale storage_aspect_ratio avec storage_aspect, signale display_aspect_ratio avec display_aspect, active square_pixels lorsque le PAR vaut 1, et rappelle la formule. Exemple : width 1920, height 1080, dar_width 16, dar_height 9 donne PAR 1:1 et square_pixels true. Exemple : width 720, height 480, dar_width 4, dar_height 3 donne PAR 8:9 ≈ 0.888888888889. Le tarif d'un élément réussi est un $0.002 forfaitaire.

Où une API de ratio d'aspect pixel gagne sa place

Les fermes de transcodage qui ingèrent des lots HD et SD mélangés peuvent appeler le même contrat pour chaque fichier : si square_pixels vaut true, elles sautent la voie anamorphique ; sinon, elles mettent à l'échelle par par_width:par_height avant un mezzanine à pixels carrés. Comme l'implémentation est du parse pur de niveau A, des entrées identiques produisent toujours le même JSON : pas de requête réseau, pas d'arrondi aléatoire, pas d'horloge dans le résultat, ce qui rend la capacité sûre pour les tests unitaires et les oracles de CI. L'usage de l'API prélève le solde prépayé KIT au $0.002 publié par requête réussie ; une entrée invalide n'est pas facturée.