Explications relatives à la V5

Explications sur le fonctionnement de la V5
Verrouillé
Avatar du membre
Administrateurs
Messages : 456
Enregistré le : lun. 14 mars 2005, 17:07
Localisation : Marseille / Champagne/Seine
Contact :

Explications relatives à la V5

Message par Administrateurs »

Ce fil est créé pour recevoir les différents tests et les explications founies concernant la V5. Il est mis en post-it pour un accès plus facile. Ce message sera remis à jour et contiendra les titres des différents sujets. Cliquer sur le titre pour ouvrir le sujet.
1 - Choix des options de redimentionnement et de positionnement des objets.
2 - Transitions "Versailles"
3 - les problèmes de moirage.
4 - Déplacement d'une image
5 - Conseils pour une meilleure fluidité.
Modifié en dernier par Administrateurs le jeu. 30 nov. 2006, 09:22, modifié 12 fois.
Avatar du membre
Administrateurs
Messages : 456
Enregistré le : lun. 14 mars 2005, 17:07
Localisation : Marseille / Champagne/Seine
Contact :

Message par Administrateurs »

1 - Choix des options de redimentionnement et de positionnement des objets :

Le montage de test concernant cette rubrique peut-être téléchargé ici
En règle générale, avant de réaliser un diaporama, on est amené à travailler ses images, les recadrer et redimensionner à un standard que l'on choisi dès le début.

Les incrustations, titres, cadres etc que l'on réalise sont en toute bonne logique adaptés aux dimensions que l'on a défini, il n'est donc pas idiot de penser que tous ces éléments seront enregistrés à la même échelle et à la même qualité.

Lors de la réalisation du montage, à supposer que l'on veuille faire un montage dont les dimensions s'adapte à l'écran, il est plus rationnel de faire en sorte d'assembler tous les objets à la même échelle et que l'ajustement à l'écran se fasse sur l'ensemble des objets assemblés plutôt que d'assembler des objets s'ajustant à l'écran indépendemment et qui plus est, s'ils n'ont pas la même dimension avec des ratios différents, certains étant référencés à la largeur, d'autres l'étant à la hauteur.

Pour faire en sorte que l'ajustement se fasse à l'ensemble des objets, le plus simple est que tous les objets dépendent d'un seul objet qui s'adapte à l'écran et qui transmettra à tous les objets "enfant" cette adaptation. Ainsi le rapport entre ces différents objets sera de 100%, ce qui est tout de même plus facile que d'avoir un ratio de 24.219% pour un premier objet, de 16.042% pour un second et de 33.542% pour un troisième comme j'ai du le faire dans la dernière vue de l'exemple lorsqu'ils s'ajustent indépendemment.

Si l'on met en objet de niveau 1 une vue à la dimension standard définie (1280x960 dans l'exemple), tous les objets réalisés à la même échelle pourront avoir un Zoom à 100% tout en s'adaptant à l'écran en fonction des caractéristiques de l'image de niveau 1, du ratio choisi dans la Configuration des options du montage (onglet écran) de la définition d'écran.
Pour les vues n'ayant pas d'images à la dimension standard, il suffira d'utiliser comme objet de niveau 1 un rectangle à la taille standard (cette option n'existe pas dans la #2, il faut faire la modif manuellement dans le fichier PTE, j'en ai fait la demande à Igor et à priori, ce serait intégré dans la #3).
PS La fonction a bien été incorporée

En plus de la facilité que représente cette façon de faire, on aura une qualité homogène de tous les objets du montage, d'ou une meilleure qualité de l'ensemble.

L'objet de niveau 1 pourra avoir l'option "ajuste à l'écran" ou "couvre l'écran", tous les objets de niveaux inférieurs lui étant rattachés auront tous l'option "original".

Ayant, à priori redimensionné tous les objets (photos, incrustaions, titres etc) à la même échelle, le nombre de pixels des différents fichiers est par définition entier. Si l'on veut superposer 2 motifs identiques, la position relative d'un fichier par rapport à l'autre sera automatiquement un multiple de 0.5 pixel.
Dans la fenêtre "Objets et animation", les valeurs de la fonction "Pan" peuvent être incrémentées par la souris de 1 pixel, aussi pour ne travailler qu'avec un nombre de pixels entier, le plus simple est de n'avoir que des fichiers ayant des dimensions paires (ça va 3 fois plus vite lors du positionnement, seule la souris est nécessaire).
Pour pouvoir bénéficier de cette facilité d'emploi, encore faut-il que le positionnement des objets soit en pixels et non en %.

