Bienvenue invité ( Connexion | Inscription )
28/03/2008 09:48
Message
#41
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
mise à jour 3.5 : correction d'un bug sur le zoom (bug apparu lors de la création des paramètres "image" et "cadre")
|
|
|
04/04/2008 20:57
Message
#42
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Mise à jour 3.6 dans laquelle il y a maintenant l'option Pixels="pc" ou Pixels="tv" (ça va plaire à micjul !)
Exemples simples : Source.CropResizeBorder(full=true,pixels="pc") donne ceci (IMG:http://img291.imageshack.us/img291/121/imagepcfk3.th.jpg) Source.CropResizeBorder(full=true,pixels="tv") donne ceci (IMG:http://img292.imageshack.us/img292/9931/imagetvhv7.th.jpg) |
|
|
04/04/2008 22:50
Message
#43
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Dans la prochaine version, il y aura aussi Pixels="dvd" (pour encoder en mpeg)
Voir la discussion (avec Jack...) sur http://forum.surdvd.com/viewtopic.php?p=14...84c29827ac6d5c4 si vous n'avez pas mal à la tête... (IMG:http://forum.ripp-it.com/style_emoticons/default/aga.gif) Ce message a été modifié par leon1789 - 04/04/2008 22:53. |
|
|
04/04/2008 22:54
Message
#44
|
|
Producteur Groupe : Super Modérateurs Messages : 6.326 Inscrit : 19/03/2004 Lieu : Un chouette endroit Membre no 1.888 |
Mince j'y fais une apparition (IMG:http://forum.ripp-it.com/style_emoticons/default/aga.gif) .. tu déterres (IMG:http://forum.ripp-it.com/style_emoticons/default/aga.gif)
|
|
|
04/04/2008 23:37
Message
#45
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
<<Moi aussi j'ai fini mon tube...>> dit la souris casquée !
(IMG:http://forum.ripp-it.com/style_emoticons/default/yahoo1.gif) une discussion déterrée (par google !) mais qui finalement permet à Jack... de conclure clairement (à la fin !) quant aux pixels pc, tv,dvd. Je lui dis merci ! |
|
|
07/04/2008 08:28
Message
#46
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Il est assez facile de comprendre pourquoi ri4m déforme l'image lors d'un encodage DVD :
imaginons un DVD 16/9 pal 720x576. La première chose que ri4m execute sur la vidéo est un redimentionnement en 720x400. Or le format 16/9 est dans l'absolu 720x405. Donc ri4m déforme l'image DVD 16/9 de 1.23 % (car 400 = 405 - 1.23% ) Regardons maintenant pourquoi ri4m perd une partie de l'image lors du crop. Après le resize, ri4m fait un rognage des bandes noires de telle sorte à tomber sur une résolution finale multiple de 16. Or les nombres de lignes et de colonnes noires d'une image sont rarement multiples de 16, donc ri4m va emputer l'image... Si vous avez 4 lignes noires, ri4m gratte 16-4 = 12 lignes de l'images en plus ! (et la résolution finale est 720x384, car 400-16 = 384). Après quelques mesures sur une douzaine de DVD, on arrive à cette conclusion : Après crop, ri4m perd en moyenne 2.3 % de l'image. Sur les douze vidéos testées, seulement deux fois ri4m n'a pas rogné l'image. Pour comparaison, sur les mêmes DVD : (avec bandes noires) simple resize de Riam en 720x400 -> perte d'image 0%, et déformation de 1.23 % CropResizeBorder(720,400) -> perte d'image 0%, et déformation de 0.1 % en moyenne (sans bandes noires) resize+crop de Riam -> perte d'image 2.3% en moyenne, et déformation de 1.23 % CropResizeBorder(bords=false) -> en moyennes, perte d'image 3.8 %, déformation 0.1%, CropResizeBorder(full=true) -> perte d'image 0%, et déformation de 0.8 % en moyenne Ce message a été modifié par leon1789 - 07/04/2008 15:28. |
|
|
24/05/2009 10:11
Message
#47
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Bonjour,
Voici un petit jeu de "resize" d'image. On se donne des images de DVD PAL 16/9 dont les formats réels sont 1.77 (=16/9) , ou 1.85 , ou 2.35 ou 2.39 : ce sont les formats les plus courants sur DVD. (Ici, je ne parle pas des DVD 4/3.) Le format réel de chaque image est inscrit sur l'image en question, et j'y ai placé aussi des cercles pour une analyse visuelle. J'ai aussi laissé les traces des calculs pour avoir des résultats numériques. Voici les images DVD : Le but du jeu est de recadrer ces images en résolution 720x400 (pour compatibilité avec le matos de SG1 !), sans perte d'image mais avec des bandes noires permises. On voit clairement que les cercles sont complètement déformés sur les images DVD initiales : cela est normal car l'encodage sur DVD PAL est anamorphique (720x576). Le but est justement de redimensionner ces images pour obtenir des vrais cercles ! Je compare ici deux méthodes : le simple Resize(720,400) et CropResizeBorder(720,400) Résultats de Resize(720,400) Le premier resize(720,400) est simulé par CropResizeBorder(720,400,full=true) pour obtenir numériquement l'unique information importante : quel que soit le format réel de l'image (1.77, 1.85, 2.35 ou 2.39), il y a une déformation constante de plus de 1.2 %. En fait l'image redimensionnée est maintenant légèrement tassée verticalement. Tout ceci est normal car le ratio 720/400 (résolution finale désirée par SG1) est légèrement supérieur à 16/9 (format du DVD). Résultats de CropResizeBorder(720,400) Ici, il y a étonnamment 3 petites bandes noires (!), ce qui est assez moche je trouve. Mais la déformation très faible est de 0.06 % (!!) car l'image réelle est de résolution 708x398 (il y a donc resize dans les deux dimensions). Les bandes noires sont de 6 lignes à gauche et à droite, et de 2 lignes en haut. Ici, la déformation est de 0.12 % (dix fois moins qu'avec le resize(720,400) habituel) car l'image réelle est de résolution 720x390. Enfin, les bandes noires sont de 6 lignes en haut et 4 lignes en bas. Ici, la déformation est de 0.18 % car l'image réelle est de résolution 720x306. Enfin, les bandes noires sont de 48 lignes en haut et 46 lignes en bas. Ici, la déformation est de 0.3 % (mais quatre fois moins qu'avec le resize habituel) car l'image réelle est de résolution 720x300. Enfin, les bandes noires sont de 50 lignes en haut et en bas. Conclusion sur les méthodes : Grâce à l'utilisation de redimensionnements différents et plus adaptés, CropResizeBorder conserve bien mieux les formats réels des images, et cela dans tous les cas de figure. Ce n'est pas étonnant vu que ce script a été développé pour (IMG:style_emoticons/default/rolleyes.gif) ! Seul bémol, c'est le cas où CropResizeBorder se permet de placer 3 bandes noires (dans le but de coller parfaitement au format 1.77) : les 2 lignes en haut de l'image sont petites mais assez choquantes... Je vais regardé ça, ajouter une option si je peux,... Pour terminer, voici ce qu'on pourrait réaliser "à la main" en combinant un Resize puis un Crop (pour couper) ou un AddBorder (pour ajouter des bords noirs) : -- Pour l'image au ratio 1.77 (et de manière générale < 1.8 ), on enchaine les opérations Resize(712,400) puis AddBorders(4,0,4,0) : ce qui donne une déformation de 0.125 % (dix fois moins qu'un simple Resize(720,400)). Remarquer qu'il y a redimensionnement dans les deux dimensions (de 720x576 à 712x400) -- Pour les images aux ratios 1.85 , 2.35 , 2.39 (et de manière générale > 1.8 ), on enchaine les opérations Resize(720,404) puis Crop(0,2,0,-2) : ce qui donne une déformation de 0.25 % (cinq fois moins qu'un simple Resize(720,400)) Ce message a été modifié par leon1789 - 24/05/2009 13:06. |
|
|
24/05/2009 17:32
Message
#48
|
|
Producteur Groupe : Rédacteurs Messages : 6.285 Inscrit : 08/10/2004 Lieu : Un coin perdu du Gers (32) Membre no 4.657 |
Bonjour,
Bravo, Léon, je vais me pencher sur ces nouvelles données... Je n'ai pas passé en revue tous les messages de ce post, et peut-^tre que ça s'y trouve quelque part, mais si ça n'est pas le cas, tu devrais donner un exemple concret de l'intégration de ton script dans le script AVS de Ri4m... Citation Tout ceci est normal car le ratio 720/400 (résolution finale désirée par SG1) est légèrement supérieur à 16/9 (format du DVD). Ah bon ? C'est quoi la correspondance exacte ? 720 x 384 ? @+ Ce message a été modifié par SG1 - 24/05/2009 17:36. |
|
|
24/05/2009 18:45
Message
#49
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Je n'ai pas passé en revue tous les messages de ce post, et peut-^tre que ça s'y trouve quelque part, mais si ça n'est pas le cas, tu devrais donner un exemple concret de l'intégration de ton script dans le script AVS de Ri4m... En fait, ça demande deux manipulations : -- la première, qu'il faut réaliser une fois pour toute, est de placer dans le répertoire "C:\Program Files\AviSynth 2.5\Plugins\" le script CropResizeBorder.avs (téléchargeable ici http://forum.ripp-it.com/index.php?s=&...st&p=255987 ) -- la seconde est d'éditer le script de Ri4m, de supprimer toute ligne contenant les instructions Crop ou AddBorders, et de remplacer la ligne Video=BilinearResize(Video, Largeur, Hauteur) par Video=CropResizeBorder(Video, Largeur, Hauteur) par exemple. Citation Tout ceci est normal car le ratio 720/400 (résolution finale désirée par SG1) est légèrement supérieur à 16/9 (format du DVD). Ah bon ? C'est quoi la correspondance exacte ? 720 x 384 ? Normalement, il faudrait redimensionner l'image "brute" d'un DVD PAL 16/9 en quelque chose comme 720x404 ou 712x400. Malheureusement, ces dimensions ne sont pas multiples de 16, donc il faut : - soit rogner un bout de noir pour passer de 720x404 en 720x400 et cela est faisable dans le cas des vidéos 1.85 et + ; - soit ajouter des bandes noires sur les cotés pour passer de 712x400 à 720x400 et cela est faisable dans le cas des vidéos 1.77 et -. Tu es ok ? Ce message a été modifié par leon1789 - 24/05/2009 19:38. |
|
|
24/05/2009 22:01
Message
#50
|
|
Admin Groupe : Admin Messages : 32.192 Inscrit : 12/05/2003 Lieu : DivX ou XviD Membre no 2 |
Il me semble que le 1.77777 est obtenu (et à cause de l'anamorphose) en faisant 1024/576.
|
|
|
25/05/2009 14:24
Message
#51
|
|
Producteur Groupe : Rédacteurs Messages : 6.285 Inscrit : 08/10/2004 Lieu : Un coin perdu du Gers (32) Membre no 4.657 |
Bonjour,
Citation Normalement, il faudrait redimensionner l'image "brute" d'un DVD PAL 16/9 en quelque chose comme 720x404 ou 712x400. 720x404, c'est la dimension donnée par Ri4m si l'on ne coche pas « Forcer le snap à 16x 16 » J'ai déjà encodé (par erreur) dans cette dimension et je dois reconnaitre aue je n'avais pas eu de problème de lecture... donc je ne m'étais pas affolé outre mesure... Citation Tu es ok ? Yes Sir, I am OK ! @+ |
|
|
25/05/2009 17:28
Message
#52
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Il me semble que le 1.77777 est obtenu (et à cause de l'anamorphose) en faisant 1024/576. Oui, tu as raison, mais là, on commence à faire de la HD (> 720x576) et je crainds l'incompatibilité avec le matos de SG1 (IMG:style_emoticons/default/interro1.gif) Mais la HD, c'est justement prévu dans CropResizeBorder ! (IMG:style_emoticons/default/maya.gif) Si Source désigne l'image 720x576 au format réel 1.77, voici que l'on obtient avec l'instruction CropResizeBorder(Source, HD=true), sans préciser de dimension, ... Résultat : perte 0% , déformation 0% (normal, il s'agit en réalité d'un simple Resize comme le signale Rol) Ce message a été modifié par leon1789 - 25/05/2009 17:36. |
|
|
25/05/2009 17:32
Message
#53
|
|
Admin Groupe : Admin Messages : 32.192 Inscrit : 12/05/2003 Lieu : DivX ou XviD Membre no 2 |
Ah vi intéressant ça (IMG:style_emoticons/default/cling1.gif)
|
|
|
25/05/2009 17:42
Message
#54
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Bonjour, Citation Normalement, il faudrait redimensionner l'image "brute" d'un DVD PAL 16/9 en quelque chose comme 720x404 ou 712x400. 720x404, c'est la dimension donnée par Ri4m si l'on ne coche pas « Forcer le snap à 16x 16 » J'ai déjà encodé (par erreur) dans cette dimension et je dois reconnaitre aue je n'avais pas eu de problème de lecture... donc je ne m'étais pas affolé outre mesure... On peut (avec des versions pas trop anciennes de divx) effectivement encoder avec des résolutions non multiples de 16 (multiples de 4 seulement)... Mais c'est risqué question compatibilité avec les fitres AVS (pendant l'encodage), avec les lecteurs (pour le décodage), et c'est aussi très dommageable en qualité : voir http://forum.ripp-it.com/Comment-perdre-de...58.html&hl= (IMG:style_emoticons/default/glass.gif) --> un mauvais choix de résolution peut entrainer une perte de qualité équivalente à une diminution de bitrate de 10 à 30% Ce message a été modifié par leon1789 - 25/05/2009 17:44. |
|
|
01/10/2009 17:48
Message
#55
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Version 3.7
Ca faisait longtemps que je n'avais pas testé les méthodes de redimensionnement. Après plusieurs tests croisés sur les algorithmes de redimensionnement, voici le classement auquel j'arrive Agrandissement : Lanczos4 ~ Lanczos > spline36 > bicubic(0,0.7) > spline16 > bicubic(0,0.5) >>> Gauss(70) > bicubic(0.33,0.33) > Gauss(100) > Gauss(40) > bilinear réduction : Lanczos4 ~ Lanczos > spline36 ~ bicubic(0,0.7) >> Gauss(100) ~ spline16 > bicubic(0,0.5) > Gauss(70) > bicubic(0.33,0.33) >> bilinear > Gauss(40) Ce message a été modifié par leon1789 - 02/10/2009 16:57. |
|
|
02/10/2009 17:55
Message
#56
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Autre classement, mais cette fois en terme de compressibilité (du plus compressible au moins) :
Agrandissement : bilinear > Gauss(40) > bicubic(0.33,0.33) >> bicubic(0,0.5) > spline16 > bicubic(0,0.7) ~ spline36 > Lanczos > Lanczos4 > Gauss(70) >> Gauss(100) Réduction : bilinear > bicubic(0.33,0.33) > Gauss(40) >> Gauss(70) > bicubic(0,0.5) > bicubic(0,0.7) ~ spline36 > spline16 > Gauss(100) > Lanczos4 > Lanczos |
|
|
03/10/2009 14:52
Message
#57
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
Classement de plusieurs bicubicResize en terme de qualité (évaluation SSIM à partir d'images DVD).
Agrandissement : bicubic(0.0,0.8 ) > bicubic(0.0,0.7) ~ bicubic(0.0,0.9) > bicubic(0.0,1.0) > bicubic(0.1,0.8 ) > bicubic(0.1,0.7) ~ bicubic(0.1,0.9) > bicubic(0.0,1.1) > bicubic(0.2,0.8 ) ~ bicubic(0.2,0.9) > bicubic(0.2,0.7) Réduction : bicubic(0.0,0.8 ) ~ bicubic(0.0,0.9) > bicubic(0.0,0.7) ~ bicubic(0.0,1.0) > bicubic(0.0,1.1) > bicubic(0.1,0.9) > bicubic(0.1,0.8 ) > bicubic(0.1,0.7) > bicubic(0.2,0.9) > bicubic(0.2,0.8 ) > bicubic(0.2,0.7) Ce message a été modifié par leon1789 - 03/10/2009 15:00. |
|
|
09/06/2010 14:26
Message
#58
|
|
Ouvreur Groupe : Membres Messages : 2 Inscrit : 09/06/2010 Membre no 54.703 |
Bonjour,
Le lien pour télécharger CropResizeBorder 3.7 a l'air mort ("fin de l'archive corrompue"). Est il possible de donner un nouveau lien pour cet outil ? Merci d'avance. |
|
|
09/06/2010 19:38
Message
#59
|
|
Producteur Groupe : Rédacteurs Messages : 6.285 Inscrit : 08/10/2004 Lieu : Un coin perdu du Gers (32) Membre no 4.657 |
Bonjour,
Bonjour, Le lien pour télécharger CropResizeBorder 3.7 a l'air mort ("fin de l'archive corrompue"). Est il possible de donner un nouveau lien pour cet outil ? Merci d'avance. Je viens de tenter un téléchargement (le lien dans le tout premier message de ce post) sans problème... Extraction correcte avec le ZIP de Windows XP et extraction également correcte avec Winrar ! Refais un téléchargement, il y a peut-être eu un problème à ce moment là... @+ |
|
|
12/06/2010 11:02
Message
#60
|
|
Ouvreur Groupe : Membres Messages : 2 Inscrit : 09/06/2010 Membre no 54.703 |
Il y avait un problème, j'ai effectivement pu le télécharger, merci !
|
|
|
Discussions similaires à la discussion "CropResizeBorder 3.7 - Script vidéo AviSynth"
Sujet | Réponses |
---|---|
Vidéo sur Ipod | 5 |
vidéo accélérée | 8 |
avisynth et Windows 7 x64 | 3 |
vidéo sur psp | 1 |
videos pour ipod | 1 |
Avisynth Multithread | 5 |
Vidéo Sans Son PS3 | 0 |
Scripte avisyth mrestore | 19 |
Video qui saccade | 1 |
Avisynth open failure | 16 |
Sujets récents
Nous sommes le : 06/05/2024 02:24 |