je n'ai pas fait encore des tests comparatifs, et puis avant de le
faire, je me suis dit que ça a du être déjà fait...
et hors son, bien entendu, puisque ma demande ne porte que sur la
vidéo, quel est le meilleur compromis ?
(sachant qu'on part d'une source 1080p - en fait une série télé qui
prend une place pas possible)
entre:
* la dimension de l'image
* le codec (xvid, h264 ?)
* le bitrate
* la taille de sortie
* la vitesse de compression (choix du codec et 1 ou 2 passes ?)
pour un visionnage correct sur un écran de plus de 50'
avec une taille de sortie de 12Mo/minute (1Go/1h30), je rappelle, hors
son évidemment.
S'il y avait une série de vidéos presentant un court extrait avec une
scene lente, une scene rapide, en plusieurs formats, ça serait pas
mal... ça n'existe pas deja ?
ce n'est pas ce que vous cherchez désespérement sur le net concernant les vecteurs, ça ne concerne que les déplacements de blocs dans l'image, sans rotation, sans zoom: juste 2 directions : horizontale et verticale.
vous voulez me convaincre de quoi ? que le x264 est abouti ? même pas en rêve.
ce n'est pas ce que vous cherchez désespérement sur le net concernant
les vecteurs, ça ne concerne que les déplacements de blocs dans
l'image, sans rotation, sans zoom: juste 2 directions : horizontale et
verticale.
vous voulez me convaincre de quoi ? que le x264 est abouti ? même pas
en rêve.
ce n'est pas ce que vous cherchez désespérement sur le net concernant les vecteurs, ça ne concerne que les déplacements de blocs dans l'image, sans rotation, sans zoom: juste 2 directions : horizontale et verticale.
vous voulez me convaincre de quoi ? que le x264 est abouti ? même pas en rêve.
ce n'est pas ce que vous cherchez désespérement sur le net concernant les vecteurs, ça ne concerne que les déplacements de blocs dans l'image
tenez :
Estimation de mouvement subpixélique par blocs... rapport de stage, Vincent Garcia, Université de Nice, STIC
pour alf: /Ch2/L'estimation de mouvement est excessivement coûteuse en temps de calcul. Cela peut prendre jusqu'à 80% des ressources matérielles de la machine. Aujourd'hui on se contente d'aller au bout de cette logique, confirmation :
/Ch3/L'idée de l'utilisation d'un modèle de mouvement linéaire pour l'estimation de mouvement (nous nommons ceci la contrainte bidirectionnelle) provient de l'hypothèse de linéarité du mouvement interne dans une vidéo.
En clair, cela veut dire qu'on ne s'occupe pas ni de zoom, ni de rotations, les blocs sont des rectangles, on recherche juste leur place. Il n'est pas question d'analyser plus globalement des parties ou des objets dans l'image pour en déterminer des zones prédictives qui subiraient une rotation, un zoom en même temps qu'un déplacement. Cette logique trouve sa limitation en ce qu'on ne peut pas diminuer la taille d'un bloc en deça d'une taille minimale, parceque cela deviendra d'une part infernal en temps de calcul, et d'autre part, cela n'aurait aucun sens de chercher une texture de "un" pixel (ou de 2...): il en faut un minimum pour pouvoir faire des comparaisons OR, cette logique qui pourrait émuler des recherches de zoom et de rotation ne peut aboutir qu'au pixel près, c'est donc contradictoire, donc impossible, pour l'instant, on reste dans l'approximation en estimant que macroscopiquement sur un petit nombre d'image, les différences ne sont que des translations, mais la ou on pourrait globalement définir une rotation/zoom/déplacement avec des données scalaires plus complexes, on en reste a une série de vecteurs bidirectionnels, d'une image a l'autre et non d'une image clé aux suivantes, d'autant plus nombreux qu'on veut être plus précis, avec les limitations évoquées plus haut.
On ne pourra passer au stade suivant qu'avec l'intelligence artificielle qui ne découpera pas en force brute des blocs, pour chercher leur correspondance ddans l'image de référence, mais recherchera des zones d'images (objets), et leur transformation scalaire, et la, niveau temps de calcul, on n'est pas sorti de l'auberge, mais ça viendra surement un jour
c'est de "cela dont de quoi je causait"
bon, j'ai autre chose a faire, je vous laisse en rajouter 5 couches a côté de la plaque puisque je vous signale quand même que ceci était parti de juste 2 mots sur les évolutions des codages déjà brimés a l'heure actuelle par la faiblesse des processeurs je n'en demandais pas tant mais j'aurai au moins appris que le divx savait deja utiliser les déplacements linéaires, même si contrairement au h264, il ne pouvait pas les utiliser pour reconstruire des trames servant de clé aux suivantes
c'est déjà pas mal donc au moins merci la dessus
-- Thierry http://ardf.free.fr
Thierry M. avait prétendu :
pehache a pensé très fort :
C'est quoi les "translations bidirectionnelles" ?
ce n'est pas ce que vous cherchez désespérement sur le net concernant les
vecteurs, ça ne concerne que les déplacements de blocs dans l'image
tenez :
Estimation de mouvement subpixélique par blocs...
rapport de stage, Vincent Garcia, Université de Nice, STIC
pour alf:
/Ch2/L'estimation de mouvement est excessivement coûteuse en temps de
calcul. Cela peut prendre jusqu'à 80% des ressources matérielles de la
machine.
Aujourd'hui on se contente d'aller au bout de cette logique,
confirmation :
/Ch3/L'idée de l'utilisation d'un modèle de mouvement linéaire pour
l'estimation de mouvement (nous nommons ceci la contrainte
bidirectionnelle) provient de l'hypothèse de linéarité du
mouvement interne dans une vidéo.
En clair, cela veut dire qu'on ne s'occupe pas ni de zoom, ni de
rotations, les blocs sont des rectangles, on recherche juste leur
place. Il n'est pas question d'analyser plus globalement des parties ou
des objets dans l'image pour en déterminer des zones prédictives qui
subiraient une rotation, un zoom en même temps qu'un déplacement.
Cette logique trouve sa limitation en ce qu'on ne peut pas diminuer la
taille d'un bloc en deça d'une taille minimale, parceque cela deviendra
d'une part infernal en temps de calcul, et d'autre part, cela n'aurait
aucun sens de chercher une texture de "un" pixel (ou de 2...): il en
faut un minimum pour pouvoir faire des comparaisons
OR, cette logique qui pourrait émuler des recherches de zoom et de
rotation ne peut aboutir qu'au pixel près, c'est donc contradictoire,
donc impossible, pour l'instant, on reste dans l'approximation en
estimant que macroscopiquement sur un petit nombre d'image, les
différences ne sont que des translations, mais la ou on pourrait
globalement définir une rotation/zoom/déplacement avec des données
scalaires plus complexes, on en reste a une série de vecteurs
bidirectionnels, d'une image a l'autre et non d'une image clé aux
suivantes, d'autant plus nombreux qu'on veut être plus précis, avec les
limitations évoquées plus haut.
On ne pourra passer au stade suivant qu'avec l'intelligence
artificielle qui ne découpera pas en force brute des blocs, pour
chercher leur correspondance ddans l'image de référence, mais
recherchera des zones d'images (objets), et leur transformation
scalaire, et la, niveau temps de calcul, on n'est pas sorti de
l'auberge, mais ça viendra surement un jour
c'est de "cela dont de quoi je causait"
bon, j'ai autre chose a faire, je vous laisse en rajouter 5 couches a
côté de la plaque puisque je vous signale quand même que ceci était
parti de juste 2 mots sur les évolutions des codages déjà brimés a
l'heure actuelle par la faiblesse des processeurs
je n'en demandais pas tant
mais j'aurai au moins appris que le divx savait deja utiliser les
déplacements linéaires, même si contrairement au h264, il ne pouvait
pas les utiliser pour reconstruire des trames servant de clé aux
suivantes
ce n'est pas ce que vous cherchez désespérement sur le net concernant les vecteurs, ça ne concerne que les déplacements de blocs dans l'image
tenez :
Estimation de mouvement subpixélique par blocs... rapport de stage, Vincent Garcia, Université de Nice, STIC
pour alf: /Ch2/L'estimation de mouvement est excessivement coûteuse en temps de calcul. Cela peut prendre jusqu'à 80% des ressources matérielles de la machine. Aujourd'hui on se contente d'aller au bout de cette logique, confirmation :
/Ch3/L'idée de l'utilisation d'un modèle de mouvement linéaire pour l'estimation de mouvement (nous nommons ceci la contrainte bidirectionnelle) provient de l'hypothèse de linéarité du mouvement interne dans une vidéo.
En clair, cela veut dire qu'on ne s'occupe pas ni de zoom, ni de rotations, les blocs sont des rectangles, on recherche juste leur place. Il n'est pas question d'analyser plus globalement des parties ou des objets dans l'image pour en déterminer des zones prédictives qui subiraient une rotation, un zoom en même temps qu'un déplacement. Cette logique trouve sa limitation en ce qu'on ne peut pas diminuer la taille d'un bloc en deça d'une taille minimale, parceque cela deviendra d'une part infernal en temps de calcul, et d'autre part, cela n'aurait aucun sens de chercher une texture de "un" pixel (ou de 2...): il en faut un minimum pour pouvoir faire des comparaisons OR, cette logique qui pourrait émuler des recherches de zoom et de rotation ne peut aboutir qu'au pixel près, c'est donc contradictoire, donc impossible, pour l'instant, on reste dans l'approximation en estimant que macroscopiquement sur un petit nombre d'image, les différences ne sont que des translations, mais la ou on pourrait globalement définir une rotation/zoom/déplacement avec des données scalaires plus complexes, on en reste a une série de vecteurs bidirectionnels, d'une image a l'autre et non d'une image clé aux suivantes, d'autant plus nombreux qu'on veut être plus précis, avec les limitations évoquées plus haut.
On ne pourra passer au stade suivant qu'avec l'intelligence artificielle qui ne découpera pas en force brute des blocs, pour chercher leur correspondance ddans l'image de référence, mais recherchera des zones d'images (objets), et leur transformation scalaire, et la, niveau temps de calcul, on n'est pas sorti de l'auberge, mais ça viendra surement un jour
c'est de "cela dont de quoi je causait"
bon, j'ai autre chose a faire, je vous laisse en rajouter 5 couches a côté de la plaque puisque je vous signale quand même que ceci était parti de juste 2 mots sur les évolutions des codages déjà brimés a l'heure actuelle par la faiblesse des processeurs je n'en demandais pas tant mais j'aurai au moins appris que le divx savait deja utiliser les déplacements linéaires, même si contrairement au h264, il ne pouvait pas les utiliser pour reconstruire des trames servant de clé aux suivantes
c'est déjà pas mal donc au moins merci la dessus
-- Thierry http://ardf.free.fr
pehache
Le 17/05/12 06:48, Thierry M. a écrit :
pehache a pensé très fort :
C'est quoi les "translations bidirectionnelles" ?
ce n'est pas ce que vous cherchez désespérement sur le net concernant les vecteurs,
Euh, merci, mais je n'ai pas attendu hier pour découvrir ce qu'était un champs de vecteurs...
ça ne concerne que les déplacements de blocs dans l'image, sans rotation, sans zoom:
Totalement faux, une fois de plus. Un champs continu de vecteurs peut décrire tout ça, et bien plus encore. Faut avoir fait un peu de maths et de physique, hein...
La limitation dans les codecs actuels c'est que ce ne sont pas des champs *continus* et qu'il n'y a qu'un vecteur par bloc. Pour décrire plus finement le mouvement par un champs de vecteurs il faut en avoir plus, jusqu'à 1 vecteur par pixel si possible. Mais il faut une puissance de calcul énorme pour ça, donc pas possible pour l'instant.
juste 2 directions : horizontale et verticale.
Une translation, quoi. Inutile d'ajouter "bidirectionnelle", qui est totalement superflu et n'a aucun sens mathématique.
Le 17/05/12 06:48, Thierry M. a écrit :
pehache a pensé très fort :
C'est quoi les "translations bidirectionnelles" ?
ce n'est pas ce que vous cherchez désespérement sur le net concernant
les vecteurs,
Euh, merci, mais je n'ai pas attendu hier pour découvrir ce qu'était un
champs de vecteurs...
ça ne concerne que les déplacements de blocs dans l'image,
sans rotation, sans zoom:
Totalement faux, une fois de plus. Un champs continu de vecteurs peut
décrire tout ça, et bien plus encore. Faut avoir fait un peu de maths et
de physique, hein...
La limitation dans les codecs actuels c'est que ce ne sont pas des
champs *continus* et qu'il n'y a qu'un vecteur par bloc. Pour décrire
plus finement le mouvement par un champs de vecteurs il faut en avoir
plus, jusqu'à 1 vecteur par pixel si possible. Mais il faut une
puissance de calcul énorme pour ça, donc pas possible pour l'instant.
juste 2 directions : horizontale et verticale.
Une translation, quoi. Inutile d'ajouter "bidirectionnelle", qui est
totalement superflu et n'a aucun sens mathématique.
ce n'est pas ce que vous cherchez désespérement sur le net concernant les vecteurs,
Euh, merci, mais je n'ai pas attendu hier pour découvrir ce qu'était un champs de vecteurs...
ça ne concerne que les déplacements de blocs dans l'image, sans rotation, sans zoom:
Totalement faux, une fois de plus. Un champs continu de vecteurs peut décrire tout ça, et bien plus encore. Faut avoir fait un peu de maths et de physique, hein...
La limitation dans les codecs actuels c'est que ce ne sont pas des champs *continus* et qu'il n'y a qu'un vecteur par bloc. Pour décrire plus finement le mouvement par un champs de vecteurs il faut en avoir plus, jusqu'à 1 vecteur par pixel si possible. Mais il faut une puissance de calcul énorme pour ça, donc pas possible pour l'instant.
juste 2 directions : horizontale et verticale.
Une translation, quoi. Inutile d'ajouter "bidirectionnelle", qui est totalement superflu et n'a aucun sens mathématique.
Thierry M.
pehache a formulé ce jeudi :
Une translation, quoi. Inutile d'ajouter "bidirectionnelle", qui est totalement superflu et n'a aucun sens mathématique.
ce n'est pas moi qui emploi ce mot ah eh puis a vrai dire, vous me faites chier la, c'est dit
-- Thierry Photos de foetus entre 8 et 12 semaines: http://ardf.free.fr/foetus
pehache a formulé ce jeudi :
Une translation, quoi. Inutile d'ajouter "bidirectionnelle", qui est
totalement superflu et n'a aucun sens mathématique.
ce n'est pas moi qui emploi ce mot
ah eh puis a vrai dire, vous me faites chier
la, c'est dit
--
Thierry
Photos de foetus entre 8 et 12 semaines:
http://ardf.free.fr/foetus
Une translation, quoi. Inutile d'ajouter "bidirectionnelle", qui est totalement superflu et n'a aucun sens mathématique.
ce n'est pas moi qui emploi ce mot ah eh puis a vrai dire, vous me faites chier la, c'est dit
-- Thierry Photos de foetus entre 8 et 12 semaines: http://ardf.free.fr/foetus
bilou
"Alf92" wrote in message news:jovr0n$2pf$
"bilou" a écrit
Une serie TV en 1080p c'est diffusé ou ?
sur la TNT HD par exemple
Alors on doit pas vivre sur la meme planete. Chez moi la TV est diffusée en entrelacé depuis 70 ans.
quel est le rapport ?
Le rapport c'est que sur ma planete on diffuse la HD en 1080i pour interlaced Et non en 1080p pour progressive. ccette derniere option reservée aux pros et bluray donne des fichiers de taille double
--- Posted via news://freenews.netfront.net/ - Complaints to ---
"Alf92" <alf921@gmail.com> wrote in message
news:jovr0n$2pf$1@dont-email.me...
"bilou" <laurent.blinpadepub@free.fr> a écrit
Une serie TV en 1080p c'est diffusé ou ?
sur la TNT HD par exemple
Alors on doit pas vivre sur la meme planete.
Chez moi la TV est diffusée en entrelacé depuis 70 ans.
quel est le rapport ?
Le rapport c'est que sur ma planete on diffuse la HD en 1080i
pour interlaced
Et non en 1080p pour progressive.
ccette derniere option reservée aux pros et bluray donne
des fichiers de taille double
--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
Alors on doit pas vivre sur la meme planete. Chez moi la TV est diffusée en entrelacé depuis 70 ans.
quel est le rapport ?
Le rapport c'est que sur ma planete on diffuse la HD en 1080i pour interlaced Et non en 1080p pour progressive. ccette derniere option reservée aux pros et bluray donne des fichiers de taille double
--- Posted via news://freenews.netfront.net/ - Complaints to ---
pehache
Le 17/05/12 13:01, Thierry M. a écrit :
pehache a formulé ce jeudi :
Une translation, quoi. Inutile d'ajouter "bidirectionnelle", qui est totalement superflu et n'a aucun sens mathématique.
ce n'est pas moi qui emploi ce mot
Tu le réemploies, donc c'est à toi que je le dis.
Ce n'est pas parce que quelqu'un d'autre l'a écrit que c'est parole d'évangile
ah eh puis a vrai dire, vous me faites chier la, c'est dit
Aucune importance, un forum n'est pas une discussion entre 2 personnes
Le 17/05/12 13:01, Thierry M. a écrit :
pehache a formulé ce jeudi :
Une translation, quoi. Inutile d'ajouter "bidirectionnelle", qui est
totalement superflu et n'a aucun sens mathématique.
ce n'est pas moi qui emploi ce mot
Tu le réemploies, donc c'est à toi que je le dis.
Ce n'est pas parce que quelqu'un d'autre l'a écrit que c'est parole
d'évangile
ah eh puis a vrai dire, vous me faites chier
la, c'est dit
Aucune importance, un forum n'est pas une discussion entre 2 personnes
Une translation, quoi. Inutile d'ajouter "bidirectionnelle", qui est totalement superflu et n'a aucun sens mathématique.
ce n'est pas moi qui emploi ce mot
Tu le réemploies, donc c'est à toi que je le dis.
Ce n'est pas parce que quelqu'un d'autre l'a écrit que c'est parole d'évangile
ah eh puis a vrai dire, vous me faites chier la, c'est dit
Aucune importance, un forum n'est pas une discussion entre 2 personnes
Stephane Legras-Decussy
Le 17/05/2012 14:36, bilou a écrit :
Le rapport c'est que sur ma planete on diffuse la HD en 1080i pour interlaced Et non en 1080p pour progressive. ccette derniere option reservée aux pros et bluray donne des fichiers de taille double
non la taille est la même.
en on affiche 540 lignes à t et 540 lignes à t+10ms
en on affiche 1080 lignes à t
au final, on a exactement le même nombre de ligne par seconde.
Le 17/05/2012 14:36, bilou a écrit :
Le rapport c'est que sur ma planete on diffuse la HD en 1080i
pour interlaced
Et non en 1080p pour progressive.
ccette derniere option reservée aux pros et bluray donne
des fichiers de taille double
non la taille est la même.
en 1080i@25fps on affiche 540 lignes à t et 540 lignes à t+10ms
en 1080p@25fps on affiche 1080 lignes à t
au final, on a exactement le même nombre de ligne par seconde.
Le rapport c'est que sur ma planete on diffuse la HD en 1080i pour interlaced Et non en 1080p pour progressive. ccette derniere option reservée aux pros et bluray donne des fichiers de taille double
non la taille est la même.
en on affiche 540 lignes à t et 540 lignes à t+10ms
en on affiche 1080 lignes à t
au final, on a exactement le même nombre de ligne par seconde.
jean-daniel dodin
Le 17/05/2012 15:39, Stephane Legras-Decussy a écrit :
Le 17/05/2012 14:36, bilou a écrit :
Le rapport c'est que sur ma planete on diffuse la HD en 1080i pour interlaced Et non en 1080p pour progressive. ccette derniere option reservée aux pros et bluray donne des fichiers de taille double
non la taille est la même.
en on affiche 540 lignes à t et 540 lignes à t+10ms
en on affiche 1080 lignes à t
au final, on a exactement le même nombre de ligne par seconde.
mon camescope me propose 50i ou 25p, ca me parait plus clair (tout ca en 1080)
jdd
Le 17/05/2012 15:39, Stephane Legras-Decussy a écrit :
Le 17/05/2012 14:36, bilou a écrit :
Le rapport c'est que sur ma planete on diffuse la HD en 1080i
pour interlaced
Et non en 1080p pour progressive.
ccette derniere option reservée aux pros et bluray donne
des fichiers de taille double
non la taille est la même.
en 1080i@25fps on affiche 540 lignes à t et 540 lignes à t+10ms
en 1080p@25fps on affiche 1080 lignes à t
au final, on a exactement le même nombre de ligne par seconde.
mon camescope me propose 50i ou 25p, ca me parait plus clair (tout ca
en 1080)
Le 17/05/2012 15:39, Stephane Legras-Decussy a écrit :
Le 17/05/2012 14:36, bilou a écrit :
Le rapport c'est que sur ma planete on diffuse la HD en 1080i pour interlaced Et non en 1080p pour progressive. ccette derniere option reservée aux pros et bluray donne des fichiers de taille double
non la taille est la même.
en on affiche 540 lignes à t et 540 lignes à t+10ms
en on affiche 1080 lignes à t
au final, on a exactement le même nombre de ligne par seconde.
mon camescope me propose 50i ou 25p, ca me parait plus clair (tout ca en 1080)
jdd
pehache
Le 17/05/12 06:40, Thierry M. a écrit :
pehache a utilisé son clavier pour écrire :
Vu que chaque bloc est caractérisé par un vecteur déplacement indépendant, ça veut dire que le pas a été franchi hier.
non, pas de zoom, pas de rotation, juste en déplacement bidirectionnel,
On le refait : avec un champs continu de vecteurs on peut décrire ce qu'on veut : rotations, zoom, ou n'importe quoi.
et ce n'est pas un probleme de taille de bloc
Si, c'est aussi un problème de taille de blocs. Avec un vecteur par (petit) bloc on ne fait qu'approximer une rotation par exemple. Mais c'est quand même mieux que rien.
En gardant les blocs il pourrait y avoir effectivement un paramètre de rotation et un de zoom: mais là aussi c'est avant tout un problème de puissance de calcul à l'encodage.
mais d'intelligence artificielle pour distinguer non pas des blocs rectangulaires, mais des parties concretes d'image (des objets) on en est très loin, surtout qu'on ne peut pas encore exploiter pratiquement les performances logicielles des codecs d'aujourd'hui quant à modéliser en temps réel l'image en vectoriel, puis textures et éclairage, ce qui nous amenerai a la compression ultime (parcequ'aller plus loin en intelligence artificielle pure ne pourra plus nous montrer les subtilité de la réalisation qui reviendrait à la machine) la on est en 3012...
La reconnaissance d'objets est une autre voie, en effet
Le 17/05/12 06:40, Thierry M. a écrit :
pehache a utilisé son clavier pour écrire :
Vu que chaque bloc est caractérisé par un vecteur déplacement
indépendant, ça veut dire que le pas a été franchi hier.
non, pas de zoom, pas de rotation, juste en déplacement bidirectionnel,
On le refait : avec un champs continu de vecteurs on peut décrire ce
qu'on veut : rotations, zoom, ou n'importe quoi.
et ce n'est pas un probleme de taille de bloc
Si, c'est aussi un problème de taille de blocs. Avec un vecteur par
(petit) bloc on ne fait qu'approximer une rotation par exemple. Mais
c'est quand même mieux que rien.
En gardant les blocs il pourrait y avoir effectivement un paramètre de
rotation et un de zoom: mais là aussi c'est avant tout un problème de
puissance de calcul à l'encodage.
mais d'intelligence
artificielle pour distinguer non pas des blocs rectangulaires, mais des
parties concretes d'image (des objets)
on en est très loin, surtout qu'on ne peut pas encore exploiter
pratiquement les performances logicielles des codecs d'aujourd'hui
quant à modéliser en temps réel l'image en vectoriel, puis textures et
éclairage, ce qui nous amenerai a la compression ultime (parcequ'aller
plus loin en intelligence artificielle pure ne pourra plus nous montrer
les subtilité de la réalisation qui reviendrait à la machine)
la on est en 3012...
La reconnaissance d'objets est une autre voie, en effet
Vu que chaque bloc est caractérisé par un vecteur déplacement indépendant, ça veut dire que le pas a été franchi hier.
non, pas de zoom, pas de rotation, juste en déplacement bidirectionnel,
On le refait : avec un champs continu de vecteurs on peut décrire ce qu'on veut : rotations, zoom, ou n'importe quoi.
et ce n'est pas un probleme de taille de bloc
Si, c'est aussi un problème de taille de blocs. Avec un vecteur par (petit) bloc on ne fait qu'approximer une rotation par exemple. Mais c'est quand même mieux que rien.
En gardant les blocs il pourrait y avoir effectivement un paramètre de rotation et un de zoom: mais là aussi c'est avant tout un problème de puissance de calcul à l'encodage.
mais d'intelligence artificielle pour distinguer non pas des blocs rectangulaires, mais des parties concretes d'image (des objets) on en est très loin, surtout qu'on ne peut pas encore exploiter pratiquement les performances logicielles des codecs d'aujourd'hui quant à modéliser en temps réel l'image en vectoriel, puis textures et éclairage, ce qui nous amenerai a la compression ultime (parcequ'aller plus loin en intelligence artificielle pure ne pourra plus nous montrer les subtilité de la réalisation qui reviendrait à la machine) la on est en 3012...
La reconnaissance d'objets est une autre voie, en effet
Thierry M.
pehache avait écrit le 17/05/2012 :
On le refait
merde
quand vous y comprendrez quelque chose, on vous sonnera
-- Thierry http://ardf.free.fr
pehache avait écrit le 17/05/2012 :
On le refait
merde
quand vous y comprendrez quelque chose, on vous sonnera