Le fichier joint a pour but de démontrer l'avantage de cette méthode. Le montage de test comporte 5 vues qui permettent en même temps de voir comment positionner les objets en utilisant une image de fond provisoire en couleurs inverses et des objets mis à 50 % de transparence. Lorsque l'objet est à la bonne place, l'objet devient d'un gris parfaitement uni, et ses coordonnées dans le Zoom sont nécessairement un entier (sinon mettre l'entier le plus proche).
PS La fonction "transparent pour le clic" facilite encore plus la tâche, il suffit d'avoir l'image de fond à 50% d'opacité et de la mettre en avant plan en activant la fontion "transparent pour le clic". Plus besoin de mettre chacun de objet à 50% d'opacité pour les placer.

Dans la première vue du montage, l'image de fond est l'image définitive, avec pour option "Ajuste à l'écran", et tous les objets sont positionnés approximativement, avec en option "Original" et "En pixels", leur transparence étant réglée à 50 %.

La seconde vue montre le positionnement terminé des objets. Pour cela l'image de fond est remplacée temporairement par son image en couleurs inversée. Pour positionner les objets avec précision, d'abord mettre les valeurs du "Pan" à l'entier le plus proche, puis déplacer l'objet en cliquant sur les flèches associées aux fenêtres Pan.

La 3ème vue montre ce que l'on obtient en ayant remis l'image de fond et remis tous les objets en opacité totale.

La 4ème vue est la même vue animée, pour chaque objet, on crée un point clé qui sera le point d'arrivée de l'objet dans lequel vont être dupliqués les paramètres de Pan, tous les Zooms étant à 100% et les Rotations fixées à 0. Puis on retouche les paramêtres du point de départ (Pan,Zoom, Rotation et Transparence, éventuellement Centre), et l'on ajoute des points clés intermediaires si nécessaire pour obtenir l'effet désiré.

Dans cette vue, un cadre composé d'un même rectangle utilisé 4 fois et d'une image de 20 x 20 px utilisée elle aussi 4 fois, simple et pas lourd, ni pour les Ko, ni pour la mémoire de la carte graphique.
Note : avec cette technique, en la compliquant un peu, on peut faire des cadres bien plus complexes avec simplement 2, 3 ou 4 rectangles au lieu d'un seul, le fichier pour les coins restant unique.

La 5ème vue utilise la méthode utilisée par Igor pour ses montages et par bien d'autres, je ne l'ai volontairement pas terminée, pour ceux qui voudraient la compléter, au cas ou mes arguments ne les auraient pas convaincus, après cet essai, ils le seront.
Tous les objets sont au niveau 1, ajustés à l'écran et en option "en pourcents". Pour mettre en place les quelques objets j'ai mis plus de temps que pour faire le montage complet avec l'autre méthode, et encore, j'ai triché car je me suis aidé du tableur, avec seulement PTE : mission impossible.

J'espère obtenir d'Igor qu'on puisse changer le paramétrage par défaut :

JPD le 10/05/06 :

1 - Would it be possible to have the choice of the default parameters for mode an position (properties of objects windows). I found it was easier to work first in "Original" mode and choice if necessary "Fit to screen" when the job is finish.

2 - When using Pan/Zoom/Rotate, but also with "Push" and "Slide" effects, there are non useful picture around the usefull picture (see below). Would it be possible for these objects to define the part where it must not appear (it's alway possible to put above a mask (as in the exemple), but in this exemple, the total picture is larger than 3000x3000). I found a solution with using a mask and 8 times a blank picture as show (green and violet part), but it's not an easy way and made more calculation for the graphic card.
I know you prefer the "Fit to screen" option, but there are many people here who want to use "Original" option without using windowed mode in screen option.

3 - Another request about "windowed mode" in screen option : would it be possible to have an option "with" or "not" a background instead of the desktop.


Igor le 10/05/06 :

1. I plan to add new global option "Don't resize images" which will set "Original size" to main images of all slides.

2. We'll think about mask later. I agree there is a problem now, but
we would like to work with this moment a little later (probably not in v5.00) you see that we have so many not re-activated "old" functions.

Personally we very don't like "Original size" mode, because on HDTV displays (1920x1080 and larger) images will be very small, like a postcard.
So Fit mode is better, on my opinion.


Also Pan/Zoom for images with "Original size" mode may look
incorrectly on larger screen resolutions.


NB Le point 2 permettrait de résoudre le problème que Medericke a rencontré, le point 3 permettrait d'utiliser le mode fenêtré avec un fond noir en lieu et place du bureau de Windows, mais pour ces 2 points, ce n'est pas gagné d'avance.

En gras, ce qui m'a poussé à utiliser le formmat TVHD pour Versailles :-)

Recommandation : sauf cas particulier, paramétrer tous les objets de niveau 1 en "Ajuste à l'écran" et "En pourcents" avec en niveau 1 des objets de mêmes dimensions, des rectangles s'il le faut. Pour tous les objets de niveaux inférieurs, utiliser "Original" et "En pixels"
Modifié en dernier par Administrateurs le mar. 15 août 2006, 15:12, modifié 3 fois.
Avatar du membre
Administrateurs
Messages : 456
Enregistré le : lun. 14 mars 2005, 17:07
Localisation : Marseille / Champagne/Seine
Contact :

Message par Administrateurs »

2 - Transitions "Versailles"

Comme promis, voici les premiers fichiers PTE concernant les transitions que vous m'avez demandé de décortiquer.
Comme je vous l'avais dit, le format choisi était celui de la TVHD et le but originel du montage était de faire différents tests sur la V5 #2.

Cliquer sur les N° de transition pour télécharger les fichiers tests.

1ère transition :

La transition expliquée ici avait pour but de vérifier la précision sur un cas pratique.

Une image a été découpée horizontalement en 45 parties de 24 pixels de haut chacune. Cette valeur de 24 pixels a été choisie car les fichiers JPG sont plus performants en ayant des dimensions multiples de 8.

45 fichiers JPG ont été créés ainsi que 2 fichiers PNG et 2 fichiers BMP 32 bits.
Pour les fichiers BMP et PNG, un fichier avec transparence contient les 23 parties impaires espacées de 24 pixels, un second contient les 22 parties paires espacées elles aussi de 24 pixels et décalées de 24 pixels par rapport au premier fichier.
Ainsi en superposant ces 2 fichiers on reconstitue de façon parfaite l'image originale.

Au niveau du fichier PTE, le but recherché est qu'en début de vue on ne voit que l'image de fond et progressivement apparaissent de droite et de gauche les "lamelles" d'image qui un fois position au centre de l'écran formeront l'image complète.

Plusieurs options sont possibles, quelques-une sont dans le fichier de démo :

Dans la première vue, les 45 "lamelles" en JPG sont en niveau 2, sous l'image de la vue de départ.
Pour chaque objet "lamelle", les options choisies sont "original" et "en "pixels", mais dans le cas présent, cela n'a pas d'importance, avec les options "ajusté à l'écran" et "en pourcents", on aurait eu la même précision, ce qui n'est pas toujours le cas.
Chaque objet dispose de 3 points-clés : les 2 premiers, situés en début de vue et en fin de transition début, positionnent les lamelles de rang impair à gauche et en dehors de l'image de fond (-1920 pixels) et les lamelles de rang paire à droite de l'image de fond (+1920 pixels). Un 3ème point-clé, positionné par rapport à la fin de la transition précédente positionne toutes les lamelles au centre de l'écran horizontalement. A ce point, l'image d'origine est reconstituée si tout se passe bien. Le 3ème point-clé est synchronisé entre tous les objets.
Dans cette version il y a 135 points-clés sur l'ensemble des objets.

Dans la seconde, il y a 2 objets de niveau 1, transparents auxquels sont associés en niveau 2 les 23 objets impairs pour l'un, les 22 objets pairs pour l'autres (dans chaque groupe il y a un espace de 24 pixels entre chaque objets). Cette fois-ci les points-clés ne sont que sur les objets de niveau 1, et ce sont les 2 ensembles que se déplace et non plus chacun des objets.
A noter que dans ce cas, il est impératif que les objets de niveau 1 soient paramétrés en pourcentage et non en pixel, car ne connaissant pas la définition de l'écran sur lequel sera vu le montage, le décalage en nombre de pixels ne correspondra qu'à une seule définition d'écran.
Dans cet exemple il n'y a plus que 6 points-clés.

Règle : lorsque plusieurs objets ont une animation identique, il vaut mieux ajouter un objet (rectangle) sur lequel s'appliquera l'animation et de mettre les objets comme enfants de l'objet intermédiaire.

Dans la troisième vue, le montage est semblable à la vue 1, mais il y a un décalage dans le temps des points-clé, ce qui modifie l'aspect de la transition, les "lamelles" du haut se mettent en place avant celles du bas.

La quatrième vue est identique à la troisième à ceci près que ce sont les "lamelles" du bas qui se positionnent en premier.

La cinquième vue est identique à la précédente, sauf que toutes les lamelles arrivent en même temps. Pour être franc, c'est pas du meilleur effet.

La sixième est identique à la quatrième, sauf que le fichier de 1920 x 1080 a été remlacé par un rectangle de taille équivalente (pour l'instant, il faut modifier les valeurs dans le fichier PTE, mais l'option va exister).

La septième est identique à la précédente sauf que le rectangle est maintenant transparent.

Dans la huitième, c'est la largeur des "lamelles" qui varie, leur partie gauche (ou droite selon le cotê) reste fixe, quand leur largeur atteint 100%, l'image est reconstituée.

Dans la neuvième vue, tout est identique à la huitième, mais en plus, l'Opacité passe de 20% à 100%, c'est personnellement l'effet que je préfère parmi ceux montrés dans cet exemple.

Les 10ème et 11ème vue ont été faites avec les fichiers PNG et BMP avec une partie de l'ensemble (800x600) pour cause de taille, mais l'on voit nettement qu'il y a un défaut de raccordement (si vous assemblez ces fichiers dans Adobe ou autre, il n'y a pas de défaut). Le problème a été signalé à Igor, mais pour l'heure il n'a pas encore réagi.

2ème transition :

Cette transition n'est pas d'une grande originalité, mais permet de voir comment 2 effets peuvent cohabiter sans que les images recouvrent la partie attribuée à l'autre effet.

Dans la première vue, c'est la partie gauche qui sera active (un zoom). La photo correspondante est donc mise en premier et la photo de droite vient par dessus et un cadre encore par dessus, l'action du zoom n'apparait que dans la partie non cachée par les 2 autres fichiers.

Remarque : c'est par manque de temps que j'ai mis un cadre réalisé en GIF. S'il ne pèse pas lourd en Ko, il encombre de façon significative la mémoire vive de la carte graphique (1920x1080 octets) et augmente le temps de transfert entre RAM et mémoire vidéo en proportion. Il aurait été beaucoup plus judicieux d'utiliser 5 cadres blancs qui n'ont pas tous les inconvénients précités. Ce sera plus facile quand on pourra choisir la taille des cadres.

Dans la 2ème vue, les rôles sont inversés, et c'est la photo de droite qui est en arrière-plan. Là ou se trouve le problème, c'est que l'on ne peut pas réutiliser la photo gauche de la vue précédente car elle dborderait sur la partie droite, masquant en partie l'autre photo. C'est la raison pour laquelle c'est un autre fichier qui est utilisé, il faut simplement prendre soin que la superposition des 2 vues soit au pixel près :-) pour que ça ne se voit pas.

