éditer: résolu! S'il vous plaît voir ma réponse ci-dessous pour plus de détails.
J'ai été incapable de trouver une réponse à la question initiale, mais j'ai trouvé une solution alternative Cette question peut être posée quelque part ailleurs, mais je cherche des jours et je ne trouve rien qui aide. question: Je dois convertir "flux" à "image (BGR, octet)" en une fois, y a-t-il un moyen / commande à convertir directement de System.Drawing. Image.fromstream to emgu.cv.image (BGR, octet) sans conversion de flux à image to bitmap to Image (BGR) , octet) ? Information: Je codiste dans C # dans Visual Studio 2010 dans le cadre de mon projet de thèse.
Je prends une source d'image d'une caméra IP sur un réseau et j'applique de nombreux algorithmes pour détecter les faces / extraire des caractéristiques du visage et reconnaître une face aux individus. Sur la caméra locale des ordinateurs portables, je peux réaliser des fps d'environ 25 ~ (donner ou prendre), y compris des algorithmes, car je n'ai pas à convertir l'image. Pour un flux de caméra IP, j'ai besoin de le convertir plusieurs fois pour obtenir le format souhaité et le résultat est d'environ 5-8fps. (Je sais que ma méthode actuelle est extrêmement inefficace, c'est pourquoi je suis pourquoi je suis ici, Je suis en train de convertir une image 5 fois totale (même gris à l'échelle grise), en réalité uniquement à la moitié de la mémoire de mes processeurs (I7, 8 Go de RAM)). Il doit être image (BGR, octet) car c'est le seul format que les algorithmes fonctionneront avec. Le code que j'utilise pour obtenir l'image: J'ai beaucoup de choses dans la gestion de l'arrière-plan Connexions, données, sécurité, etc. que j'ai raccourci au code ci-dessus.
Mon code actuel pour couvrir l'image à la sortie souhaitée: Je comprends une méthode permettant d'enregistrer une image sur place temporairement, mais je devrais éviter cela à des fins de sécurité. Je cherche plus pour une conversion directe pour économiser de la puissance de traitement.
Suis-je surplombant quelque chose? Toute aide est appréciée. Merci de la lecture. (Je vais mettre à jour cela si quelqu'un demande plus de détails)
-Dave
3 Réponses :
Vous pouvez enregistrer plusieurs images dans la mémoire (tampon), puis commencer le traitement de la mémoire tampon.
quelque chose comme ceci: mais note que vous aurez besoin de suffisamment de bélier Pour stocker des images en mémoire et également, vous devez ajuster la taille du tampon à la viande de vos besoins.
C'est une idée décente, je vais rechercher les méthodes de conversion de la mémoire. J'ai de bonnes spécifications de RAM afin que je puisse être capable d'essayer cette méthode.
Vous avez quelques goulots d'étranglement potentiels, ce n'est pas le moindre dont vous êtes probablement en train de décoder le flux dans une image et de la convertir dans une image bitmap, puis dans une image OpenCV.
Un moyen de contourner cela consiste à contourner l'imagerie .NET entièrement. Cela impliquerait de tenter d'utiliser libjpeg directement. Il y a un le port gratuit de celui-ci ici en C # et IIRC vous pouvez vous y connecter pour être appelé à une personne Scanline base pour remplir un tampon.
L'inconvénient est que vous décodez les données JPEG dans un code géré qui fonctionnera d'au moins 1,5 fois plus lentement que l'équivalent que l'équivalent, même si franchement, je m'attendrais à ce que la vitesse du réseau soit naine.
OpenCV devrait être capable de lire des images JPEG directement (tu veux deviner ce qu'ils utilisent sous la hotte? Enquête indique: libjpeg), ce qui signifie que vous pouvez tamponner tout le flux et la remettre à OpenCV et contourner la couche .NET entièrement .
je crois que j'ai trouvé la réponse à mon problème . J'ai barbouillé en utilisant Ce que je pense est ma cause est la vitesse de réseautage! pas le retard d'algorithme réel. Comme indiqué par Vano avec le chronomètre pour trouver la vitesse, les algorithmes ne consomment réellement que beaucoup. Donc, avec et sans les algorithmes, la vitesse est à peu près la même si j'ose optimiser à l'aide de la filetage afin que la trame suivante soit collectée car le précédent terminer le traitement. J'ai fait des tests sur certains routeurs de Cisco et obtenu même résultat si un peu plus ralentissé rond rond avec des vitesses d'horloge et des largeurs de bande qui était perceptible. J'ai donc besoin de trouver un moyen de récupérer des cadres sur les réseaux plus rapidement, très grand merci à tous ceux qui ont répondu qui m'a aidé à mieux comprendre! Conclusion:
Pouvez-vous utiliser la classe de chronomètre pour mesurer chaque performance des lignes? (pour les 3 dernières lignes)
Je n'ai pas utilisé cela pour mesurer les performances, mais si vous me donnez un moment, je vais gifler quelque chose ensemble et comment revoir. Les 3 dernières lignes réside dans la mise en place de 5 conversions, dessinant à une image ImageBox et rendant des sorties d'algorithme lors de la prête à l'image suivante.
@Vanomaisuradze La classe de chronomètre indique qu'il a pris 00: 00: 00: 0343616 pour compléter la tâche pour ces 3 lignes en particulier (pensez que c'est en millisecondes).
Quel type d'image obtenez-vous de la caméra? Je soupçonne que c'est JPEG.
Avez-vous envisagé / essayé d'utiliser plusieurs cœurs?
Je n'ai pas eu de barbaire à la transformation multi-noyau, mais je suis conscient qu'il existe, l'image de la caméra à laquelle je pense arrive en tant que JPEG ou MJPEG.
@ Lassev.karlsen Après un peu de recherche, j'ai remarqué que l'utilisation d'un traitement multi-noyau Il provoque un verrouillage à 100% de la mémoire de processeurs et la fait chauffer beaucoup si sous beaucoup de tension, mais vous pouvez accomplir des tâches 3 fois plus rapidement en moyenne. Je vais donner cela quelques tests ~