Salut a tous,

Je suis actuellement en train de developper un petit couple de programmes pour envoyer sur un pc via internet (wifi) en temps réél ce que filme ma psp grace a la goCam.

pour le moment ça marche.... basiquement pour etre pudique.
En gros tout ce qui est aquisition d´image, envois et réaffichage ça tourne.

Le pb c´est que je recupere une image de 480*272 en 3octets par pixel. -> 391ko pour une image... c´est beaucoup trop pour etre viable (j´ai une image tt les 2 secondes qui arrive)

J´ai mis en place une compression maison:
j´envois un pixel sur 16 (et il donne un carré de 4*4 sur l´image d´arrivé)
je ramene les couleurs sur 8 bits au lieu de 24 en prenant les bits de poid fort des 3 composantes (3 pour le rouge et le vert et 2 pour le bleu dont l´oeuil voit moins les dégradés)

Avec ça je tombe a 8ko par image, ça me permet d´afficher 3 ou 4 images par secondes. bien mieu me direz vous...
Sauf que ma maniere de compressé donne un espece de vomi de couleurs...
Alors j´ai chercher un peu sur le web et je pense avoir trouvé le couple d´opération me permettant de réduire la taille sans reduire autant la qualité.
compression en ondelette + codage de huffman.
http://fr.wikipedia.org/wiki/Compression_par_ondelettes
http://fr.wikipedia.org/wiki/Codage_de_Huffman

j´ai les base de traitement du signal et deja codé les algos avec scilab. Donc coté portage en C je pense pouvoir m´en sortir mais je voudrais savoir, si quelqu´un si connais, si c´est un bon choix ou si je vais passer 2 jours a coder un truc qui servira a pas grand chose.

Merci

pour info voila ce que ça donne pour le moment
http://www.dailymotion.com/wiof/video/x2m2rn_psp2pc_webcam
les sauts sont du a ma connexion

Les ondelettes, ça peut etre sympa.
Ton erreur est de traiter les images de la vidéo de façon indépendante.
Mais je serais toi, je me renseignerai sur la compression MPEG.

Regarde aussi (je crois bien que MPEG utilise ça) la notion de Keyframes.

Une keyframe, c´est une belle image envoyée toutes les 5 ou 10 secondes (donc une image - compressée bien sur - mais de qualité plutot bonne)

Donc tu as une belle image qui arrive chez le client.
Ensuite, comment est calculée l´image suivante ?
Elle est calculée en fonction de l´image précédente :
l´image N dépend de N-1
C´est la différence (ou soustraction pixels/pixels si tu veux) entre les 2 images.
C´est la qu´est l´astuce : sur une image webcam par exemple, tout le fond ne bouge pas : donc si tu fais une soustraction entre N et N-1, tu as un fond noir sur ton image résultante, et comme tu as peu bougé, l´image calculée (soustraite) est tres sombre : elle se compresse donc super bien !!

Donc, pour résumer, des Keyframes (pour resynchroniser) toutes les 5 a 10 secondes, et sinon, entre les keyframe, tu passes les soustractions : donc des images souvent tres noires, donc tres compactes.

Tu vois le truc ?
Le client, lui, a déja l´image N-1, récupere l´image soustraite N, il l´additionne a N-1, et il récupere une belle image.

Apres, il a la keyframe intelligente : au lieu de faire toutes les 5 ou 10 secondes, tu fais ça des que l´image "change trop" -> ça se détecte par une soustraction "trop importante" entre N et N-1. -> typiquement dans un film un changement de scene.

Certains formats de compression (bon, la c´est plus trop webcam, mais film) partent du principe que dans un film, il y a des "scrollings" : quand une caméra balaye un champ. Donc ils font une soustratcion entre N et N-1 en ayant d´abord réévalué un vecteur translation. (qu´ils passent)
Le DIVX va encore plus loin : car il a des algos de reconnaissance de formes.

Qui n´a pas déja vu un DIVX défecteux, avec, des fois, pendant 5 secondes, des pixels incohérants sur l´image, mais qui représentent malgré tout la forme du mec qui bouge
Et puis d´un coup, tout redevient beau -> Keyframe atteinte