Remarque : initialement les 2 vues n'en faisait qu'une, mais lorsqu'on peut faire la même chose avec plusieurs vues, ça a l'avantage de soulager la mémoire de la carte graphique, toutes les images n'étant pas chargées en même temps.

3ème transition :

Cette transition a pour but de reproduire l'effet qu'on a avec certains panneaux publicitaires utilisant des triangles tournants sur un axe. L'objectif initial étant de voir si la juxtaposition de 2 images se faisait parfaitement en cas de variation des zooms.

En fait, la juxtaposition laisse entrevoir légèrement l'arrière plan dans certains cas. Pour ce genre d'opération, il sera sage de prévoir un recouvrement de 1 pixel pour être tranquille.

La vue est composée de 16 images au niveau 2. Là encore, lorsque le bug sur les rectangles (erreur de 1 pixel sur la dimension) sera reprise et qu'on aura la possibilité de saisir les dimensions du rectangle, il sera beaucoup plus intéressant de les utiliser que d'utiliser un fichier GIF (Pb mémoire CG).

Chacun de ces 16 éléments a deux sous-objets en niveau 3, chacun étant le 1/16ème de chacune des vues de départ et d'arrivée.

Au départ, les 16 objets de niveau 3 correspondant à l'image de départ ont un zoom horizontal de 100% tandis que ceux correspondant à l'image d'arrivée sont à 0%.

