C'est l'avantage de faire des statiques sur des comparaisons A/B/x, plein de biais peuvent être filtré.
Sauf que si je ne trompe pas (je ne suis pas un spécialiste des comparaisons A/B/x), un biais ne peut être filtré que si il est constant sur l'ensemble des échantillons, non ? Ce qui ne serait pas le cas ici.
Si l'objectif est de mesurer la qualité ressentie des encodages auprès d'un échantillon représentatif de la population, alors les daltoniens ont leur mot à dire.
Ben justement, on ne cherche pas à avoir un échantillon représentatif de la population. On cherche à savoir, le plus précisément possible, quel est l'impact sur le système visuel humain, de tel ou tel système dégradant. Or le SVH en question n'est pas une "moyenne" ou une "représentation" de tous les SVH existants mais plutôt un modèle, une espèce de concept médico-psychologique représentant le cas nominal, parce que les déviances sont souvent trop importantes et auraient un impact trop important dans une moyenne. Oui, il y a des cas déviants, mais les codeurs ne peuvent pas en tenir compte dans leur manière de fonctionner, donc ça n'aurait pas de sens de les prendre en compte dans des tests subjectifs qui leur seraient dédiés.
Comme je l'ai déjà dit dans le fil de discussion sur le sujet [1], ce n'est pas forcément si simple, en tout cas pour avoir des résultats exploitables. Pour que les notes de deux utilisateurs soient comparables, il faut qu'ils soient dans les mêmes conditions d'expérimentation, notamment en termes d'affichage et d'éclairage ambiant. Sans parler du fait que les utilisateurs sont normalement testés pour écarter les cas de daltonisme et d'acuité faible (les bons vieux tests avec des lettres à lire au fond de la salle :-) ). C'est pour ça que ce genre de test se fait dans des salles dédiées, normalisées et que ça prend du temps et de l'argent.
Alors maintenant, oui, on peut s'affranchir de ces contraintes et faire un test via une interface web bien foutue (c'est pas à Mozilla qu'on va apprendre ça), mais rien ne garantira que les écarts de notes, semble-t-il minimes, entre les différents systèmes de codage provienne des différences de codage ou de la méthodologie.
Ceci dit, des sessions de tests subjectifs bien faits me semblent plus pertinentes que d'utiliser des métriques type SSIM. Elles ont certes l'avantage d'avoir du code disponible, d'être rapides à mettre en place et d'être relativement simples à comprendre, mais aucune d'elles n'est suffisament précise (corrélation de l'ordre de 0.91) pour déclarer un vainqueur clair dans ce type de comparaison. Il existe d'autres métriques plus proches du système visuel humain, mais c'est pas la même complexité…
C'est clairement une fonctionnalité identifiée comme essentielle dans mon entreprise, et évidemment Dropbox n'est pas une solution viable pour conserver des fichiers professionnels. Une solution Open Source auto-hébergée serait l'idéal mais à ma connaissance, il n'en existe pas de complète qui arrive au niveau fonctionnel de Dropbox.
y'en a très peu, c'est d'ailleurs un gros problème pour nous (chercheurs en qualité vidéo en HD)
pour donner une idée, on utilise 24 séquences de 10 secondes, elles font à peu près 1Go chacune (et le codage H.264 avec le codeur de référence dure environ 2 jours sur un bi-Xeon :-) )
j'avais un lien où on pouvait en télécharger une poignées mais il est HS, donc je n'ai rien à proposer....
Attention cependant, ils utilisent des métriques de qualité objectives (PSNR et SSIM) dont les performances sont très discutables.... et faire des tests subjectifs n'est pas à la portée de tout le monde.
L'autre problème est qu'ils testent énormément de choses. Il y a du multi-contenu, du multi-format (du QCIF à la TVHD), du multi-framerate et donc du multi-codeurs. Pas facile de s'y retrouver et d'avoir des échantillons représentatifs. La dernière campagne de comparaison de décembre 2007 (http://compression.ru/video/codec_comparison/mpeg-4_avc_h264(...) ) portait sur les codecs suivant :
# XviD (MPEG-4 ASP codec)
# MainConcept H.264
# Intel H.264
# x264
# AMD H.264
# Artemis H.264
Évidemment, il n'inclut pas Dirac dans son panel de codecs, peut-être qu'ils élargiront à l'avenir. Pour résumer les résultats (basé sur du PSNR et du SSIM, donc à prendre avec des pincettes) : MainConcept et x264 semblent meilleurs pour les trois configurations (vidéoconférence bas débit, basse taille d'image ; films (qualité DVD) ; TVHD (haut débit, 1920*1080) mais pour ces deux derniers les résultats sont discutables dans la mesure où la source a déjà subit un codage MPEG-2).
[^] # Re: site de comparaison ?
Posté par Stéphane Péchard (site web personnel) . En réponse à la dépêche Étude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 1.
Sauf que si je ne trompe pas (je ne suis pas un spécialiste des comparaisons A/B/x), un biais ne peut être filtré que si il est constant sur l'ensemble des échantillons, non ? Ce qui ne serait pas le cas ici.
[^] # Re: site de comparaison ?
Posté par Stéphane Péchard (site web personnel) . En réponse à la dépêche Étude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 3.
Ben justement, on ne cherche pas à avoir un échantillon représentatif de la population. On cherche à savoir, le plus précisément possible, quel est l'impact sur le système visuel humain, de tel ou tel système dégradant. Or le SVH en question n'est pas une "moyenne" ou une "représentation" de tous les SVH existants mais plutôt un modèle, une espèce de concept médico-psychologique représentant le cas nominal, parce que les déviances sont souvent trop importantes et auraient un impact trop important dans une moyenne. Oui, il y a des cas déviants, mais les codeurs ne peuvent pas en tenir compte dans leur manière de fonctionner, donc ça n'aurait pas de sens de les prendre en compte dans des tests subjectifs qui leur seraient dédiés.
[^] # Re: site de comparaison ?
Posté par Stéphane Péchard (site web personnel) . En réponse à la dépêche Étude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 5.
Comme je l'ai déjà dit dans le fil de discussion sur le sujet [1], ce n'est pas forcément si simple, en tout cas pour avoir des résultats exploitables. Pour que les notes de deux utilisateurs soient comparables, il faut qu'ils soient dans les mêmes conditions d'expérimentation, notamment en termes d'affichage et d'éclairage ambiant. Sans parler du fait que les utilisateurs sont normalement testés pour écarter les cas de daltonisme et d'acuité faible (les bons vieux tests avec des lettres à lire au fond de la salle :-) ). C'est pour ça que ce genre de test se fait dans des salles dédiées, normalisées et que ça prend du temps et de l'argent.
Alors maintenant, oui, on peut s'affranchir de ces contraintes et faire un test via une interface web bien foutue (c'est pas à Mozilla qu'on va apprendre ça), mais rien ne garantira que les écarts de notes, semble-t-il minimes, entre les différents systèmes de codage provienne des différences de codage ou de la méthodologie.
Ceci dit, des sessions de tests subjectifs bien faits me semblent plus pertinentes que d'utiliser des métriques type SSIM. Elles ont certes l'avantage d'avoir du code disponible, d'être rapides à mettre en place et d'être relativement simples à comprendre, mais aucune d'elles n'est suffisament précise (corrélation de l'ordre de 0.91) pour déclarer un vainqueur clair dans ce type de comparaison. Il existe d'autres métriques plus proches du système visuel humain, mais c'est pas la même complexité…
[1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/9NKc7OeEFLM
# marave
Posté par Stéphane Péchard (site web personnel) . En réponse à la dépêche Focuswriter, un éditeur de texte sans distractions. Évalué à 2.
Basé sur PyQt, il ne semble malheureusement plus très actif...
[^] # Re: oui (on veut) mais non (pas celui-la)
Posté par Stéphane Péchard (site web personnel) . En réponse à la dépêche SparkleShare pour partager vos fichiers sur internet. Évalué à 3.
[^] # Re: my 2 cents
Posté par Stéphane Péchard (site web personnel) . En réponse à la dépêche Test d'Ubuntu Jaunty (9.04). Évalué à 1.
Merci
# codec HD ?
Posté par Stéphane Péchard (site web personnel) . En réponse à la dépêche Nouvelle version d'EKD pour Linux. Évalué à 4.
Le HD est un format d'image, non un codec :-)
[^] # Re: Qualité ?
Posté par Stéphane Péchard (site web personnel) . En réponse à la dépêche Schrödinger 1.0 : le codec Dirac est prêt. Évalué à 2.
pour donner une idée, on utilise 24 séquences de 10 secondes, elles font à peu près 1Go chacune (et le codage H.264 avec le codeur de référence dure environ 2 jours sur un bi-Xeon :-) )
j'avais un lien où on pouvait en télécharger une poignées mais il est HS, donc je n'ai rien à proposer....
[^] # Re: Qualité ?
Posté par Stéphane Péchard (site web personnel) . En réponse à la dépêche Schrödinger 1.0 : le codec Dirac est prêt. Évalué à 3.
Attention cependant, ils utilisent des métriques de qualité objectives (PSNR et SSIM) dont les performances sont très discutables.... et faire des tests subjectifs n'est pas à la portée de tout le monde.
L'autre problème est qu'ils testent énormément de choses. Il y a du multi-contenu, du multi-format (du QCIF à la TVHD), du multi-framerate et donc du multi-codeurs. Pas facile de s'y retrouver et d'avoir des échantillons représentatifs. La dernière campagne de comparaison de décembre 2007 (http://compression.ru/video/codec_comparison/mpeg-4_avc_h264(...) ) portait sur les codecs suivant :
# XviD (MPEG-4 ASP codec)
# MainConcept H.264
# Intel H.264
# x264
# AMD H.264
# Artemis H.264
Évidemment, il n'inclut pas Dirac dans son panel de codecs, peut-être qu'ils élargiront à l'avenir. Pour résumer les résultats (basé sur du PSNR et du SSIM, donc à prendre avec des pincettes) : MainConcept et x264 semblent meilleurs pour les trois configurations (vidéoconférence bas débit, basse taille d'image ; films (qualité DVD) ; TVHD (haut débit, 1920*1080) mais pour ces deux derniers les résultats sont discutables dans la mesure où la source a déjà subit un codage MPEG-2).