Combien de générations en montage virtuel ?

En semaine... pas trop :lol:

A priori, oui. Mais j'aurai préféré faire le test avec ulead qui traite réellement le HDV. Le womble considère plutôt le HDV comme du MPEG en général et peu lui importe qu'il soit CBR ou VBR (même s'il respecte le type du fichier d'origine)

Prudence quand même. Un seul logiciel testé et sur un seul type de camescope.

Pas d'idées là dessus. Mais ce n'est pas lié aux GOP. Dans les essais, plus le nombre de coupures était important, plus le nombre de GOP a augmenté, sans que la durée ne change. De plus tous les fichiers faisaient exactement la même taille à l'octet près. Le débit moyen était donc identique.

 

Salut,
je voulais répondre à la question concernant l'équivalence entre RVB et YUV en indiquant un lien que j'ai mentionné ailleurs :

Chrominance - Wikipédia

L'approximation généralement utilisée est Y = 0,6 V + 0,3 R + 0,1 B

Je cite:
"De cette façon, le passage d'un système de couleur RGB à un système YUV peut être réprésenté au moyen d'une matrice, d'où le nom de « matriçage » donné à cette opération.
Ce système est bidirectionnel, ce qui permet, par l'opération inverse, de retrouver les signaux RGB pour les afficher à l'écran."

L'opération est totalement réversible. Pour ce qui est de l'écran, en général, la chrominance est codée sur 24 bits (chaque signal composantes étant codé sur huit bits), ce qui équivaut à... 16,7 millions de couleurs. Les algorithmes de compression agissent en amont, pas au niveau du périphérique de diffusion pour lequel YUV = RVB.
A+

Autre lien :
YUV - Wikipédia

 

Bonne explication, DJRI !

Il y a aussi … JPEG, M-JPEG, et MPEG … et puis DCT, Huffman, wavelets …
Du pain sur la planche !
Et, bien sûr, Wikipedia …

 

Tu as bien compris le principe, mais une petite phrase me chagrine :

"pas au niveau du périphérique de diffusion pour lequel YUV = RVB"

Le secteur 110 volts est totalement transformable en 220V et inversement, il y des prises 110v et des prises 220v qui, elles, ne sont pas interchangeables. En cas d'inversion, par erreur, les resultats peuvent être étonnants

De meme, YUV est convertible en RVB et inversement, mais sur un moniteur il y a des prises YUV et des prises RVB qui ne sont pas interchangeables.

Allez, je débranche un moniteur et je te poste une photo.

A+

 

la phrase
"L'approximation généralement utilisée est Y = 0,6 V + 0,3 R + 0,1 B"

contient neamoins l'affirmation que cette conversion se fait avec des pertes.
quelque soit le nombre de bits, l'operation qui consiste a diviser 1 par 3 et a multiplier le resultat par 3 donnera plus ou moins rapidement une valeur different de celle de depart.

avec la calculette de windows, il suffit de diviser 1 par 3, de copier le resultat, de faire la multiplication de ce resultat par 3 pour voir qu'il y a deja une erreur (0.99999999999 au lieu de 1)
ca peut explique cette tendance qu'on les codec DV a tirer une image vers le vert ou le bleu suite a une recompilation

 

Salut st65,
oui, bien sûr, les connectiques YUV et RGB ne sont pas compatibles "fiche à fiche", bien qu'elles soient toutes deux en composantes. Les branchements ne sont pas intercheangeables. L'important est de brancher sur l'une ou l'autre une liaison compatible.

Et si le moniteur "affiche" 16,7milliosns de couleurs (je mets des guillements car aucun pour l'instant n'aurait assez de pixels pour les afficher toutes simultanément !), c'est que chacune des trois couleurs RGB est codée à égalité sur huit bits, soit 24 bits par pixel....

Petite question qui me turlupine : l'ACER 3705 MGW dispose de 4 entrées/sorties peritel de deux types différents :
1) CVBS (entrée/sortie), S-video (entrée), RVB (entrée), audio (D/G)
2) CVBS (E/S), S-Video (Entrée), Audio (D/G)

Cela veut-il dire que les entrées peritel RVB acceptent aussi les signaux HD ? J'ai entendu dire le contraire sur un forum...Je reste dubitatif : qu'est-ce qui s'y opposerait ?
En revanche, les deux entées composantes en YPbPr/YCbYCr et Audio D/G acceptent la HD (comme indiqué sur la notice) ...
Il est vrai qu'Acer préconise l'utilisation des connexions composantes plutôt que Peritel...