Pour chacun des 32 sous-objets de niveau 3; il y a 7 points-clés intermédiaires correspondant à des écarts de rotation du triangle de 15°, les valeurs de Zoom et de Pan étant calculées en fonction (merci Excel).

La vue de fond a été conçue pour que les microscopiques écarts entre deux portions d'images ne laissent apparaitre quelques pixels noirs.

Cet essai m'a permis de vérifier la grande précision des calculs faits par PTE. Le recouvrement de 1 pixel ou le fond de plan que j'ai utilisé n'étant utiles que parce que dans certains cas les arrondis ne sont pas favorables, et ça, même Igor n'y peut rien :-)

4ème transition :

Cet exemple montre l'utilisation d'une troisième image, comme quoi il n'y a pas que le Pan/Zoom/Rotate dans la V5.

On peut, comme je l'ai fait, faire apparaitre plus tôt ou disparaitre plus tard certaines parties de l'image (La statue dorée dans l'exemple), mais aussi faire varier la progressivité d'une transition en fonction du temps sans l'artifice d'une image intermédiaire.

5ème transition :

Cette transition "ouverture de fenêtre" est assez simple à mettre en place, il suffit que la première vue soit composée de 2 fichiers JPG juxtaposés iniatlement avec Zoom horizontal à 100% et qu'en fin de transition, le Zoom horizontal soit à 0.001 tandis que le Pan "sorte" l'image de l'écran (j'ai mis 1 pixel de marge).

L'utilisation de 2 rectangles gris permet de simuler l'épaisseur de la page, celle-ci va en augmentant et son opacité passe de 0 à 100%.
Les rectangles se déplace de façon synchronisée avec les 2 demies-vues, du centre vers les bords (décalés de 4 pixels pour tenir compte de leur épaisseur).

6ème transition :

Cette transition avait pour objectif de tester la précision de l'enchainement de 2 effets successifs (très intéressant par exemple pour un fondu-enchainé comportant une 3ème image).

C'est la fonction zoom qui a été choisie pour ce test, car très sensible au moindre à-coup.

5 fichiers JPG provenant de la même image sont assemblés de façon à couvrir l'écran tout en laissant une fenêtre (cette façon de faire pèse beaucoup moins lourd qu'un fichier PNG qui aurait une partie transparente).

Note = 4 fichiers "masque" auraient pu suffir pour cette seule vue, mais ces fichiers étant utilisés par d'autres vues, c'est le découpage le moins lourd pour l'ensemble du montage qui a conduit à utiliser un fichier "ombre" (23-O).

La partie Zoom, au lieu d'utiliser une seule et même image que l'on aurait zoomé de 34.3% (70% x 70% x 70%) à 140 % a été remplacée par 3 images successives de la même vue à des échelles différentes, la 1ère (vue de loin) passe de 70% à 100%, puis la seconde qui est identique avec un zoom à 70% que la première avec zoom à 100% prend le relais pour passer de 70% à 100%, enfin la 3ème (vue de près) passe de 70% à 140%.

Les variations de pourcentage du zoom étant une fonction linéaire par rapport au temps, les points-clés sont positionnés proportionnellement au valeur de zoom qu'aurait eu une seule et même vue. L'apparition des deux dernières vues est conditionnée par le début de présence de ces objets (trait bleu de gauche).

