Question:
Obtenir des photos correctement exposées et la bonne vitesse d'obturation pour la carte de la caméra RPi à l'aide de raspistill
Vincent Tjeng
2013-12-17 02:09:11 UTC
view on stackexchange narkive permalink

J'utilise mon Raspberry Pi avec la carte caméra RPi pour capturer une vidéo time-lapse de paysages extérieurs à l'aide de la commande raspistill . Comme je télécharge les photos sur un serveur après avoir pris chaque photo, je n'utilise pas la fonctionnalité de time lapse intégrée, mais j'exécute plutôt un cronjob qui exécute ce script toutes les minutes: 

  filename = $ (date + "% d% m% Y_% H% M-% S"). jpgraspistill --width 1280 --height 960 --quality 100 --timeout 500 --encoding jpg -sh 0 -co 0 -br 50 -sa 0 -ev 0 --exposure snow --awb sun --ISO 100 --metering average --nopreview --output $ PROJECTDIR / $ IMAGEDIR / $ filename # un code supplémentaire que j'utilise pour télécharger les fichiers.

Comme j'exécute le même code pour capturer des photos toute la journée et la nuit, j'ai besoin du code pour choisir les vitesses d'obturation appropriées qui permettent à l'image d'être correctement éclairée.

Une approche possible pour obtenir un éclairage constant consiste à fixer une vitesse d'obturation. Cependant, j'ai trouvé que cette approche n'était pas assez générale. Le réglage --ss 1000 , ou une vitesse d'obturation de 1 ms, est idéal pour les jours ensoleillés, mais une vitesse d'obturation au moins quatre fois plus longue est nécessaire pour de bonnes images par temps nuageux (oubliez la photographie de nuit! )

En tant que tel, je dois me fier à la mesure interne de la caméra. Cela me donne un certain degré de flexibilité car il modifie la vitesse d'obturation en fonction de la lumière totale entrant, donnant des photos décentes de jour comme de nuit. Cependant, l'utilisation des paramètres par défaut de l'appareil photo conduit à des images généralement sous-exposées, quelles que soient les conditions. J'ai essayé de jouer avec --ev , --brightness et ainsi de suite, mais les résultats ne sont pas cohérents.

Une approche que je J'ai trouvé que cela fonctionne en modifiant les paramètres --timeout sur la caméra. En général, plus le --timeout choisi est court, plus la vitesse d'obturation est susceptible d'être lente (et plus l'image résultante est lumineuse).

Sans définir une valeur fixe pour la vitesse d'obturation, j'ai constaté que le Raspberry Pi choisit une bonne vitesse d'obturation dans des conditions ensoleillées lorsque --timeout est réglé à 500. Cependant, les jours nuageux et pour la nuit, l'image résultante de --timeout 500 est trop sombre, et je dois réduire --timeout à 200.

Ici est un peu de données sur les vitesses d'obturation choisies par l'appareil photo.

Sunny Days:

  • --timeout 500: exposition 1/1060 s
  • --timeout 200: exposition 1/366 s

Si cela m'aide à télécharger les images, merci de le mentionner dans un commentaire ci-dessous.

Obtenez-vous des résultats similaires lorsque vous utilisez d'autres modes de mesure, par ex. `- matrice de mesure`?
J'ai essayé les comptages «--spot» et «--average» - la documentation n'est pas claire sur leur fonctionnement, mais je pensais que «--average» serait un moyen judicieux de mesurer les images en extérieur. Je suis prêt à essayer matrice aussi une fois que mon Pi sera de nouveau opérationnel.
Si quelqu'un pouvait me diriger vers de la documentation expliquant le fonctionnement du comptage, je serais très heureux aussi :)
Je ne sais pas comment les modes de mesure sont implémentés spécifiquement sur l'appareil photo RPi, mais [essayez] (http://photo.stackexchange.com/questions/4687/when-best-to-use-multi-zone-matrix- spot-or-center-weight) [ces] (http://photo.stackexchange.com/questions/6769/what-is-ansel-adams-zone-system/6774) [links] (http: // photo. stackexchange.com/questions/6598/what-is-the-exposure-triangle/12441) pour mieux comprendre le fonctionnement de la mesure et de l'exposition en général. La mesure moyenne est exactement ce à quoi elle ressemble: ajuster l'exposition pour compenser les zones les plus claires et les plus sombres de l'image.
J'ai suggéré à l'origine la matrice parce que c'est généralement le plus «intelligent» des modes disponibles sur la plupart des caméras. Malheureusement, je n'ai pas encore de caméra Pi avec laquelle jouer, donc je ne sais pas si cela fonctionne bien pour cela.
merci, maniacyak. Je vais essayer de publier quelques exemples d'images que vous pourrez regarder. Au fait, travaillez-vous avec un reflex numérique?
Entre autres caméras, oui! ;)
Un répondre:
sdenton4
2014-01-07 02:13:19 UTC
view on stackexchange narkive permalink