Toutes les tentatives qui ne font pas de la keyframe sont voué a l´echec, il n´y a pas assez de BP pour assurer une image fluide en envoyant toutes les images.

Tu peux aussi chercher a compresser la keyframe et les différences avec ou sans perte. En premiere approximation, tu dois pouvoir dire que les bits de poids fort des composantes ne changeront pas. Et donc, tu peux passer sur un codage à 4 bits par composante.
Rien ne t´empeche non plus de passer une compression sur toute ton image. Une idée est la meme que celle de key frame, c´est celle de keypixel. tu coupe ton image en petit carré, tu code completement la couleur du premier pixel qui est le key pixel. Et tu exprimes la couleurs des autres pixels du meme carré en fonction du key pixel. La encore, tu obtiens une image qui ressemble a l´image de base, mais tu risque de voir apparaitre des petit carér au niveau des changements brute de couleur.

merci merci...
j´avais effectivement vu des trucs sur le mpeg mais ça m´avais parru un poil compliqué.

bon je vais voir ce que donnent les ondelettes (je cherche pas qqch de fluide mais au moins 3-4 frame par secondes). Si ça convient pas j´essayerais les keyframes et keypixels.

[...intense reflexion...]

quoique les keypixels me semblent assez simple a appliquer, je vais faire ça plutot en premier

les bases du MPEG sont en fait assez "simples" ; ca consiste en 2 types de keyframes (image completes / offsets), et de la prediction bi-directionnelle multidimensionnelle. details :

- bidirectionnelle, car c´est un mix de forward / backward entre les keyframes
- multidimensionnelles, car on utilise la redondance spatiale (variations dans l´image, voir methodes 3SS three-step-search, ou H264, etc.) , mais aussi la redondance temporelle (variation au cours du temps)

en implementant ca, on obitient un compresseur tres flexible en termes d´adaptabilite ; une premiere passe d´analyse pour determiner distorsion en entropie du signal permet de trouver des bons parametres pour le codec.

au final, c´est juste du pattern-matching, de l´interpolation, et qq noyaux de convolution. Avec qq notions de traitement du signal, ca se fait pas trop mal.

les convolutions ça va pas trop le faire... je rappel que le prog tourne sur une psp et qu´elle a beau etre pas mal puissante ça sert a rien que je gagne sur le temps de transfert si je perd tout dans l´algo de compression ;)

bah c´est rien, une convolution discrete, sur des petits noyaux genre 3x3 a 5x5, c´est guere que qq look up et une formule pour ponderer les coefficients.

Je suis pas connaisseur de PSP, mais sauf erreur de ma part, elle propose deja un movie player non ? ca doit faire des choses dans ce genre la, avec surement du filtrage bcp plus avance.

les convolutions 3x3 ou meme 5x5 ne sont pas trop calculatoires (surtout que tu n´es pas en tres haute résolution), donc a mon avis tout a fait supportable par une PSP.

A ne pas oublier qu´une PSP est quand meme plus puissante que de tres vieux PC qui geraient déja bien le MPEG

Je me pose la question... Une PSP, c´est un (ou plusieurs processeurs) mais surtout (pour le jeu) un chipset graphique de tres bonne qualité. Est ce que tu ne pourrais pas voir si tu ne pourrais pas tirer avantage de ce matériel la ?
Par exemple les filtrages de textures pourraient peut etre t´aider a avoir une image moins pixelisée...

autant pour moi, si vous pensez que ça peu passer je vous fais confiance.

La convolution c´est bien :
pour chaque pixel (sauf les bords suivant la taille du masque) faire n*n additions ou multiplication voir division suivant le masque pour avoir une valeur.

Ouai en fait vous devez avoir raison, je me faisait du soucis mais c´est pas parce qu´elle est petite qu´elle en a pas sous le capot.

"A ne pas oublier qu´une PSP est quand meme plus puissante que de tres vieux PC qui geraient déja bien le MPEG"

Mais compresser et décompresser sont différent. Le format est prévu pour être facilement lisible (on peut lire des vidéo mpeg à plusieurs centaine de fois la vitesse normale). Par contre, pour les compresser, même mon core 2 ne va pas beaucoup plus vite que le temps réel.

Donc je ne sais pas si la psp peut compresser beaucoup d´image pa seconde (mais la résolution est probablement assez petite).