Ce test montre que la jonction n'est pas visible, ce qui signifie que l'on pourra faire des enchainements fondu-enchainé avec 3 ème image parfaits (et bien d'autres).

A noter que le poids des 3 fichiers est inférieur au poids qu'aurait eu, à qualité égale, une seule et même image (1189 Ko contre 1443 Ko), d'autre part la partie nécessitant un cache est diminuée d'une façon considérable, ce qui peut avoir un intérêt s'il y avait 2 fenêtres avec effet sur la même vue.

7ème transition :

Ces transitions sont basées sur le même principe que la N° 3, sauf qu'ici les effets sont réalisés dans une fenêtre.

Les objets "Fond ...." devront être remplacés avec la béta 3 par des rectangles de tailles équvalentes, ce qui allègera la mémoire de la carte graphique.

8ème transition :

Cet effet avait pour but de vérifier la qualité de la fonction Rotation.
Pour cela j'ai mis le sigle Diapositf comme enfant d'un objet quelconque (carré transparent de quelques pixels, mais ç'aurait aussi pu être un rectangle). Le sigle étant en paramètre "Original".
Le sigle a été décentré par rapport à son objet-parent à l'aide des fonctions Pan.

Une rotation a été appliquée à l'objet parent, faisant parcourir un cercle au sigle (ayant fait varier les valeurs de décentrage simultanémént, c'est non pas un cercle mais une spirale).

S'il n'y avait eu de rotation strictement inverse au niveau du sigle, il aurait eu la tête en bas à un instant donné. C'est cette rotation inverse qui fait que le sigle Diapositif est toujours à l'horizontal.
Le "Soleil" suit la même trajectoire.

Cet exemple montre que la fonction Rotation est parfaitement homogène et s'applique strictement de la même façon sur 2 objets différents, y compris dynamiquement.

Note : Le paramètre "Centre" permet de faire parcourir un cercle sans faire appel à un objet-parent, mais cette fonction a un énorme défaut, elle est en pourcentage par rapport à la dimension de l'objet, et si celui-ci est petit et de rayon du cercle de la trajectoire grand, il faut un pourcentage énorme.

Pour moi cette fonction pourrait-être supprimée puisqu'on peut faire très facilement la même chose avec un parent et la fonction Pan qui elle peut être en pourcents ou en pixels.

Pour la signature, j'ai utilisé une astuce imaginée par Lin Evans (Wnsoft forum) qui consiste à superposer 2 images identiques, celle du dessus étant un format permettant la transparence et ayant ce que l'on voudra afficher, comme zone transparente (la signature dans l'exemple).

Il suffit d'intercaler une image opaque ou un rectangle entre les 2 vues et de l'animer pour que la partie transparente laisse voir l'objet intermediare progressivement.

L'idéal serait de combiner la méthode de Lin Evans avec une autre mise au point par Thedom (toujours sur Winsoft) ou celle que j'ai mise au point pour mon test "Draw"
Les effets basés sur ces principes ont une multitude de variantes possibles.

La méthode de Lin Evans donne un résultat plus lourd mais beaucoup plus propre que la mienne car il n'y a pas de fonction anti-aliasing sur les rectangles.
Modifié en dernier par Administrateurs le sam. 19 août 2006, 09:22, modifié 5 fois.
Avatar du membre
Administrateurs
Messages : 456
Enregistré le : lun. 14 mars 2005, 17:07
Localisation : Marseille / Champagne/Seine
Contact :

Message par Administrateurs »

3 - les problèmes de moirage
Igor a prévu une fonction "Flou" (Blur) qui permet d'éviter ou de limiter les effets de moirage qui peuvent apparaite lors de l'utilisation du Zoom.

Il avait indiqué sur Wnsoft que cet effet apparaissait lorsqu'on avait utlisé les fonctions d'accentuation dans le traitement de l'image ou que celle-ci comportait beaucoup de détails, comme c'est le cas d'un arbre.

La fonction flou est effectivement efficace contre le moirage mais quand l'image est fixe, elle n'est plus nette, aussi j'avais imaginé une solution : que la fonction "Flou" ne s'applique que lors du Zoom, j'avais fait un test que j'avais envoyé à Igor le 10 mai avec cette demande :

"Another question about Blur. I have understand that blur is especially done when pictures are moving (Problem of moire). If we want to have a good picture when picture doesn't move and good picture when it move we have to use twice the same picture, first with blur and second without blur as in the exemple Project1... in order there is blur only when picture is moving.
Would it be possible than blur function is in the animation window and can be change just at same position as the keypoint to have the same result as in the exemple, or may be another possiblity is that blur is used only when pisture is moving (easiest solution for users) and can stay where it is now."


Mais sa réponse immédiate a été :
"3. "Blur" option works for entire object. In fact we just add slight Gaussian blur to the image when you enabled "Blur" option. So you can only add second image. But maybe large image (2500 x 1600) even with blur looks enough sharp?"

Pour simplifier : puisque vous avez une solution, PTE reste comme il est et utilisez votre solution, du moins c'est comme ça que j'ai traduit.

Donc voici la solution que je lui avait proposé :

Le principe, on met 2 fois l'image en les superposant, l'une avec flou, l'autre sans, et en jouant sur l'opacité, on fait en sorte que ce soit celle sans flou qui soit affichée lorsque l'image est fixe, et celle avec le flou activé lorsque le zoom est en action.
Je vous ai mis ici un fichier PTE permettant de voir l'effet ainsi réalisé.

Les vues 1 et 5 sont sans flou du début à la fin (avec moirage)
Les vues 2 et 6 sont avec flou du début à la fin (donc image fixes pas nettes)
Les vues 3 et 7 utilisent alternativement chacune des 2 vues, les images fixes sont nettes, le Zoom n'a pas de moirage.

Les 3 premières sont avec l'anti-aliasing activé, les autres sans.

Par ailleurs, il avait indiqué que ça pouvait se produire avec la fonction Pan lorsqu'on est en "Original". La vue 9 est un Pan, mais je n'ai pas recontré ce qu'indiquait Igor, je n'ai donc pas pu tester la solution sur des Pan.

PS l'image a été accentué (masque flou = 1px à 200%, ce qui est énorme, surtout pour des arbres).

Seule préoccupation : je ne sais pas si une même image chargée 2 fois en mémoire vidéo occupe ou non 2 fois plus de place, je poserai la question.
Modifié en dernier par Administrateurs le mar. 15 août 2006, 15:09, modifié 1 fois.
Avatar du membre
Administrateurs
Messages : 456
Enregistré le : lun. 14 mars 2005, 17:07
Localisation : Marseille / Champagne/Seine
Contact :

Message par Administrateurs »

4 Déplacement d'une image

En l'absence d'antialias :
La plus petite valeur pour le déplacement d'une image est 1 pixel.
Si l'on déplace une image pixel par pixel, on aura une impression de mouvement saccadé, incompatible avec la fluidité des mouvements requise.

Pour résoudre le problème, entre les déplacements de 1 pixel, l'image affichée est recalculée en tenant compte de la position intermédiare à simuler.

Pour essayer d'être plus explicite, si l'on veut reproduire ce que fait PTE entre 2 sauts de 1 pixel, il faudrait :
1 - Agrandir l'image dans un rapport de 10, par exemple.
2 - Faire 10 copies de l'agrandissement
3 - Décaler chacune de ces copies de respectivement 0, 1, 2, 3, 4, 5, 6, 7, 8 et 9 pixels
4 - Réduire les 10 images dans un rapport de 10 pour retrouver le format d'origine
5 - Faire défiler dans l'ordre les 10 images obtenues.
Ainsi on aurait l'illusion d'un déplacement fluide sur 1 pixel. C'est ce qui a été fait dans Hubble V4 pour que la lune se déplace d'une façon à peu près fluide, 12 images sont affichées au même endroit avant de redéfiler au pixel suivant (4 pas intermédiares horizontaux et 3 verticaux)

C'est ce que PTE fait. je ne connais pas le nombre d'images interpolées mais c'est ce principe qui est utilisé. L'interpolation est faite en rééchantillonnage bilinéaire (le bicubique, certe meilleur demande de 20 à 30 fois plus de calculs). Il n'est pas exclu qu'à terme une option "Au plus près" appelée encore "nombre de pixels" soit disponible en option.

Le mouvement d'une image (ou d'un objet quelconque) se fait donc de la façon suivante :
Saut de 1 pixel, affichage des images interpolées, à nouveau saut de 1 pixel et ainsi de suite.

Le fait que les images soient interpolées peut provoquer des artefacts. Téléchargez l'album PTE pour suivre les explications ci-après :

Dans la 1ère vue 9 images de 41 x 41 pixels avec des traits verticaux de 1 pixels, noirs et blancs sont superposées à 9 images de 42 x 42 pixels. Ces images ont 2 bords rouges et 2 bords bleus.

Au départ, les images rayées sont positionnées en haut et à gauche des images de 42 pixels qui elles restent fixes. Dans un point-clé (à 5500 ms), elles sont positionnées en bas et à droite des images 42 x 42. Entre les 2 points, les images rayées se seront déplacées de 1 pixel en horizontal et 1 en vertical.

Si vous allez dans la fenêtre animation, avec un affichage à 100%, vous constaterez que l'image laisse apparaitre 1 trait rouge en bas et à droite et les traits noirs et blancs sont nets.

En faisant avancer le curseur sur la time-line, on voit tout d'abord disparaitre les traits rouges au profit des traits bleus en haut et à gauche. Cela signifie que les images rayées se sont déplacées de 1 pixels en vertical et horizontal. L'image rayée a perdu 1 pixel à gauche et une ligne calculée par interpolation a été rajoutée à droite.

Si vous avancez encore le curseur, les traits noirs et blancs ont moins de contrastes, puis tous sont à cheval sur 2 pixels. Lorsqu'on est à mi-chemin, il n'y a plus de contraste du tout, tous les traits sont gris, et réapparaissent lorsqu'on avance pour finir en noir et blancs losqu'on atteint position suivante (*)

* Il n'y a pas de pixels au centre de l'écran, ceux-ci ayant toujours un nombre pair de pixels en vertical et horizontal. Pour qu'un pixel de l'image concorde avec un pixel de l'écran, il faut qu'il soient superposés, sinon le pixel de l'image aura la moitié de sa valeur sur un pixel d'écran et l'autre moitié sur un second pixel d'écran.
Dans l'exemple, l'image ayant un nombre impair de pixel (41), il faut décalée l'image de 0.5 pixel afin qu'il y ait concordance comme c'est le cas en début et fin de mouvement.

Dans l'exemple, l'image 41 x 41 pixel est grise quand son positionnement est à un nombre entier de pixels, si l'image avait une dimension paire, les rayures seraient parfaitement nettes.

La vue 2 de l'exemple est l'agrandissement de la vue 1, voir ci-dessous :

:80: Image

:160: Déplacement d'un carré de 41 x 41 de 1 pixel

La conséquence de ces règles est qu'un filet noir et blanc de 2 pixels de large n'aura pas le même aspect à l'affichage selon sa position, même en restant affiché à sa taille d'origine.

C'est ce que montre la vue 3 ou un seul et même filet est affiché avec des valeurs différentes.

:80::20: Image

Cas particulier : les fichiers (JPG ou BMP) ne contenant qu'une seule couleur. En l'absence de l'antilias, les images interpolées étant toutes les mêmes, on ne voit le déplacement que pixel par pixel, c'est à dire un déplacement saccadé.

La figure ci-dessous montre des traits blancs de 1 pixel décalés de 1/10ème de pixel en 1/10ème. Dans la première ligne, ces traits sont sur des fichiers transparents de 3 pixels de large, le trait blanc étant au centre. Le bloc de gauche est en GIF, celui du milieu en BMP 32 bits, celui de droite en PNG.
Dans la seconde ligne les fichiers sont non transparents et de 1 pixel de large. Le bloc de gauche est en GIF, celui du milieu en BMP, celui de droite en JPG.

:80::20: Image

Pour la seconde ligne, le résultat est le même, les traits sont toujours parfaitement blancs, mais leur position ne tient pas compte des 1/10ème de pixels, et pour rattraper cette erreur, il y a un pixel de plus entre le premier et le second trait (voir cas particulier ci-dessus).

Pour la première ligne, le fichier faisant 3 pixels de large, PTE peut interpoler le trait blanc en fonction de sa position. Dans le cas de pixel en limite d'une zone transparente, PTE réparti chaque pixel sur 2 pixels au prorata de la position relative à un nombre de pixel entier. C'est sur le réglage de la transparence que se fait la répartition de couleur.
Pour exemple, si le trait est à 50% entre 2 pixels, il y aura 2 pixels blancs côte à côte chacun ayant 50% de transparence. Sur un fond noir, cela donne un trait de 2 pixels avec un gris à 127 ou 128.
On constate un écart entre les valeurs théoriques et les valeurs relevées, surtout en ce qui concerne le fichier GIF.
Ci-dessous comparatif visuel entre théorie et pratique :

:80::20: Image

Comme on peut le contater, les résultats obtenus avec PTE sont plus sombres qu'ils ne devraient, c'est flagrant pour le fichier GIF.

Pour se rendre compte de l'effet que produit ce petit défaut, j'ai positionné 2 carrés de 20 par 20 sur une transparence de 40 x 40 et 2 triangles (carré dont la moitié est transparente) en GIF et en PNG :

:80::20: Image

Lorsque les pixels des objets sont superposés avec les pixels de la définition d'écran, seuls les GIF présentent un défaut très léger, à peine visible. Par contre lorsque ces objets sont décalés d'un demi pixel, des défauts très nets sont constatés sur le GIF et un défaut très léger sur le PNG sur les verticales ou horizontales.
Ayant fait part de ces observations à Igor, il m'a conseillé d'utiliser le PNG, ce qui signifie que les problèmes avec les GIF ne seront sûrement jamais traités.
Il vaut donc mieux suivre son conseil :-)