J'ai travaillé sur un peu de code Python pour faire exactement cela. Vous pouvez le trouver ici: https://github.com/sdenton4/pipic Et il y a un exemple de timelapse ici: http://inventingsituations.net/2014/01/01/pilapse3/

Notez que la vitesse d'obturation (SS) et l'ISO sont directement contrôlables avec un firmware récent. (Exécutez sudo rpi-update pour obtenir le dernier firmware et raspistill.) Ces deux éléments influencent la luminosité globale d'une image, et pour obtenir un éclairage cohérent sur un timelapse, vous devrez contrôler directement les deux. Se fier à n'importe quel type d'exposition automatique est mauvais, car l'exposition automatique prendra des décisions différentes pour SS et ISO d'une image à l'autre, ce qui entraînera un scintillement considérable dans votre timelapse. Et vous devriez désactiver la balance des blancs automatique, pour la même raison. (Aussi, je crois que l'utilisation à la fois de --exposure et --ISO conflit; n'utilisez pas --exposure si vous êtes réglage manuel de l'ISO et du SS.)

Je dois également noter que le capteur a tendance à se bloquer si vous lui demandez des photos avec une vitesse d'obturation de plus de 2,5 secondes. (En fait, un peu plus de 2,5 s semble toujours convenir, mais je n'ai jamais eu de problème avec les prises de vue en 2,5 s.) Cela provoque parfois le blocage du capteur si vous utilisez les paramètres d'exposition automatique; depuis le passage au réglage manuel de SS avec un maximum de 2,5 s, je n'ai eu aucun problème avec le verrouillage du capteur; c'est un autre bon argument pour définir manuellement SS et ISO.

