Impact de la compression sur le temps de rendu
OverdOzed
Inscrit:
23/02/2006 18:10
De Alpes-Maritimes
Post(s): 3071
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.
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 !

Contribution le : 25/07 09:57:17
Créer un fichier PDF de la contribution Imprimer



 Haut   Précédent   Suivant




Enregistrer votre réponse
Compte*
Nom   Mot de passe   Authentification
Message:*



[Recherche avancée]



Sujets récemment répondus
Forums Sujets Réponses Lus Dernières contributions
Moteur de jeu GameBlender et alternatives [non résolu] Cs (vaisseau)    [1][2][3]...[56] 558 170560 Hier 23:53:03
sbkodama 
Questions & Réponses MeasureIt et dpi 3 858 Hier 19:50:21
Laorz 
Questions & Réponses De Maya vers Blender concordance de axes. 9 73 Hier 17:04:59
Bibi09 
Questions & Réponses Armature en IK sur squelette complexe 0 20 Hier 16:40:33
Melodicpinpon 
Questions & Réponses texture procédurale qui suis une plane 1 64 Hier 10:54:35
Redstar 
Hors Sujet !! les tutos de Moonboots    [1][2][3]...[22] 214 21083 Hier 10:54:10
moonboots 
Questions & Réponses [résolu] Enlever "snapping" dans la timeline ? 6 98 Hier 09:47:12
CBY 
[WIP] et travaux terminés [terminé] Appli Blender de Poche en FR    [1][2][3] 29 1078 18/10 19:14:29
moonboots 
[WIP] et travaux terminés [WIP] La gabarre '' Le Gros Ventre''    [1][2][3]...[10] 92 17325 18/10 15:14:25
Bibi09 
Questions & Réponses Débutant Blender, temps de travail pour un rendu ? 2 75 18/10 11:37:55
Jalis 
Questions & Réponses [WIP] Dragster-Tracteur pour Bécassine    [1][2][3] 24 5706 17/10 18:37:48
Laorz 
Graphisme alternatif faire de la bd avec blender    [1][2][3]...[13] 123 9012 17/10 14:20:26
blend74 
Questions & Réponses Bug texture sur plane avec bevel 1 182 16/10 08:09:13
Laorz 
Questions & Réponses [terminé] Supprimer le lien d'un objet entre 2 scènes 4 125 15/10 12:52:21
Horemheb 
Questions & Réponses Blender kit : barre d'assets 0 74 15/10 09:26:52
Sphere3d 
Questions & Réponses MeasureIt et dpi 3 111 15/10 08:39:25
Cdric 
Questions & Réponses Comment faire la symétrie d’une multitude d’éléments.    [1][2] 13 65777 14/10 23:35:18
meltingman 
Questions & Réponses Conversion courbe 1 93 13/10 16:59:40
moonboots 
Moteur de jeu GameBlender et alternatives [non résolu] Godot Engine - Projet Arsenal    [1][2] 15 1070 13/10 16:14:33
Redstar 
Moteur de jeu GameBlender et alternatives hARMful engine    [1][2][3]...[9] 86 26630 12/10 17:38:03
Bibi09 

Qui est en ligne
131 utilisateur(s) en ligne (dont 37 sur Forums)

Membre(s): 11
Invité(s): 120


JaneenJano, WhittStacia, RosauraOlv, ColbyCrump, VeolaEmi55, BrandiGsel, MarianaBee, DelbertTea, LindellKathy, DelA812391, KlaraTull, plus...
Nouveaux membres
BonitaGawl 20/10/2021
DarwinBurn 20/10/2021
ReginaChri 20/10/2021
FRGImogene 20/10/2021
ValentinaW 20/10/2021
EulaliaHar 20/10/2021
GabrielleK 20/10/2021
Wade95767 20/10/2021
MckenzieKh 20/10/2021
ShariMayer 20/10/2021
Dernier Ajout
2020-09-24.jpg

Evènements à venir
Nov 18
Anniversaire de RichDeg
Dec 29
Anniversaire d'ebrain
Jan 8
BUG de Lyon
plus 247 plus d'élément(s)
 Par Mickaël Guédon [ebrain] © 2003-2021 The Blender Clan - hébergé par TuxFamily - Site déclaré à la CNIL sous le numéro 1155445