Lors du rééchantillonge des PNG, celui-ci prend en compte la couleur de la partie transparente (on la voit dans l'aperçu de PTE de la fenêtre animations).
Ci dessous le résultat de superposition de 3 fichiers identiques mais dont la couleur de la transparence diffère, ceci explique la différence constatée ci-dessus entre le triangle et le carré PNG :

:80::20: Image

Il semble que par défaut la couleur de transparence soit noire avec Pixbuilder et blanche avec Adobe CS2... sujet à vérifier.
Avatar du membre
Administrateurs
Messages : 456
Enregistré le : lun. 14 mars 2005, 17:07
Localisation : Marseille / Champagne/Seine
Contact :

Message par Administrateurs »

5 - Conseils pour une meilleure fluidité. Version testée béta#7.

L'un des 2 moteurs de la V5 fait appel aux cartes graphiques. Cela lui permet de faire des effets Pan/Zoom/Rotation beaucoup plus fluides qu'en utilisant le seul processeur de l'UC comme le fait le second moteur ou celui de la V4.

Le résultat en terme de fluidité dépend des caractéristiques de la carte graphique du PC sur lequel on lit le montage. Cette carte n'est pas forcément aussi bonne que celle du PC sur lequel a été réalisé le montage.

Il est actuellement difficile, sans retour, de savoir si le montage que l'on a produit est lisible ou non par une majorité de machines, les gens ne pouvant lire un montage ne se manifestant quasiment jamais.

Pour remédier à cela, j'ai réalisé de très nombreux tests (1) permettant maintenant d'indiquer les grandes lignes qui devraient permettre de réaliser un montage accessible au plus grand nombre.
(1) Voir ici, ici, ici, et .

1 - Eviter d'avoir une grande image sur la 1ère vue associée à un effet PZR, ou de nombreuses images importantes (7 ou 8 images 1600 x 1200 sur la vue 1) cela plante sur un certain nombre de machines (écran noir).
Pour contourner le problème : Démarrer le montage par 2 vues "neutres" utilisant un petit fichier BMP noir de quelques pixels de côté ou une image normale sans effet PZR.
La première vue peut être aussi courte que 20 ms avec un fondu-enchainé de 20 ms (Ne pas mettre de transition instantanée), la seconde vue pouvant être d'une durée aussi courte que 1 ms avec une transition instantanée.
Il est cependant très fortement recommandé de laisser sur l'ensemble de ces 2 vues une durée suffisante pour que PTE puisse charger l'image de la 3ème vue, de l'ordre de 320 ms sur une machine très moyenne pour une image de 1024 x 768, incluant lecture sur le disque dur, décodage du jpg et transfert dans la mémoire graphique. Les temps de chargement étant sensiblement proportionnels à la taille. Compter 10% de plus pour les fichiers PNG.

2 - Eviter d'avoir un poids en mémoire graphique trop élevé sur 3 vues consécutives. Le poids d'une image n'a pas grand chose à voir avec son poids en Ko, mais dépend directement de sa taille.
Le poids en Mo est égal à largeur x hauteur en pixel x 4 pour les 3 couleurs et la couche alpha (transparence) que divise 1024 2 fois.
Exemple : un fichier de 1024 x 768 pèse exactement 3 Mo en mémoire graphique.

Pour les images en GIF ou en PNG, les partie transparentes pèsent autant que les autres, il ne faut donc pas laisser de partie transparente superflue dans une image.

Une partie de la mémoire étant utilisée pour la création de l'image affichée, il faut donc en tenir compte.
En gros, il faut pour l'image affichée :

7.4 Mo pour du 1600 x 1200
5.8 Mo pour du 1440 x 1050
5.0 Mo pour du 1280 x 1024
4.7 Mo pour du 1280 x 960
3.8 Mo pour du 1152 x 864
3.0 Mo pour du 1024 x 768

Ce qui laisse 24 Mo si l'on souhaite voir son montage tourner sur des machines disposant de 32 Mo en carte graphiques, 56 Mo sur les machines disposant de 64 Mo.

Traduit en dimensions totale à ne pas excéder sur 3 vues :
L'équivalent de 8 vues 1024 x 768 sur 3 vues dans le 1er cas, l'équivalent de 18 vues 1024 x 768 sur 3 vues dans le second.

Nota : lorsque la mémoire de la carte graphique n'est pas suffisante, la mémoire vive de l'ordinateur est utilisée en complément, le montage continue donc de tourner, mais d'une façon saccadée car la mémoire de l'UC est beaucoup plus lente.

Une solution pour alléger la charge de la mémoire est de "doubler" les vues, au lieu de mettre une image sur une vue pendant 6 secondes, on peut faire 2 vues avec la même image pendant 3 secondes chacune. Ainsi 2 vues utilisant la même image, celle-ci n'est présente qu'une fois en mémoire graphique, et donc ne sera additionné à cette image que le poids de la vue précédente ou suivante. C'est comme si il n'y avait plus que 2 vues en mémoire.

3 Limiter la charge de calcul de façon à ne pas dépasser les possibilités de calculs des cartes graphiques.
Il semble de ce point de vue que les capacité de calcul ont évolué moins vite que les capacités de mémoire, une carte moderne traitera moins bien une image en limite de capacité mémoire qu'une carte ancienne.
En clair une vieille carte 32 Mo (4/5 ans) aura moins de mal à calculer les effets PZR d'un fichier de 20 Mo qu'une carte moderne à 512 Mo l'aura pour un fichier de 300 Mo, bien que les % d'utilisation mémoire soient identiques.

La puissance de calcul nécessaire dépend de plusieurs paramètres, le nombre et le type d'effets, la taille des fichiers sur lesquels ils s'appliquent et la vitesse à laquelle ils sont éffectués.

Autant que peut se faire, il vaut mieux répartir dans le temps les besoins en calculs.
La répartition d'un effets sur plusieurs vues, outre le fait qu'il diminue la charge mémoire diminue aussi grandement les besoins en puissance.
Un zoom qui fonctionne sur une machine lorsque sa durée est d'une minute ne fonctionnera pas forcément correctement si l'on descend à 30 secondes et a toutes les chances de cafouiller si l'on descend à 10 secondes.

Un ensemble d'albums mis sur ce post permettent de vérifier que la répartition d'un effet sur plusieurs vues améliore la fluidité.
Dans cet exemple, une vue unique ne peut tourner sur aucune machine existante, avec 2 vues, uniquement sur des machines super puissantes alors que le même montage avec une répartition du travail sur 10 vues, non seulement tourne correctement mais est capable d'aller 4 fois plus vite que la vitesse initiale choisie.

En pratique, pour les Pan test complémentaires en cours.

En pratique pour les zooms, un ratio de 70% par vue en 5/6 secondes est accepté par les cartes 32 Mo assez anciennes (taille image = 1832 x 1374 pour une définition 1280 x 960 à 70%). On peut sur une carte 64 Mo de 3/4ans descendre à 2 secondes par vue, ce qui est au dela des besoins courants.

Pour les rotations, une image carrée de 1600 x 1600 suffit pour faire une rotation de 360° en 1280 x 960, cela passe en moins de 10 secondes sur une carte 32 Mo ancienne et en moins de 2 secondes pour une carte 64Mo de 3/4 ans.

Un Pan de 200px x 340px simultané à un zoom de 70% et à une rotation de 360° toujours pour une définition de 1280 min passe fluide sur une carte 32 Mo en 24 secondes et en 2 secondes sur une carte 64 Mo, c'est à dire bien au dela de ce qui est visuellement supportable.

On s'aperçoit qu'avec 2 500 000 pixels à traiter par vue, on passe sur toutes les machines pour tous les effets de base.
Ces chiffres peuvent être dépassés, mais il est nécessaire d'être prudent au delà si l'on veut être lu partout. Ce chiffre augmente à mesure qu'on vise comme minimum requis des machines plus performantes (4/5 millions de pixels pour une Radeon 7500/64Mo 3/4 ans d'age).

