Impact de la compression sur le temps de rendu
Posté par Bibi09 le 25/7/2021 9:57:17
Bonjour à toutes et à tous,
Je travaille sur une animatique simple, rendue avec le workbench de Blender, et dont les temps de calculs sont très rapides.
Je n'avais jamais pensé à un élément rentrant pourtant dans l'équation du temps de calcul d'une animation : la compression des images rendues.
Comme chacun le sait, nos disques durs n'ont pas un espace de stockage infini. Or, pour une animation, outre les meshs, textures et autres assets pouvant occuper un espace non négligeable, les résultats des rendus en occupent probablement une plus grande partie encore suivant la durée du projet. On doit alors peser sur la balance l'espace occupé par les rendus et leur qualité visuelle.
D'ordinaire, et probablement comme un certain nombre d'entre vous, je privilégie les images PNG pour mes rendus car leur méthode de compression est dite sans perte. Le processus de compression est réversible, autrement dit, la compression n'endommage pas l'image. A contrario, le JPEG est un algorithme de compression avec perte, donc non réversible. On a des défauts visuels qui apparaissent surtout si on compresse trop l'image. Pire encore, plus on ré-enregistre un fichier JPEG, plus sa qualité se dégrade. On peut penser à une séquence d'images JPEG qu'on va ensuite compresser en MPEG-4 pour rendre son animation finale puis uploader sur YouTube qui va réencoder la vidéo... En tout, on a 3 compressions successives qui dégradent chacune un peu plus les images.
La compression nous permet cependant de préserver de l'espace disque pour un même fichier.
En revanche, il faut prendre un autre point en compte : la vitesse à laquelle un fichier est compressé.
L'algorithme de compression JPEG est plutôt rapide.
L'algorithme de compression PNG, le même que pour les fichiers ZIP, est plus lent. Mais à quel point ? Quel impact a-t-il sur le temps de rendu ?
J'ai fait un test de rendu sur 100 frames en WQHD (2560x1440), où les images sont calculées en environ 0.2s. J'ai donc ainsi une bonne visibilité du temps pris pour écrire le fichier sur le disque.
J'ai utilisé une qualité de 100% pour les JPEG pour limiter au maximum les défauts visuels et m'approcher au plus de celle d'un PNG. Quant au PNG, j'ai limité la compression à 5% dans un premier temps. Cependant, le niveau de compression étant très faible, le poids des images était plus que conséquent et donc non viable pour une animation complète. J'ai donc ensuite choisi le taux de compression minimal pour m'approcher du poids d'un rendu de 100 images avoisinnant celui en JPEG.
Afin de limiter au maximum les biais, j'ai écrit les fichiers sur un RAMDisk, c'est-à-dire un espace de stockage dans la RAM de l'ordinateur. L'avantage ici est de limiter au maximum le temps en écriture sur le disque*, la RAM étant toujours bien plus rapide que le meilleur SSD actuel.
J'ai sélectionné les mêmes instants de départ (lancement du rendu) et de fin (arrivée à la frame 100) pour chaque résultat.
Voici les résultats. Le format BMP, qui ne compresse rien ici, sera la valeur étalon.
On voit donc qu'en PNG, si on veut prioriser la rapidité de compression, il faut en payer un prix conséquent en espace disque. De l'autre côté, en optimisant l'espace disque, la compression prend un temps non négligeable sur le temps de calcul total de l'animation. De son côté, malgré les défauts qu'il peut apporter aux rendus, le JPEG constitue un très bon compromis entre rapidité, qualité et taille des fichiers.
Le JPEG2000, légèrement plus lent, est lui aussi recommandable grâce à sa capacité impressionnante à compresser. On pourra le privilégier pour des rendus en format 4K ou supérieurs... à condition de pouvoir l'ouvrir dans son logiciel de montage favori, ce qui est loin d'être généralisé. Blender en est capable bien entendu !
Pour conclure, le temps de compression peut avoir un impact plus ou moins important sur le temps de rendu des images. Avec EEVEE et les calculs très rapides, l'impact sera évidemment plus important. Si le temps de calcul d'une frame est plus long, comme avec Cycles, alors le surplus de temps consacré à la compression de l'image sera plus négligeable. Il faut donc veiller à optimiser non seulement le rendu mais aussi le moyen d'enregistrement des fichiers suivant la situation.
Enfin, il faut aussi noter que la compression est opérée par le processeur et donc intimement liée à ses performances. L'impact du disque utilisé est quant à lui peu voire pas du tout visible pour de petits fichiers (le RAMDisk utilisé ici n'accélère aucunement l'écriture des fichiers mais évite d'éventuels aléas).
Voilou.
* Le temps d'écriture sur le disque pourra dépendre de la saturation du cache du disque. Le cache est une mémoire très rapide temporaire pour accélérer les transferts de données. lle est souvent comprise en 64 et 256Mo pour les disques durs grand public, voire un ou plusieurs gigaoctets pour les SSD.
Le disque s'occupe ensuite de copier le contenu du cache sur son espace permanent quand il n'est plus sollicité. Sous Linux, on peut forcer cette écriture avec la commande `sync` (recommandée par exemple avant de retirer une clé USB). Après avoir copié un gros fichier, vous pouvez voir le temps que prend cette opération parfois assez longue ! Pour les gros volumes de données, ce cache pourrait ne pas suffire en taille et donc entraîner un goulot d'étranglement le temps que le disque évacue le trop plein de données du cache vers sa mémoire permanente, pour pouvoir réceptionner les données qui continuent d'arriver.
Un RAMDisk n'a pas besoin de cache puisque le processeur est en ligne directe avec la mémoire RAM. Et petit bonus, le RAMDisk est très pratique pour écrire de nombreuses choses sans détériorer un SSD. Par contre la RAM coûte assez cher donc on peut pas en avoir des tonnes.
Voilà la différence entre mon SSD NVMe (PCI-E 3.0) et un RAMDisk (mémoire DDR4 3200MHz dual-channel). Il n'y a pas photo !
Je travaille sur une animatique simple, rendue avec le workbench de Blender, et dont les temps de calculs sont très rapides.
Je n'avais jamais pensé à un élément rentrant pourtant dans l'équation du temps de calcul d'une animation : la compression des images rendues.
Comme chacun le sait, nos disques durs n'ont pas un espace de stockage infini. Or, pour une animation, outre les meshs, textures et autres assets pouvant occuper un espace non négligeable, les résultats des rendus en occupent probablement une plus grande partie encore suivant la durée du projet. On doit alors peser sur la balance l'espace occupé par les rendus et leur qualité visuelle.
D'ordinaire, et probablement comme un certain nombre d'entre vous, je privilégie les images PNG pour mes rendus car leur méthode de compression est dite sans perte. Le processus de compression est réversible, autrement dit, la compression n'endommage pas l'image. A contrario, le JPEG est un algorithme de compression avec perte, donc non réversible. On a des défauts visuels qui apparaissent surtout si on compresse trop l'image. Pire encore, plus on ré-enregistre un fichier JPEG, plus sa qualité se dégrade. On peut penser à une séquence d'images JPEG qu'on va ensuite compresser en MPEG-4 pour rendre son animation finale puis uploader sur YouTube qui va réencoder la vidéo... En tout, on a 3 compressions successives qui dégradent chacune un peu plus les images.
La compression nous permet cependant de préserver de l'espace disque pour un même fichier.
En revanche, il faut prendre un autre point en compte : la vitesse à laquelle un fichier est compressé.
L'algorithme de compression JPEG est plutôt rapide.
L'algorithme de compression PNG, le même que pour les fichiers ZIP, est plus lent. Mais à quel point ? Quel impact a-t-il sur le temps de rendu ?
J'ai fait un test de rendu sur 100 frames en WQHD (2560x1440), où les images sont calculées en environ 0.2s. J'ai donc ainsi une bonne visibilité du temps pris pour écrire le fichier sur le disque.
J'ai utilisé une qualité de 100% pour les JPEG pour limiter au maximum les défauts visuels et m'approcher au plus de celle d'un PNG. Quant au PNG, j'ai limité la compression à 5% dans un premier temps. Cependant, le niveau de compression étant très faible, le poids des images était plus que conséquent et donc non viable pour une animation complète. J'ai donc ensuite choisi le taux de compression minimal pour m'approcher du poids d'un rendu de 100 images avoisinnant celui en JPEG.
Afin de limiter au maximum les biais, j'ai écrit les fichiers sur un RAMDisk, c'est-à-dire un espace de stockage dans la RAM de l'ordinateur. L'avantage ici est de limiter au maximum le temps en écriture sur le disque*, la RAM étant toujours bien plus rapide que le meilleur SSD actuel.
J'ai sélectionné les mêmes instants de départ (lancement du rendu) et de fin (arrivée à la frame 100) pour chaque résultat.
Voici les résultats. Le format BMP, qui ne compresse rien ici, sera la valeur étalon.
BMP (sans compression): 1.02 Go (100%), 39.05s (100%)
JPEG qualité 100% : 79.6 Mo (7.8%), 37.20s (95.2%)
JPEG2000 qualité 100% : 2.99 Mo (0.3%), 42.14s (107.9%)
PNG compression 5%: 1,03 Go (101%), 35.11s (89.9%)
PNG compression 67%: 94.7 Mo (9.3%), 79,09s (202,5%)
On voit donc qu'en PNG, si on veut prioriser la rapidité de compression, il faut en payer un prix conséquent en espace disque. De l'autre côté, en optimisant l'espace disque, la compression prend un temps non négligeable sur le temps de calcul total de l'animation. De son côté, malgré les défauts qu'il peut apporter aux rendus, le JPEG constitue un très bon compromis entre rapidité, qualité et taille des fichiers.
Le JPEG2000, légèrement plus lent, est lui aussi recommandable grâce à sa capacité impressionnante à compresser. On pourra le privilégier pour des rendus en format 4K ou supérieurs... à condition de pouvoir l'ouvrir dans son logiciel de montage favori, ce qui est loin d'être généralisé. Blender en est capable bien entendu !
Pour conclure, le temps de compression peut avoir un impact plus ou moins important sur le temps de rendu des images. Avec EEVEE et les calculs très rapides, l'impact sera évidemment plus important. Si le temps de calcul d'une frame est plus long, comme avec Cycles, alors le surplus de temps consacré à la compression de l'image sera plus négligeable. Il faut donc veiller à optimiser non seulement le rendu mais aussi le moyen d'enregistrement des fichiers suivant la situation.
Enfin, il faut aussi noter que la compression est opérée par le processeur et donc intimement liée à ses performances. L'impact du disque utilisé est quant à lui peu voire pas du tout visible pour de petits fichiers (le RAMDisk utilisé ici n'accélère aucunement l'écriture des fichiers mais évite d'éventuels aléas).
Voilou.
* Le temps d'écriture sur le disque pourra dépendre de la saturation du cache du disque. Le cache est une mémoire très rapide temporaire pour accélérer les transferts de données. lle est souvent comprise en 64 et 256Mo pour les disques durs grand public, voire un ou plusieurs gigaoctets pour les SSD.
Le disque s'occupe ensuite de copier le contenu du cache sur son espace permanent quand il n'est plus sollicité. Sous Linux, on peut forcer cette écriture avec la commande `sync` (recommandée par exemple avant de retirer une clé USB). Après avoir copié un gros fichier, vous pouvez voir le temps que prend cette opération parfois assez longue ! Pour les gros volumes de données, ce cache pourrait ne pas suffire en taille et donc entraîner un goulot d'étranglement le temps que le disque évacue le trop plein de données du cache vers sa mémoire permanente, pour pouvoir réceptionner les données qui continuent d'arriver.
Un RAMDisk n'a pas besoin de cache puisque le processeur est en ligne directe avec la mémoire RAM. Et petit bonus, le RAMDisk est très pratique pour écrire de nombreuses choses sans détériorer un SSD. Par contre la RAM coûte assez cher donc on peut pas en avoir des tonnes.
Voilà la différence entre mon SSD NVMe (PCI-E 3.0) et un RAMDisk (mémoire DDR4 3200MHz dual-channel). Il n'y a pas photo !
Cette contribution était de : http://blenderclan.tuxfamily.org/html/newbb/viewtopic.php?forum=7&topic_id=50737&post_id=589433