Au départ, je faisais une capture d'image basée sur cron, mais je suis passé à l'exécution d'un seul script Python, qui peut mémoriser une collection de valeurs SS et ISO. J'ai alors une commande @reboot dans cron qui démarre le script timelapse.py automatiquement lorsque le Pi s'allume. J'ai également configuré mon programme de timelapse pour ignorer les images qui sont trop éloignées de ma luminosité préférée; cela me permet d'éviter de me retrouver avec d'énormes piles de plans trop sombres du milieu de la nuit. (Je gardais les photos de nuit dans l'exemple lié, cependant, à bon escient!)

Mon approche a été de:

  1. Exécuter une séquence initiale de 'rapide' capture d'image pour trouver une vitesse d'obturation initiale et une sensibilité ISO appropriées. Cela prend généralement environ huit secondes, pour un éclairage standard de la pièce.
  2. Une fois les valeurs initiales connues, ralentissez pour prendre des photos aux intervalles souhaités. Nous conservons une liste de la luminosité des 10 dernières images et ajustons dynamiquement le SS et l'ISO pour maintenir une luminosité moyenne constante.
  3. Je l'ai également configuré pour rejeter des images qui le sont aussi loin de la luminosité souhaitée; cela me permet d'exécuter le timelapse du jour au lendemain pendant des mois sans me soucier de manquer d'espace disque. En calculant la moyenne de plus de dix images, nous évitons que les images aberrantes individuelles aient trop d'effet sur notre SS et notre ISO, tout en étant également sensibles au changement global de l'image (par exemple, au coucher du soleil).

Le code que j'ai écrit est configuré pour augmenter le SS avant d'augmenter l'ISO, car je suis intéressé à avoir moins de bruit de capteur et ne me soucie pas beaucoup du flou de mouvement.

Une autre façon d'attaquer le problème est de faire une analyse de régression sur le capteur de la caméra et d'écrire essentiellement votre propre algorithme de mesure. Mais vous ne voudrez toujours utiliser le comptage que pour obtenir une valeur initiale pour le SS et l'ISO, puis les garder constants ou les changer lentement au fil du temps. J'ai également joué avec cette approche et j'espère publier un article de blog à ce sujet dans les prochaines semaines. Cela devrait me permettre de ramener le temps de préchauffage de huit secondes pour le timelapse à environ 1 seconde.

J'espère que c'est utile!

Salut Tom, il semble que vous ayez implémenté un tas de choses qui m'intéressent! Je me pose plusieurs questions que je voudrais aborder dans des commentaires séparés.
1. Vous mentionnez que vous essayez de maintenir une luminosité moyenne constante; cela signifie-t-il que l'algorithme tente de maintenir la même luminosité globale pendant la nuit et le jour? Cela ne semble pas être le cas depuis le time-lapse que j'ai consulté sur votre site Web. Sinon, comment votre algorithme identifie-t-il le moment opportun pour permettre à la luminosité globale de se réduire?
2. J'ai eu un problème similaire de changement de balance des blancs, même si j'ai réglé «--exposition snow --awb sun». Avez-vous une idée de pourquoi cela se produit? Mon hypothèse est que seule la vitesse d'obturation devrait changer dans cette situation.
3. Votre script Python connaît-il la «dérive» temporelle que je décris ici? http://raspberrypi.stackexchange.com/questions/12249/sleep-in-bash-is-innacurate J'ai décidé d'exécuter mon timelapse en tant que travail cron en conséquence, mais si Python peut donner un degré similaire de précision temporelle (capture images à la minute à chaque minute, je serais très heureux de l'utiliser).
Question 1: J'ai défini une valeur maximale et minimale pour SS et ISO. À chaque photo, le script mesure la luminosité moyenne et tente de changer SS pour obtenir une `` meilleure '' luminosité pour l'image suivante. Mais finalement, surtout pour les photos de nuit, il se heurtera à mon maximum de SS et ISO. Ainsi, vous obtenez des images plus sombres la nuit. Mais avec un maximum d'environ 2 secondes pour SS, 800 pour ISO et une quantité considérable de pollution lumineuse autour de Toronto, je pense que les images de nuit avaient toujours une luminosité d'environ 50 à 70 points, alors que ma luminosité cible était de 100.
Q2: Je pense que la balance des blancs automatique essaie toujours de faire une correction dynamique; il est plus sûr d'utiliser simplement `--awb off`, et potentiellement de faire de la balance des blancs en post-production.
Q3: Les modules de temps Python sont assez précis et plus précis que cron. Dans ma boucle photo, je chronomètre la durée de toutes les opérations (t), puis je lui dis de dormir pendant (disons) 10 t secondes. Cela peut prendre un flotteur et semble faire un excellent travail, du moins selon l'horloge du pi. Une autre possibilité est que l'horloge interne du Pi a juste beaucoup de dérive; une façon de gérer cela est de garder une connexion wifi ouverte et d'exécuter ntpd de temps en temps. Cependant, je n'ai pas mesuré la dérive de l'horloge sur le pi.
Merci pour votre réponse. J'ai voté pour votre réponse, mais je ne marque pas votre réponse comme la réponse acceptée pour le moment, d'autant plus que j'estime que les photos de jour sont légèrement plus sombres que je ne le souhaiterais. Espérons que quelqu'un d'autre qui a réalisé un projet similaire pourra peut-être jeter un œil au problème et fournir un autre point de vue.
Si vous jouez avec le script auquel j'ai lié, il existe une option de ligne de commande pour la luminosité cible (ou vous pouvez simplement changer la variable par défaut dans le script directement). Si vous souhaitez une image plus lumineuse, vous pouvez simplement fournir une valeur différente, entre 0 et 255 - la valeur par défaut est 100.
@sdenton4 Quelle est la nature de ce verrouillage de capteur. J'essaye de faire des expositions plus longues et après googler, je me suis retrouvé ici, et je confirme que si je fais des expositions plus longues, tout le Raspberry Pi devient bizarre et je ne peux pas le redémarrer. Je dois le redémarrer. Une idée de ce que c'est et pourquoi ne pouvons-nous pas résoudre ce problème? : \
Je suppose que le verrouillage était probablement une sorte de dépassement soit dans le code du contrôleur, soit dans le module de la caméra lui-même ... Cela fait des années que je ne l'ai pas regardé ou que je n'y ai pas pensé, et que le matériel de la caméra est vendu car le Pi a un peu changé depuis. Une solution simple pour des expositions plus longues consiste simplement à prendre plusieurs expositions aussi longues que possible et à prendre la somme des images. Cela peut fonctionner tant que les images individuelles ont des pixels différents de zéro ... Bonne chance!


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...