Autre sortie intéressante, la sortie audio num SPDIF (2/4/6 canaux). Est-ce à dire qu'il y a une sortie en 5.1 ??

Autre particularité que j'ai omis de mentionner à propos de l'ACER : ses lecteurs de cartes multiformats en façade (Compact Flash, MMC, Memory Stick (dont "pro"), SD.
Pour les formats gérés, voir :

Acer - France - Produits

PS :Ah oui, pourquoi n'ai-je aucune image sur la TNT lorsque je choissi "test HD1" ou
"Test HD2" ? Quelqu'un les capte t-il déjà ?

A+

 

Non Giroubd,
cette formule n'était qu'un moyen mnémotechnique plus aisé à se remémorer que
Y = O,59 G + 0,29 R + 0,12 B (cela tombe juste)...
Regarde le ien, tout y est :
Chrominance - Wikipédia
ou/et
YUV - Wikipedia, the free encyclopedia
ou
YUV - Wikipedia, the free encyclopedia
(il esiste les mêmes articles en frenchy)
A+

 

giroudf,
Ce sont des circuits électroniques intégrés dédiés qui effectuent ces conversions en calcul matriciel …
D'où le nom de "matriçage" donné à cette conversion qui date des début de la tv couleurs …

Les valeurs approximatives ne sont là que pour en "donner une idée" et la calculette "Windows" ou n'importe quelle calculette à 1FS, ça va pour le minot de la matsup…
Même avec la "calculatrice" d' un potache, quand tu enchaînes 1 / 3 <=> X 3 <=> elle te renvoie 1 quand bien même elle ait affiché 0.333333333 après le premier =.
Ça calcule en base deux et en virgule flottante et il en faut un peu plus pour la berlurer.
Les conversions RGB < — > YUV ne sont pas des compressions et se font sans perte.

Oui, wikipedia est une bonne encyclopédie … coopérative…
Ici, au Repaire, notre excellent ami vsb a pondu un article tout aussi documenté… Restons Français, Suisses … ou, enfin Belges

 

je suis d'accord pour dire que la conversion YUV<-->RGB est mathematiquement (j'espere la plupart du temps ) correcte.
Elle peut se faire sans perte, pour autant qu'on considere une conversion pixel par pixel et sur un nombre suffisemment grand de bit.
Malheureusement, sur PC il est rarissime qu'on travaille en 4:4:4 et en 12 bits
la plupart du temp en 4:2:0 ou en 4:2:2. et en 8 bits
Ca veut dire que l'image RGB qui est recree a partir de l'image YUV est une decompression (certain pixels RGB sont recrees a partir d'une information couleur qui n'est pas la leur). Ce n'est pas la faute a la conversion YUV-->RGB, mais au fait qu'on passe d'un 4:2:0 a un 4:4:4
Ensuite le traitement RGB (effets, filtres) s'applique a chaques pixel.
puis la conversion RGB--->YUV est refaite et la si on on garde une image au pixel pres, c'est vrai que ce n'est pas important qu'elle soit en YUV ou en RGB.
Mais si on travaille dans un codec normal, cette conversion se fait aussi en comprimant le U et le V.donc je ne pense pas que la conversion YUV<-->RGB soit dissociable du calcul qui fait d'une image 4:4:4 une image 4:2:0 d'ou les pertes evoquees.

Faut toujours dissocier la theorie de la pratique.
Dans la theorie , la securite de la carte bleu etait incsassable.
dans la pratique et surement pour des raison d'economie, on a utilise des algos qui etaient bien inferieur et du coup , la protection de la carte bleue est devenue une passoire.
Le pauvre gars qui en a fait la demonstration et s'est retrouve en taule, pourrait vous le confirmer.
Donc j'ai tendance a croire que les gars qui programment des codecs et autres chips, si ils peuvent avoir 20% de performance en plus en arrondissant un peu les coins, ils se genent pas.

 

