répresenter un signal de luminance via un fichier wav

Différents standards (PAL, SECAM, NTSC), histoire et évolution de la TV analogique...

Re: répresenter un signal de luminance via un fichier wav

Messagepar Marc2 » 29 Juin 2017 08:09

mutantape a écrit:Au passage, en y réfléchissant, je voyais un petit paradoxe apparent lié à la théorie de l'échantillonnage:
supposons que j'échantillonne la porteuse de façon exactement synchrone avec un échantillon correspondant au sommet positif de la sinusoide, et un au sommet négatif.
Comme le signal modulant est représenté par les crêtes de la porteuse, on peut l'extraire exactement à partir de cette information.
Or si ma porteuse fait 100 MHZ et le signal modulant 6 MHz, la fréquence maximale du signal modulé sera 106 MHz, qu'il faudrait normalement échantillonner à au moins 212 MHz.
Mais avec mes deux échantillons par période je ne suis qu'à 200 MHz, et pourtant il semble que je n'aie pas perdu d'information.

En effet, parce que cette information est aussi située entre 94 et 100 MHz.
Moduler à une fréquence égale à la moitié de la fréquence d'échantillonnage, c'est fort pratique car il suffit de multiplier les échantillons alternativement par +1 et -1. Lors de la conversion numérique -> analogique (pour être plus exact, lors du passage du temps discret au temps continu), le phénomène de réplication* du spectre fera apparaître les deux bandes latérales. Avec toutefois une distorsion d'amplitude due à la multiplication par un sinus cardinal (dont le premier passage à 0 est à la fréquence d'échantillonnage,et qui à la moitié fait perdre environ 4 dB de mémoire).

* c'est un peu comme le repliement qui se produit lors de l'échantillonnage, mais en sens inverse.
Avatar de l’utilisateur
Marc2
Etalon
Etalon
 
Messages: 1818
Inscription: 30 Oct 2007 00:45

Re: répresenter un signal de luminance via un fichier wav

Messagepar mutantape » 30 Juin 2017 00:19

En fait le sinus cardinal intervient au moins de deux façons dans la théorie.

Pour une reconstitution parfaite du signal numérisé, il faudrait multiplier en analogique chaque échantillon par un sinus cardinal dont le pic principal est centré sur lui et faire la somme de tout l'ensemble. La valeur obtenue à l'emplacement d'un point du signal serait ainsi la contribution de ce pic principal,et aussi des ondelettes des pics secondaires, tertiaires, etc des échantillons situés avant lui dans le passé, mais également après lui dans le futur (filtre anticipateur). Théoriquement possible sur un fichier enregistré, mais difficile sur une émission en direct...
Dans ce cas il n'y a aucune distorsion on retrouve exactement le signal analogique originel. C'est la réalisation temporelle d'un filtre rectangulaire parfait (en fréquence) qui ne conserve qu'une des copies du spectre et élimine les répliques.

En pratique pour éviter la difficulté du filtre anticipateur et la complexité des circuits résultants même en différé, on se contente de maintenir la valeur d'un échantillon (théoriquement instantané et infiniment court) jusqu'à l'arrivée de l'échantillon suivant (bloqueur d'ordre zéro), ce qui reconstitue un signal continu, mais en escaliers. Ceci introduit une distorsion du signal par rapport à la reconstitution parfaite, mais on peut calculer que cette dernière est complètement décrite par un affaiblissement des hautes fréquences suivant une courbe qui se trouve également être un sinus cardinal ( la partie utile affectée se trouvant dans le lobe principal et n'atteignant pas le premier passage à zéro); Il est donc en principe possible de précompenser dans le domaine numérique avant conversion. Et comme la courbe en sinus cardinal, contrairement au filtre rectangulaire ne coupe pas totalement les répliques, mais les atténue progressivement avec les pics successifs de plus en plus faibles, il faut rajouter un filtre passe bas analogique en sortie après le DAC pour éliminer ce surplus.

Mais dans le fonctionnement recherché ici on restera toujours dans le domaine échantillonné numérique (flux créé et relu entièrement en interne dans les circuits numériques du PC) , on ne sera donc pas concerné par ces soucis. Encore faut-il que la représentation numérique contienne bien toute l'information du signal réel sous une forme simple (pas de repliement) pour pouvoir utiliser dessus des filtres réalistes par rapport à une implémentation physique.
mutantape
Grenouille
Grenouille
 
