Comme l'a souligné Roman, la par défaut Pour la plupart des webcams, le mode Compression MJPEG afin de réduire le débit de données qui doit passer par la connexion USB (et éventuellement par des concentrateurs USB, etc.) et/ou de maximiser la fréquence d'images / la résolution disponible.
Pour la vision par ordinateur, cela n'est souvent pas souhaitable, car nous préférerions avoir une fréquence d'images plus faible, mais pas d'artefacts de compression. En effet, il est possible en général de modifier le taux de compression de l'image. format du flux (par exemple, en YUV non compressé) de la même manière que la résolution est modifiée. Que ce soit en fait possible pour vous dépend de
- dont les modes de fonctionnement sont les suivants matériel soutiennent,
- lequel de ces modes est pris en charge par le pilote de bas niveau (souvent une classe vidéo USB générique / pilote UVC),
- quels sont les modes qui passent à travers les différents cadres concernés (par exemple Video for Windows / DirectX / Video4Linux2 etc.), et
- enfin, ceux qui sont pris en charge par le backend de capture vidéo sont utilisés dans OpenCV.
Malheureusement, la réponse à cette dernière question est tout simplement aucun . OpenCV possède 18( !) backends de capture différents (pour diverses plates-formes, par exemple les téléphones portables, OS X, Windows et Linux, souvent plusieurs pour différentes versions des frameworks sous-jacents), et bien qu'il semble y avoir une API pour changer le format du flux [1], elle ne semble être implémentée par aucun backend. :-(
Si vous ou quelqu'un d'autre souhaite travailler sur ce sujet, vous pouvez consulter le problème OpenCV que j'ai ouvert à ce sujet : http://code.opencv.org/issues/3007
Dans mon cas, j'ai étudié cette question pour certaines webcams Logitech, dont les capacités exposées par les pilotes de bas niveau de Windows et de Linux étaient différentes. Sous Linux, j'ai utilisé sans le savoir un backend GStreamer d'OpenCV, ce qui signifie un autre niveau d'indirection - au niveau le plus bas, cela se résume toujours à l'API du noyau V4L (vidéo pour Linux). L'utilisation du backend libv4l a permis d'améliorer les choses, car il avait la propriété intéressante de proposer par défaut un format de flux YUV (bien qu'à une fréquence d'images éventuellement inférieure, ce qui pourrait être indésirable dans d'autres contextes). (Il existe même des des backends différents et divergents pour un accès direct à l'API du noyau v4l ou en passant par libv4l).
[1] Voir CV_CAP_PROP_FORMAT dans la documentation de l'API : http://opencv.willowgarage.com/documentation/cpp/reading_and_writing_images_and_video.html