La livraison HDR chez Runway
Runway a ouvert le 20 août son API à la livraison en haute plage dynamique, avec un modèle dédié nommé Ruby qui convertit n'importe quelle vidéo SDR — importée ou générée par un autre moteur — en HDR10 dix bits, en HLG signalé BT.2020, en mezzanine ProRes ou en séquence OpenEXR demi-flottante. La conversion est présentée comme conservative : les pixels et l'audio de la source sont préservés, la luminance est étendue dans la réserve HDR par un étalonnage borné, et rien n'est recalculé. Le même jour, Gen-4.5 en texte-vers-vidéo et image-vers-vidéo a gagné des formats de sortie de post-production — masters douze bits sans perte, séquences PNG seize bits bit-exactes, EXR en lumière linéaire BT.2020 native pour les compositeurs — tandis qu'Aleph 2.0 se limite au SDR dix bits et doit être chaîné vers /v1/video_to_hdr pour sortir en HDR. Les entrées de Ruby sont plafonnées à quarante secondes et à 4096 pixels de côté, et les vidéos déjà taguées HDR sont refusées. La facturation suit la charge : vingt crédits par seconde, quarante au-delà de quatre mégapixels, et cinq crédits par seconde seulement pour le ProRes et les séquences PNG.
Le vocabulaire de cette mise à jour n'est pas celui d'un générateur de vidéo, c'est celui d'une salle d'étalonnage : mezzanine, BT.2020, PQ, EXR demi-flottant, métadonnées mesurées. Depuis trois ans, les moteurs génératifs livraient un MP4 huit bits et laissaient au monteur le soin d'inventer la suite. Une sortie EXR linéaire compositable change la nature de l'objet produit — il cesse d'être une image finie pour redevenir de la matière.
Reste que l'ordre des opérations mérite attention. Ruby étend un signal SDR vers le HDR sans rien re-rendre : ce n'est pas du HDR natif, c'est une extension bornée d'une plage déjà décidée. Le vrai HDR de la mise à jour est ailleurs, dans les rendus Gen-4.5 gradés directement en BT.2020. Confondre les deux revient à confondre une restauration et un tournage.