Nota : une carte à 32 Mo sur un portable récent est beaucoup plus performante en calcul qu'une ancienne carte 32 Mo (4/5 ans d'age). Parler uniquement de mémoire n'est pas un critère suffisant, mais il n'y a pas de quantification de la puissance de calcul fournie. C'est pourquoi j'indique l'age, ce qui donne une idée.

4 Laisser suffisamment de durée sur les 2 vues précédant une vue pour que les fichiers qu'elle utilise puissent être chargés (en gros 400ms par million de pixels devraient suffire).
Si les durées des 2 vues précédentes ne peuvent être allongées, certaines images de la vue peuvent être préchargées en les mettant sur la ou les vues précédentes avec opacité à 0. Ainsi elle seront en mémoire graphique à temps. Attention toutefois de ne pas surcharger la mémoire graphique.

5 Eviter de lancer des effets pendant les transitions, dans la mesure du possible, car les calculs pendant les transitions portent non plus sur 1 image mais sur 2 avec en plus les calculs pour la transition elle-même. Si en plus il faut faire des calculs sur des effets, le risque de dépasser les possibilités de calculs de bon nombre de machines est réel. Cela est difficilement chiffrable, mais facilement vérifiable.

6 Elément à prendre en compte : La pratique m'a montré qu'un même montage est plus fluide vu à des résolutions supérieures à sa résolution nominale qu'à des résolutions inférieures, ce qui à priori est contre toute logique.
Interrogé à ce sujet, et après enquête, Igor m'a confirmé que ce n'était pas anormal, les cartes graphiques, adaptées aux jeux sont optmisées pour l'agrandissement (textures et autre) et l'on profite de cette caractéristique aux résolutions supérieures.

7 Eléments pris en compte dans les calculs :
Les calculs pour une vue s'effectuent sur toutes les images dont l'opacité n'est pas nulle (PTE ne prend pas en compte les images à 0% d'opacité) et sur tous les rectangles, y compris ceux dont l'opacité est nulle (ce qui est ennuyeux). Les calculs semblent être proportionnels à la taille finale de l'image ou du rectangle, voir ce fil pour plus de détail

Au lieu de calculer l'image résultante des objets d'un même niveau puis de traiter le résultat selon les paramètres du niveau supérieur, chaque objet est traité individuellement en prenant en compte les paramètres de tous les objets de rang supérieur.
Cela alourdit nécessairement les calculs, si ce choix a été fait, il y a probablement une raison, mais qui, pour l'heure, m'échappe.
Lors des transitions, ce sont les même objets qui sont traités de la cette façon mais ce sont ceux des 2 vues.




J'essaierai de complèter ou d'affiner ces conseils, n'hésitez pas à faire préciser les points qui vous semblemt obscures en ouvrant un fil dans la rubrique "la V5 et vous".
Verrouillé

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 2 invités