existe-t-il des encodeurs/décodeurs qui peuvent travailler avec un nombre de bits quelconque (ou à défaut de vraiment quelconque qui peuvent manger du 64 bits par composante) ?
La spec est "illimitée" la dessus mais en pratique passé 10 bit c'est pas très optimisé au niveau du "prefect" (il se base sur un int de 32 bits divisé par 3 domaines donc 10 bits pratiques, à l'époque des débuts de FFV1 les machines 64 bits n'étaient pas partout) car... En pratique passé 10 bit d'un capteur, c'est pas mal du bruit random... On pourrait changer la chose si il y a un intérêt.
Pour le logiciel, les seuls connus s'arrêtent à 31 (RGB) ou 32 (YUV) bits mais pourraient se prendre un +32 facilement (pour mon logiciel c'est un typedef uint32_t qui passe en uint64_t) et si il faut il y a des libs pour du 128 bits ou pas. Pas implémenté mais ne fait pas peur à part sur l'espoir de compresser tant que ça du fait que la réalité montre des capteurs qui ne mesurent pas tant que ça.
A noter que (tient, un exemple sur le ouvert vs libre) j'ai un fork (pas accepté tel quel dans le standard) de FFV1 qui supporte des float à la place de int, car pour la vidéo du moins on considère que plutôt que d'avoir des int de 64 bits on fait des floats de 16 ou 32 bits (pas moi qui le dit, hein, demander à ILM qui a créé EXR et utilise pas mal les floats), la plage de précision suffit (on s'en fout un peu du nanomètre quand on mesure un truc dans le parsec).
est-il possible (voire facile) d’encoder/décoder des données qui ont (parfois beaucoup) plus que trois composantes ?
Actuellement c'est max 4 (canal alpha).
Le standard limite à 4, mais la prochaine version pourrait avoir illimité. On est intéressés pour la v4, c'est surtout se mettre d'accord sur comment annoncer le nombre, rien de compliqué mais actuellement surtout un manque de motivation faute de sponsor intéressé.
Globalement, ce dont tu parles n'est pas la mais pas difficile à implémenter pour la v4 (ou en fork si refusé par le standard), on est clairement ouverts à ce type d'usage, si tu penses que ça peut valoir le coup pour une entité, faut qu'on parle ;-).
Globalement, l'algo est assez générique et peut s'adapter facilement, reste à trouver des cas d'usage qui rendent viable le dev.
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. Évalué à 10.
La spec est "illimitée" la dessus mais en pratique passé 10 bit c'est pas très optimisé au niveau du "prefect" (il se base sur un int de 32 bits divisé par 3 domaines donc 10 bits pratiques, à l'époque des débuts de FFV1 les machines 64 bits n'étaient pas partout) car... En pratique passé 10 bit d'un capteur, c'est pas mal du bruit random... On pourrait changer la chose si il y a un intérêt.
Pour le logiciel, les seuls connus s'arrêtent à 31 (RGB) ou 32 (YUV) bits mais pourraient se prendre un +32 facilement (pour mon logiciel c'est un typedef uint32_t qui passe en uint64_t) et si il faut il y a des libs pour du 128 bits ou pas. Pas implémenté mais ne fait pas peur à part sur l'espoir de compresser tant que ça du fait que la réalité montre des capteurs qui ne mesurent pas tant que ça.
A noter que (tient, un exemple sur le ouvert vs libre) j'ai un fork (pas accepté tel quel dans le standard) de FFV1 qui supporte des float à la place de int, car pour la vidéo du moins on considère que plutôt que d'avoir des int de 64 bits on fait des floats de 16 ou 32 bits (pas moi qui le dit, hein, demander à ILM qui a créé EXR et utilise pas mal les floats), la plage de précision suffit (on s'en fout un peu du nanomètre quand on mesure un truc dans le parsec).
Actuellement c'est max 4 (canal alpha).
Le standard limite à 4, mais la prochaine version pourrait avoir illimité. On est intéressés pour la v4, c'est surtout se mettre d'accord sur comment annoncer le nombre, rien de compliqué mais actuellement surtout un manque de motivation faute de sponsor intéressé.
Globalement, ce dont tu parles n'est pas la mais pas difficile à implémenter pour la v4 (ou en fork si refusé par le standard), on est clairement ouverts à ce type d'usage, si tu penses que ça peut valoir le coup pour une entité, faut qu'on parle ;-).
Globalement, l'algo est assez générique et peut s'adapter facilement, reste à trouver des cas d'usage qui rendent viable le dev.