compression d'images par FPGA

Bonjour,
Je souhaite effectuer une compression d'image par FPGA. Ces images issues de la sortie VGA de mon unité centrale, ont préalablement été converties au format YCbCr puis numérisées. Je souhaite dorénavant comprésser un maximum chacun de mes signaux Y,Cb et Cr afin de les transmettre. A noter que d'une image à l'autre, je ne transmet que les portions modifiées. Je suis en train de me documenter sur la compression LZW, mais cette compression est elle avantageuse pour un tel système? Quelqu'un connait il les caractéristiques des compressions par FPGA? Quelqu'un pourrait-il me renseigner sur les avantages ou inconvénients des différents algorithmes de compression, plus particulièrement pour un tel système?
Merci d'avance pour vos réponses.

 

Pour moi un FPGA c'est un Field Programmable Gate Array, c'est à dire un composant électronique numérique programmable (générallement en VHDL ou Verilog), dont les plus connus sont de marque Altera, Xilinx...

Jusqu'à il y a deux ans, ce fut mon métier de concevoir des circuits électroniques utilisant des FPGA et de "programmer" ces composants.

Donc ou bien ce sigle signifie également autre chose, dans quel cas veuillez ignorer ma remarque de rigolo-qui-roule-des-mécaniques-avec-ses-composants-à-deux-balles, ou bien tu cherches des circuits, algo, code etc. pour effectuer cet encodage sur un FPGA... Dans ce cas ce n'est pas - je pense - le meilleur forum pour ça...

Jibier

 

Bon, j'ai du mal à tout comprendre :

soit je suis optu soit tu t'exprimes bizarrement

vu t'as façon de parler ( et ta méconnaissance des composantes analogique vidéo) tu viens du domaine de l'informatique, non ?

bref, en voyant tes autres posts (d'ailleurs tu aurais pu t'abstenir de poster 4/5 x la même question sur le repaire !)

Bref je récapitule :

tu as converti en YUV ton signal RVB de ton ordi (en utilisant ta sortie VGA) via un scan converteur, puis tu dis que que tu l'as numérisé...mais sur quoi ?

car l'YUV n'est en fait utilisé que pour des magnétoscope VIDÉO analogique !

utiliser l'YUV pour connecter sur un magnéto numérique, c'est dommage !

Maintenant tu nous parles de la compression image en LZW : saches que les fichiers images TIF et GIF en sont aussi !

bref tu veux créer une suite d'image compressée informatiquement d'après ......tes images venant de ton ordi ???

là je comprends pas ???? (et surtout je comprends pas la méthode d'utiliser un scan-converter RVB-YUV, numériser puis re-compresser informatiquement)

J'ai pas du tout suivre, ou il y a un truc que tu as du oublié de nous dire

bref, pour moi quand j'ai des images sur mon ordi si mon but c'est de les animés je ne les convertis pas en vidéo pour les recompresser ensuite....

le mieux serait de nous décrire complètement ta méthode et surtout nous dire ce que tu veux faire :

de la vidéo, de l'image, les 2, pour quoi transférer en YUV, pourquoi compresser en LZW....bref que de mystère

 

Je suppose que tu utilises la sortie de ton PC à des fins de test uniquement, sinon ça n'a aucune utilité comme le fait remarquer nono44.

Pour la compression vidéo, la solution la plus appropriée est le MPEG-4, notamment le H264 qui est encore supérieur en termes de compression au format DivX. Maintenant, ces algorithmes demandent beaucoup de connaissances que tu n'as pas forcément, et beaucoup de temps pour les programmer. De plus, si tu veux les implémenter sur un FPGA, il va te falloir un bon paquet de portes, possiblement plusieurs millions.

Le LZW, comme n'importe quel autre algorithme de compression par dictionnaire, correspond à une compression binaire. Le problème de ta chaine, c'est le passage par l'analogique qui va introduire inéluctablement du bruit dans le signal que tu voudras compresser. LZW va chercher des redondances dans ton image, par exemple N pixels de même couleur, et va ensuite les regrouper ; une version plus simple que LZW serait d'ailleurs un RLE (run length encoding).

Bref, à cause du bruit généré par le passage en analogique, l'algo risque de ne pas être capable de trouver de redondance et donc ne comprimera que faiblement. Tu peux compenser le problème du bruit par un filtrage (un préprocessing).

Si ton projet n'est pas urgent, intéresse toi d'abord à la compression JPEG, puis au MPEG.

 

Une solution serait d'utiliser un processeur embarqué sur un FPGA. Ca te permet d'embarqué sur le même composant les blocs de codage ligne, et le proc qui s'occupe de la compression trame. Maintenant tout dépend des choix de compression et des débits des flux de données en jeu. J'ai bossé avec les proc Nios d'Altera, et on leur faisait faire des FFT 1024 très rapides, alors qu'on codait les algos en C. Mais c'était de l'audio, et l'algo de la FFT est relativement simple. Les débits de flux vidéo sont plus importants, et les algo de compressions trames (du moins ceux que je connais) sont plus complexes.

Jibier