10-bit et 4:2:2 après conversion : tout dépend de la recompression de l’image
Mettons d’abord la phrase la plus importante : quand l’image n’a pas besoin d’être recompressée, le 10-bit et les informations HDR suivent tels quels ; quand elle doit être recompressée, la forme livrée suit la profondeur de bits de la source, jusqu’à 10-bit au plus, avec le chroma unifié en 4:2:0. Ce sont les deux voies, et CineX décide lui-même laquelle il suit ; le critère de ce choix est écrit dans pourquoi CineX est parfois rapide et parfois lent — qu’un même fichier doive être réencodé ou non dépend du codage de son image, pas de son extension.
1. Pourquoi rien ne change dans le cas « sans réencodage »
Les images HEVC 10-bit (HDR10 compris) et H.264 Hi10P que l’appareil sait déjà lire empruntent un « transport » et non une « recomposition » : aucun octet des données d’image n’est régénéré, donc la profondeur de couleur, l’échantillonnage chromatique et la plage de luminance restent inchangées. Ces fichiers se terminent souvent en quelques secondes, et cette rapidité vient précisément de l’absence de recompression.
Lorsque l’image n’a pas été recomposée, se demander « si la qualité d’image va baisser » n’a pas de sens : elle n’a pas été touchée.
2. Quand l’image doit être recompressée : livraison selon la profondeur de bits de la source, jusqu’à 10-bit au plus, chroma unifié en 4:2:0
Quand l’image doit être réencodée (source en VP9, AV1, Xvid ou tout autre codage d’image que l’appareil ne lit pas directement), la profondeur de bits ne baisse pas d’elle-même : une source en 10-bit — ou de type HDR avec une fonction de transfert PQ ou HLG — est livrée en 10-bit ; une source en 12-bit retombe à 10-bit ; le sous-échantillonnage chroma 4:2:2 comme 4:4:4 est unifié en 4:2:0, et la profondeur de bits est conservée. Deux cas seulement livrent du 8-bit : la source était déjà en 8-bit, ou le fichier ne permet pas de lire la profondeur de bits. Ce qui change, c’est la couche du sous-échantillonnage chroma : la précision des niveaux du 10-bit reste dans les pixels, l’échantillonnage des couleurs du 4:2:2 n’y reste pas.
Pourquoi unifier le chroma en 4:2:0 et ne pas livrer plus que 10-bit pour du 12-bit : c’est notre propre ligne de livraison — le résultat ne prend que la forme couverte par les preuves déjà validées (HEVC Main 10, 4:2:0), sans parier sur une forme plus large. C’est un arbitrage, pas un oubli, et aucun réglage ne peut le contredire — CineX est à zéro paramètre : il ne propose aucun palier de qualité.
3. HDR et Dolby Vision : un sort différent dans ce cas
Gardons ici une seule conclusion qui touche directement la profondeur de bits : la voie du réencodage livre selon la profondeur de bits de la source, jusqu’à 10-bit au plus. Ce qui relève de Dolby Vision, nous n’avons dit que cela suit l’image que sur la voie du changement de conteneur seul ; ce qui en reste après réencodage, nous ne l’avons pas vérifié, et nous n’en faisons une promesse ni pour l’un ni pour l’autre. Les étiquettes de couleur (fonction de transfert, gamme de couleurs et consorts) suivent la source : présentes, elles passent ; absentes, nous n’en ajoutons pas. « L’étiquette est là » et « l’effet est là » sont deux choses différentes — c’est aussi la raison pour laquelle Dolby Vision et HDR10 doivent être discutés séparément.
4. Le 10-bit ne rime pas forcément avec lenteur, mais un cas demande du temps
Le H.264 en 10-bit (Hi10P) comme le HEVC en 10-bit font partie des entrées déjà validées sur des échantillons lus sur appareil réel. Ce qui demande de prévoir du temps, ce sont les cas extrêmes : une image à fréquence d’images élevée et à haute résolution qui passe par une conversion complète — l’attente se calcule d’après la longueur du média et dépasse souvent cette longueur. Pour ces fichiers « qu’on ne peut pas attendre », vérifier d’abord s’ils ont vraiment besoin d’une recompression est plus efficace que changer d’outil.
Ce qui ralentit n’a jamais été le chiffre « 10-bit », mais la question de savoir si l’image doit être redessinée. Pour les fichiers qui n’ont pas à l’être, la profondeur de bits est conservée selon la source ; pour ceux qui doivent l’être, la sortie est une image 4:2:0 dont la profondeur suit la source, jusqu’à 10-bit au plus — c’est pour les seconds qu’il faut prévoir du temps.
5. Limites à connaître à l’avance
- Cet article énonce les règles propres à chacune des trois voies. Le comportement du 10-bit et du HDR dans la catégorie « sans réencodage » s’appuie sur des échantillons vérifiés sur appareil réel ; le 12-bit et le 4:2:2 ont chacun une lecture relevée sur appareil réel (le 12-bit retombe à 10-bit, le chroma du 4:2:2 retombe à 4:2:0 tandis que la profondeur de bits est conservée). La régression point par point de cette branche sur iOS n’est pas encore établie ⇒ le 10-bit n’y est présenté que comme une forme de livraison, jamais en argument de vente ; quiconque en fait une exigence stricte doit d’abord vérifier avec ses propres fichiers.
- Recompresser une image la modifie : nous ne le nions pas, et nous ne proposons aucune option « garder le fichier tel quel ».
- La profondeur de bits et les couleurs ne sont pas des signaux d’« échec de conversion » : le fichier produit se lit normalement, et le sous-échantillonnage chroma ramené à 4:2:0 est la règle de cette voie, pas une panne.
- Une conversion complète exige aussi de laisser suffisamment d’espace disponible (le pic d’occupation du disque ne dépasse pas deux fois le fichier d’origine ; quand seul le conteneur change, un espace équivalent à un fichier converti suffit), et la raison est écrite dans pourquoi la conversion vidéo demande de prévoir de l’espace en plus.
Questions fréquentes
Mon film HEVC 10-bit sera-t-il dégradé en 8-bit ?
Non. Quand l’appareil lit directement cette image, CineX change seulement le conteneur, les pixels ne bougent pas, et le 10-bit est conservé tel quel ; quand un réencodage est nécessaire, la profondeur de bits ne baisse pas non plus — une source en 10-bit est livrée en 10-bit. Le résultat n’est en 8-bit que si la source l’était déjà, ou si le fichier ne permet pas de lire la profondeur de bits.
Le repère HDR est encore là après conversion, pourquoi l’image paraît-elle grise ?
Un rendu délavé vient le plus souvent de la façon dont le côté affichage traite les informations de luminance de type HDR, pas d’un résultat abîmé. La voie du réencodage livre uniformément du 4:2:0, et les étiquettes de couleur suivent la source ; « l’étiquette est là » ne veut pas dire « l’effet est là ». La bonne attitude, c’est de garder le fichier d’origine pour les voies qui le prennent en charge.
Existe-t-il un moyen de conserver une sortie en 10-bit ?
Rien à régler, et rien à régler non plus : au réencodage, la profondeur de bits est livrée selon la source — une source en 10-bit est livrée en 10-bit, et une source en 8-bit ne devient pas du 10-bit parce qu’on le souhaite. CineX est à zéro paramètre : ni palier de qualité, ni choix de profondeur de bits, ni volume cible.
Une conversion de 10-bit est-elle forcément lente ?
Pas forcément. Les seuls fichiers lents sont ceux qui doivent être recompressés et dont la fréquence d’images comme la résolution sont élevées ; beaucoup de fichiers 10-bit empruntent une voie sans réencodage et en sont finis en quelques secondes.
Axiom One LLC — CineX