Impact de la compression sur le temps de rendu
OverdOzed
Inscrit:
23/02/2006 18:10
De Alpes-Maritimes
Post(s): 3172
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/2021 09:57
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
Questions & Réponses Graph editor: ne peut pas changer le handle type en free ? 5 87 Aujourd'hui 13:24:15
Redstar 
Moteur de jeu GameBlender et alternatives [non résolu] Cs (vaisseau)    [1][2][3]...[57] 561 182524 Aujourd'hui 13:22:35
Redstar 
Hors Sujet !! Le mal des répondeurs du forum (nouzautr's) 2 47 Aujourd'hui 13:14:36
Redstar 
Questions & Réponses Séparer un script en plusieurs add-ons 1 27 Aujourd'hui 12:32:49
Redstar 
Questions & Réponses [résolu] Pas d'ombre sur l'objet 7 96 Aujourd'hui 12:21:09
Lylo 
Questions & Réponses Prb modélisation hache | mirror modifier 3 80 Hier 07:05:53
Rimpotche 
Questions & Réponses [non résolu] Blend4web et Blender version 2.80 ?    [1][2] 16 3058 14/05 09:50:34
blendinfos 
Questions & Réponses export 1000x trop petit 4 68 14/05 07:50:57
Redstar 
Questions & Réponses Je patine avec mon personnage 8 293 14/05 00:37:43
Lylo 
Questions & Réponses [résolu] rendre visible image as plane et wireframe 3 85 13/05 15:54:36
Rimpotche 
Hors Sujet !! FActualités : un petit journal humoristique    [1][2] 11 836 13/05 10:23:37
Redstar 
Graphisme alternatif Logiciel anatomie, bouger un écorcher ? 3 199 12/05 08:55:27
Redstar 
[WIP] et travaux terminés [terminé] Le bouï, mon ^premier moyen métrage, avec des FX et montage Blender :D 2 93742 12/05 06:42:07
Lylo 
Questions & Réponses [résolu] Rendu d'une image sans avoir de flou - cycle 4 244 11/05 10:50:27
Redstar 
Questions & Réponses Du masculin vers le féminin avec lattice 2 182 10/05 20:25:01
Melodicpinpon 
Hors Sujet !! Outils produtifs en animation avec Blender 3 - tutoriel de 15 mm 0 104 10/05 19:52:42
meltingman 
Questions & Réponses Carré gris lors du rendu 2.93 4 167 10/05 16:39:11
Rayden 
Hors Sujet !! Vos habitudes de programmation 5 257 09/05 17:45:04
Bibi09 
Questions & Réponses [résolu] Transfer simulation cloth en boucle 3 211 09/05 10:31:27
Redstar 
Questions & Réponses Solidify-Material offset-problem 2 174 08/05 20:21:19
Melodicpinpon 

Qui est en ligne
100 utilisateur(s) en ligne (dont 40 sur Forums)

Membre(s): 1
Invité(s): 99


Redstar, plus...
Nouveaux membres
BrianneGat 16/5/2022
MichalMccl 16/5/2022
UtaPohlman 16/5/2022
MargeneIrh 16/5/2022
JessikaCha 16/5/2022
AmparoBuck 16/5/2022
JISLinnie 16/5/2022
YasminWinc 16/5/2022
JensOkk198 16/5/2022
Donnell088 16/5/2022
Dernier Ajout
2020-09-24.jpg

Evènements à venir
Jui 30
Anniv des Jedi :-D
Jui 9
BUG de Lyon
Jui 23
Anniv du BlenderClan !
plus 238 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