Bon, on progresse … la division par x ≠ 0 fonctionne, enfin "théoriquement" …
Bon, aussi, les problèmes pratiques soulevés par les décodages/encodages informatiques relèvent des paramètres : 8 bits, 4:2:0 qui sont effectivement des "compressions", mais pas de ceux de la conversion RGB<—>YUV, ni de la mise en œuvre d'un algorithme … simple.
Bon que des techniques d' accélération soient employées pour les codecs plus complexes comme ceux du MPEG et que les programmeurs y aient été plus ou moins efficaces, je pense aussi celà possible (d'où ma déception pour un certain codec) mais, ça n'a rien à voir ni avec "arrondir les coins", ni les mésaventures des utilisateurs de cartes bleues …

 

Oui Girould, mais franchement, un codage des composantes en huit bits, ça fait 16,7 millions de couleurs par pixels, ce qui me conduit à te poser deux ou trois questions :

1) Comment afficher 16,7 millions de couleurs sur un écran de 1080 x 1920 pixels, soit
2 073 600 pixels avec ma calculette Windows...

2) Ton écran est-il suffisamment bien étalloné pour rendre compte de toutes ces nuances ? Est-il parfaitement homogène en colorimétrie sur toute sa surface pour ne pas se planter sur la moindre nuance (déjà, une légère variation de l'angle de vision change tout)... Et même si tu restes immobile, ton angle de vision change d'un bord à un autre....

3) Ton oeil et ton cerveau sont-ils suffisamment aiguisés pour distinguer les moindres nuances ? J'avais lu quelque chose au sujet des peintres ou des tapissiers, qui eux-même ne sont pas assez "pointus"... Et puis, les erreurs de colorimétrie interviennent à tous niveaux ( de la balance des blancs et variations de lumière, au montage où faire de bons "raccords lumière ou couleurs" impose parfois des compromis), etc.

4) Fimer ou photographier un tableau posent des problèmes particuliers : la température de couleur de l'éclairage, les réactions d'une pellicule dans le domaine invisible (avec répercussions dans le domaine visible) sont quelques uns des facteurs qui en font un art difficile où la subjectivité, les imprévus jouent un rôle majeur. Lorsque tu es en lumière artificielle et que pénêtre de la lumière du jour, du bleu s'ajoute à la vidéo... De même que les néons, tous différents, provoquent surtout en photo des reflexions vertes avec des pellicules lumière du jour...

PS: je cherche une estimation du nombre de couleurs que l'homme peut distinguer, en vain. Mais voisi un lien (toujours cette encyclo, pas mal du tout:
Couleur - Wikipédia

Bref, tout cela pour dire que je ne cherche pas l'absolu dans ce domaine, ni même l'absolution...
A+

 

En fait meme si le nombre de couleurs total peut paraitre impressionant, il n'est pas si bon que ca.
Evidemment si tu decides de mettre un pixel de chaque couleur sur l'ecran, faudra un ecran sacrement grand. Mais maintenant, si tu decides de faire un joli degrade de bleu, tu te rends compte que 256 valeurs (8bits) c'est pas enorme.
C'est pour ca qu'on a besoin d'autant de couleurs.
Maintenant c'est clair que de toute facon avec une bonne compression 4:2:0 sur 8 bit en mpeg, si tu arrives meme a avoir 50 degardes de bleu sur ton ecran LCD , t'es deja vachement content.

 

Sur le codage informatique des couleurs:
Codage informatique des couleurs - Wikipédia

PS: Si tu fais un dégradé de bleu, et bien forcément, tu n'utiliseras pas que du bleu ! Mais aussi dans une certaine proportion de vert et de rouge (voir avec pointeur sur un nuancier de Photoshop, la composition de chaque couleur). Plus de huit bits sont utilisés dans le codage de tes bleus et tu as plus de 256 nuances, heureusement ! Sinon, on n'aurait que des bleus, rouges et verts... et pas 27,5 millions !
A+

 

Le terme "composantes" (component) est réservé à la connection YUV.

Scart n'est pas compatible HDTV, c'est du RVB 576i
De la meme façon il existe des ecrans YUV576 et non YUV720 ou YUV1080.
En regle générale, la connectique HDTV analogique est YUV (ou YPrPb, Y B-Y R-Y, etc...)

A+

 

En français, utiliser le terme "composantes" est aussi correct en RVB qu'en Y (R-Y) (B-Y).
U et V sont des vecteurs.
Comme d'habitude, les mots sont détournés de leur vraie signification.