Messages: 424
Inscription: 05 Mai 2008 01:16

Re: répresenter un signal de luminance via un fichier wav

Messagepar Mannix54 » 30 Juin 2017 21:00

pour une minute de vidéo noir et blanc analogique en définition standard 625 lignes le fichier binaire représentant ce signal modulé en AM aura quelle taille sur le disque dur ?
je crains une taille énorme,

le périphérique hackRF one permettant de diffuser ce fichier binaire via gnu radio n'est pas donné :

https://www.passion-radio.com/fr/emette ... dr-75.html

je me demande s'il existe le même type de boitier mais sans la partie "puce radio", car dans notre cas on a juste besoin d'une sortie vidéo-composite filaire, ça couterait peut-être moins cher à fabriquer, un simple composant qui ferait la conversion numérique vers analogique, en entrée : un port USB pour recevoir le signal numérique, et en sortie une prise RCA vidéo-composite, entre les deux : peut-être un FPGA, une puce programmable en langage VHDL ?

à ne pas confondre avec les boîtiers convertisseurs chinois "HDMI vers vidéo composite", ici on cherche plutôt à fabriquer un signal vidéo analogique depuis un PC ( en mettant ce qu'on veut dedans, norme 819 lignes, 625 lignes, pal, secam, gestion des lignes VBI ), et à le transmettre vers un récepteur TV ( sans forcément passer par une émission radio, ça peut être le mode filaire vidéo-composite RCA )
Avatar de l’utilisateur
Mannix54
Etalon
Etalon
 
Messages: 1224
Inscription: 18 Oct 2007 09:21

Re: répresenter un signal de luminance via un fichier wav

Messagepar marceljack » 30 Juin 2017 22:16

Mannix54 a écrit:pour une minute de vidéo noir et blanc analogique en définition standard 625 lignes le fichier binaire représentant ce signal modulé en AM aura quelle taille sur le disque dur ?
je crains une taille énorme...
Ce n'est pas pour rien qu'on a inventé la compression MPEG :wink:
Modérateur des forums tvnt.net

Installation TNT: Paris: VTU50 collective 21-60 / Royan: Lambda 9 + préampli
TV HD: Thomson FE9234B, Philips 39PFL3807, Acer AT2356,
PC: Pinnacle PCTV310i & 310e, Technaxx DVB-S3, Techgear Diversity Stick, Terratec TStick+
marceljack
Brigades du Tigre
Brigades du Tigre
 
Messages: 22777
Inscription: 06 Oct 2005 18:59
Localisation: 75019 PARIS

Re: répresenter un signal de luminance via un fichier wav

Messagepar Mannix54 » 30 Juin 2017 22:23

ceci dit en zippant le fichier binaire on devrait pouvoir réduire la taille, un peu comme avec le codec flac ( pour l'audio ) et huffyuv pour la vidéo, une compression non destructive
Avatar de l’utilisateur
Mannix54
Etalon
Etalon
 
Messages: 1224
Inscription: 18 Oct 2007 09:21

Re: répresenter un signal de luminance via un fichier wav

Messagepar mutantape » 01 Juil 2017 12:34

En reprenant les calculs faits précédemment pour le signal modulé complet, à 8 Mo par image et 25 i/s il te faudra un débit de 200 Mo/s, soit 12 Go par minute. Pour le débit, je ne suis pas sûr que la liaison USB suive. En fait c'est même pire que cela puisque pour éviter le repliement en intercalant des zéros entre chaque échantillon du fichier, on doublerait ce débit à 400 Mo/s.

Mais bon de toutes façons c'est incompatible avec le fonctionnement de la carte qui va plutôt attendre un signal numérisé en bande de base qu'elle tranposera ensuite à l'endroit désiré du spectre après conversion en analogique.

Concernant la taille du fichier, si tu ne stockes que la vidéo en bande de base, tu devrais pouvoir te rapprocher des débits du CCIR 601 à 162 Mbps soit 20,25 Mo/s ou 1,2 Go par mn environ. En noir et blanc en échantillonnant à 13.5 MHz, ça descendrait à 13.5 Mo/s ou 810 Mo par minute.

Evidemment si tu veux seulement transmettre une image fixe, il te suffit de stocker cette image une fois et de la répéter indéfiniment, et là ton fichier peut se réduire à 8Mo même sans compression, et encore beaucoup moins en bande de base, puisqu'il ne resterait plus que 720x576 echantillons soit 415 Ko ou un peu plus si on inclut les signaux de synchro.

En général on utilise des compressions sans pertes spécialisées pour les fichiers multimédia, plus efficaces que du zip qui y verra des données aléatoires.

On voit qu'on pourrait factoriser les impulsions de synchro qui se répètent de façon identique, ou les synthétiser à la lecture. Il y a le codage différentiel qui tient compte du fait qu'un signal réel va évoluer progressivement, que la différence d'un échantillon à l'autre est faible et peut être codée sur peu de bits. Puis le codage prédictif qui anticipe la valeur des échantillons en fonction du comportement passé et ne conserve que l'erreur de prédiction faible, si on a prédit correctement, et donc encodable sur peu de bits.

Mais le plus efficace est sûrement de prendre un utilitaire de compression image ou vidéo numérique sans pertes tout fait sur le net et de régénerer le signal "analogique" complet en temps réél à partir de cela avant de l'envoyer à la carte. On peut espérer une compression de deux à 3 par rapport aux échantillons numériques bruts de caméra. En considérant juste des echantillons 8 bits numériques noir et blanc, tu aurais un débit caméra de 720x576x25 =10.37 Mo/s soit 622 Mo par minute, qui pourrait se reduire peut être à 210 ou 250 Mo par compression sans pertes.

Et si on admet une compression avec pertes, alors là on retombe sur les tailles de fichier multimédia classiques.

Dans tous ces cas il faudrait un programme plus ou moins complexe travaillant en temps réel entre le fichier compressé et la liaison vers la carte.
mutantape
Grenouille
Grenouille
 
Messages: 424
Inscription: 05 Mai 2008 01:16

Re: répresenter un signal de luminance via un fichier wav

Messagepar Dominiak » 02 Sep 2018 22:57

Où en est le projet ? :)
Adhérent Radiofil, n°5933 depuis 12/2011.
OS: Linux Mint 64 Mate
Avatar de l’utilisateur
Dominiak
Etalon
Etalon
 
Messages: 1244
Inscription: 05 Déc 2009 03:54
Localisation: Varennes/Seine (77130)

Re: répresenter un signal de luminance via un fichier wav

Messagepar Mannix54 » 05 Sep 2018 00:56

projet en mode standby, mais je le garde sous le coude :mrgreen:,

pendant ce temps-là j'ai travaillé sur le rendu pal dans cryptimage, notamment l'ajout du mode "pal composite" et du mode "transcode", disponible dans cette version bêta 1.4.22 :
http://cryptimage.vot.pl/software/crypt ... 2_beta.exe
ou la version jar : http://cryptimage.vot.pl/software/crypt ... 1.4.22.zip
Avatar de l’utilisateur
Mannix54
Etalon
Etalon
 
Messages: 1224
Inscription: 18 Oct 2007 09:21

Re: répresenter un signal de luminance via un fichier wav

Messagepar Dominiak » 18 Oct 2019 10:51

Gimp propose une chose intéressante:
La possibilité d’enregistrer les images en mode "données brutes non-compressées" (*.*data), cela évite d’enregistrer en <*.*bmp> ou <*.*tiff>
L'ouverture d'un tel fichier avec un éditeur hexa montre clairement l'absence d'en-tête, puisque les données sont... brutes, les valeurs RVB de chaque pixel.
Cela pourrait être intéressant d'exploiter ce mode.
Adhérent Radiofil, n°5933 depuis 12/2011.
OS: Linux Mint 64 Mate
Avatar de l’utilisateur
Dominiak
Etalon
Etalon
 
Messages: 1244
Inscription: 05 Déc 2009 03:54
Localisation: Varennes/Seine (77130)

Re: répresenter un signal de luminance via un fichier wav

Messagepar Mannix54 » 18 Oct 2019 14:47

Si le but est d'ouvrir l'image avec un programme personnel alors tu peux sauvegarder l'image dans n'importe quel format (jpeg, png), car la plupart des langages informatiques ont des bibliothèques permettant d'ouvrir des fichiers images pour en extraire les valeurs RVB.

Ils ont aussi des bibliothèques pour créer des fichiers wav, on pourrait donc mettre ces valeurs RVB sous forme de fichier wav.
Avatar de l’utilisateur
Mannix54
Etalon
Etalon
 
Messages: 1224
Inscription: 18 Oct 2007 09:21