Schnelle Foto-Aufnahmen mit Raspberry Pi Camera

  • Ich möchte mit einem Raspberry Pi 3 Model B+ und der Raspberry Pi HQ Camera (12.3MP) schnell hintereinander mehrere Bilder (z.B. 3 oder 5) mit voller Auflösung (4056x3040) aufnehmen mit unterschiedlichem EV-Wert, um daraus ein HDR-Bild zu generieren. Mit dem standardmäßigen 'raspistill' kann man zwar den EV-Wert vorgeben, aber zwischen zwei Aufnahmen vergehen immer mehrere Sekunden. In dieser Zeit können sich aber Objekte in der Szene (Blätter, Wolken etc.) verändern, so dass das Ergebnis dadurch unscharf würde. raspistill braucht anscheinend bei jedem Aufruf einige Zeit, um Belichtung und Weißabgleich zu ermitteln. Es sollte aber eigentlich reichen, das beim ersten Aufruf zu machen und die ermittelten Werte für die nachfolgenden Aufnahmen zu verwenden.


    Weiß hier vielleicht jemand, wie man möglichst schnell hintereinander Bilder mit dieser Hardware machen kann?

    Oder gibt es vielleicht bessere Methoden, um damit HDR-Aufnahmen zu machen?

  • Hi,

    Hier geht es genau darum :

    https://www.raspberrypi.org/forums/viewtopic.php?t=215343

    Aber ohne wirkliche Fortschritte zumindest bei bewegten Bildern.

    Und hier :

    https://www.raspberrypi.org/forums/viewtopic.php?t=281704

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

    Einmal editiert, zuletzt von SurfaceCleanerZ ()

  • schon das probiert? https://github.com/andyrew/piHDR

    Danke, das sieht schon mal nicht schlecht aus, damit werden die einzelnen Bilder in Abständen von unter 2 Sekunden aufgenommen. Allerdings stimmen die Farben hinten und vorne nicht, aber als Starthilfe zum Experimentieren schon mal nicht schlecht.


    Der im Script enthaltene Aufruf von 'hdrgen' benutzt ein '../picam.rsp', welches leider nicht dabei ist und auch nicht beschrieben ist, wie man das erstellt. Ein Aufruf ohne dieses führt zu


    phdrimg.cpp@564>data: ldr_01.jpg: needs exposure calibration

    hdrgenmain.cpp@187>data: Failure generating HDR image

  • –r cam.rsp

    Use the given file for the camera’s response curves.

    If this file exists, it must contain the coefficients of three polynomials,

    one for each color primary.

    If the file does not exist, hdrgen will use its principal algorithm to derive

    these coefficients and write them out to this file for later use. If a scene

    contains no low frequency content or gradations of intensity, it may be

    impossible to derive the response curve from the exposure sequence.

    Thus it is better to create this information once for a given camera and

    reuse it for other sequences.


    (..)

    The primary failure mode for this algorithm is the one mentioned in the description
    of the –r option, when the exposures contain too little information to
    solve for the camera response function.
    The best solution to this problem is to take off the exposures that are
    very light and very dark, or to use a different sequence of images to generate
    a response file. This file may then
    be used to combine the entire set of images, since the program no longer needs
    to solve for the responses.



    sobald du weißt, wie eine Beispiel Datei aussieht, kannst du die näherungsweise daran fitten:


    https://github.com/bluegreen-l…berry_pi_camera_responses

  • https://discourse.radiance-onl…61dca6aa11f415551db16.htm


    Zum File Format..


    The first number in each line in an RSP file is the order of the polynome.

    Here's canon_5D.rsp after hdrgen is run:


    3 1.49643 -0.979 0.486712 -0.00413976

    3 1.44009 -0.884479 0.448854 -0.00446749

    3 1.46366 -0.875187 0.414554 -0.00303108

  • Nach längerer Zeit komme ich endlich mal wieder dazu, mich mit diesem Thema zu beschäftigen.

    Mit den rsp-Daten aus #8 (danke wirbel) als "picam.rsp" abgespeichert bekomme ich mit drei Jpeg-Dateien, aufgenommen mit ev -6, 0, +6 bei


    ./hdrgen -a -r picam.rsp -o hdr.tif hdr--6.jpg hdr-0.jpg hdr-6.jpg


    die Meldung "hdr--6.jpg: needs exposure calibration [...] Failure generating HDR image"

    Ich muss vor den Dateinamen der Jpegs jeweils eine Option "-s stonits" angeben, etwa


    ./hdrgen -a -r picam.rsp -o hdr.tif -s 0.8 hdr--6.jpg -s 0.4 hdr-0.jpg -s 0.2 hdr-6.jpg


    Damit wird eine Ausgabedatei erzeugt, die aber weit davon entfernt ist "HDR" zu sein.

    Das liegt wohl daran, dass (offensichtlich) die rsp-Daten ja nicht zur Kamera des RasPi passen (ich verwende die 12.3MP Kamera mit IMX477 Sensor) und ich keine Ahnung habe, welche Werte für die "stonits" zu verwenden sind. Die Doku (siehe Link in #8) sagt dazu nur "simply pick a value for the brightest image, and increase it subsequently for each exposure in the sequence. One f-stop requires doubling this conversion factor, and two f-stops requires quadrupling".

    Im Web habe ich leider keine rsp-Daten für die verwendete Kamera gefunden, und auch keine weiteren Hinweise, welche Werte für die "stonits" passen.


    Weiß hier vielleicht jemand näheres dazu?

  • Soweit die manpage verständlich ist, wäre der Weg zur korrekten rsp Datei, eine nicht existierende anzugeben, welche das Programm dann dort selbst ablegt (d.h. wenn alle anderen Optionen stimmen).


    Dieses stonits scheint eine relative Angabe zu den Schritten der F-Zahl des Objektivs (Blendenöffnung bzw. Lichtmenge auf dem sensor). Falls die picam exif statt jpeg kann, würde der Wert da drin stehen.

  • btw. solltest du die Werte sogar berechnen können aus diesen Kamera Werten bei der Aufnahme :

    * shutter_speed

    * analog_gain

    * digital_gain

    * awb_gains


    https://picamera.readthedocs.i…elease-1.12/recipes1.html

  • Soweit die manpage verständlich ist, wäre der Weg zur korrekten rsp Datei, eine nicht existierende anzugeben, welche das Programm dann dort selbst ablegt (d.h. wenn alle anderen Optionen stimmen).

    Drei Fotos haben anscheinend nicht gereicht. Ich habe es jetzt mal mit 5 Fotos (ev -12, -6, 0, +6, +12) probiert und da hat er eine rsp-Datei erzeugt:

    Code
    1 0.906286 0.0937142
    1 0.921759 0.0782411
    1 0.916837 0.0831626

    Der Aufruf


    ./hdrgen -a -r picam.rsp -o hdr.tif -s 8 hdr--12.jpg -s 6 hdr--6.jpg -s 4 hdr-0.jpg -s 2 hdr-6.jpg -s 1 hdr-12.jpg


    erzeugte dann auch ein Bild, das aber nicht wirklich nach HDR aussieht. Ich hänge mal einen Screenshot der Quell-Fotos und des Resultats an. Vielleicht erkennt ja jemand, was da noch im Argen liegen kann.

  • Mit den rsp-Daten aus #8 (danke wirbel) als "picam.rsp" abgespeichert bekomme ich mit drei Jpeg-Dateien, aufgenommen mit ev -6, 0, +6 bei

    Ich habe es so verstanden , dass man OHNE "picam.rsp" mit den 3 Bildern so eine rsp-Datei erstellen soll.

    (Im Prinzip wie Panotools die Objektiv-Korrektur-Parameter für Verzerrungen usw. aus überlappenden Aufnahmen berechnet. Damit könnte man übrigens die Fisheye-Aufnahmen auch in eine "bessere" Projektion umrechnen.)


    Dazu müssen die Aufnahmesequenz aber geeignet sein. Das Motiv sollte also jeden Farbkanal des Sensors, komplett abdecken.

    Ich würde mir da die Histogramme der einzelnen Aufnahmen mal ansehen. Da sollte jeder Farbkanal von hell bis dunkel gut belegt sein.

    Was man da am besten an Motiv nimmt, bin ich aber überfragt, ich mach nicht so viel mit HDR. Ich schätze aber, Kontrast bei allen Helligkeitsstufen ist auch wichtig.

    Die Auswahl der Aufnahmesequenz scheint wohl kein Selbstläufer zu sein:

    Zitat

    If a scene contains no low frequency content or gradations of intensity, it may be impossible to derive the response curve from the exposure sequence.  Thus it is better to create this information once for a given camera and reuse it for other sequences.


    Ich schätze, das Problem liegt in den Aufnahmen.

    Die Korrekturkurve in der .rsp-Datei ist auch nur eine Gerade. Das ist verdächtig, so gut kann die Kamera eigentlich nicht sein.


    Zunächst würde ich bei den Bildern mal den Rand abschneiden, der verwirrt den Algorithmus nur.

    Das Bild hdr-12.jpg ist auch derart überbelichtet, dass man es streichen kann.

    Bild hdr-6.jpg liefert auch nicht viele Informationen. (Ist bei der "Grösse" aber schwer zu beurteilen.)

    Generell könnten die Wolken etwas wenig Kontrast haben.


    Um wirklich sagen zu können, was los ist, bräuchte man aber das Ausgangsmateriel.


    und ich keine Ahnung habe, welche Werte für die "stonits" zu verwenden sind.

    Haben die jpeg-Dateien wirklich keine Exif-Info integriert?

    So wie ich es verstanden habe wird diese "stonits" üblicherweise daraus generiert. Und mir ist noch keine Kamera untergekommen, die die Exif nicht integriert.


    "stonits" sagt mir zwar nichts, nach der Beschreibung und Einheit (cd/m²) klingt mir das nach Beleuchtungsstärke. Es müsste sich also analog zum Blendenwert, bzw. Belichtungsdauer verhalten.
    Hilft aber auch nicht, wenn man die nötigen Daten nicht hat.


    Ob man mit den "ev"-Werten allein was anfangen kann?

    Eine Erhöhung um 1 EV entspricht einer Halbierung der Lichtmenge, eine Verringerung einer Verdopplung.

    Bei der Korrektur bezieht sich das immer auf die von der Kamera gewählten Werte und wenn man die nicht hat...

    Man hätte immerhin die Verhältnisse der Aufnahmen, da weiss ich aber nicht, ob das reicht.


    Entsprechend angewendet, sehen die Werte vom Pi aber komisch aus. 2^12=4096, das kann eigentlich nicht passen.


    Ich befürchte, man muss wohl alle Werte (Blende, Zeit, ISO, ...) hart vorgeben, wenn man selber rechnen will. Allerdings stelle ich mir das bei wechselnden Lichtverhältnissen schwierig vor.


    Der Raspi kann generell wohl Exif. Es hängt aber wohl von der Aufnahme-Methode ab.

    No Exif information is embedded in JPEG images captured through the video-port.

    Man sollte die Exif-infos in die Bilder zu bekommen, sonst tut man sich bei der Nachbearbeitung echt schwer.

    Da piHDR die "stonits" auch nicht vorgiebt, nehme ich an, dass die da drin sind. Daher ist das, denke ich, der richtige Weg.


    Ich persönlich würde es mit "Hugin" (ein grafisches Frontend zu Panotools) versuchen, mit dem Programm habe ich schon einiges gemacht. Das kann auch Belichtungskorrekturen und HDR und du hast ja quasi eine Panprama-Aufnahmen ohne Bild-Versatz gemacht ;).

    Da ist auch ein Tool zur Linsenkalibrierung dabei. Wenn du Glück hast, reichen die geraden Linien in den Aufnahmen dazu.






    Gruss
    SHF


  • Hi,

    Vor Jahren habe ich mal gute Aufnahmen mit Helicon Focus gemacht. Evtl hilft das weiter. Läuft standalone oder als Filter (Photoshop) in z. B. XNView.

    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Ich habe jetzt mal neue Fotos (bei Sonnenschein) gemacht, den Rand weggeschnitten und mit


    ./hdrgen -F -a -r picam.rsp -o hdr.tif -s 3 cldr--6.jpg -s 2 cldr-0.jpg -s 1 cldr-6.jpg


    ohne existierende rsp-Datei folgende "picam.rsp" erhalten:

    Code
    3 1.35139 -1.73392 1.30848 0.0740541
    3 1.41096 -1.79354 1.35062 0.0319624
    3 1.52995 -1.90005 1.34595 0.0241512

    Als stonit-Werte habe ich 3, 2 und 1 genommen, da ja jeweils ein f-Stop Unterschied zwischen den Fotos ist (wenn ich das richtig sehe).

    Das Resultat sieht gar nicht mal so übel aus, ist aber leider ziemlich "blass".

    Haben die jpeg-Dateien wirklich keine Exif-Info integriert?

    Doch, haben sie. Aber anscheinend reicht das nicht:

  • One f-stop requires doubling this conversion factor, and two f-stops requires quadrupling.


    ..jeweils ein f-Stop Unterschied zwischen den Fotos ist


    verstehe ich als 4,2,1

  • Das Resultat sieht gar nicht mal so übel aus, ist aber leider ziemlich "blass".

    Nach meinem Verständnis braucht man für ein ansehnliches HDR-Bild noch einen weiteren Schritt - da die generierte Tiff-Datei einen größeren Farbraum hat als ihn gängige Monitore darstellen können (die besseren sind im Bereich von 10-12 Bit pro Farbkanal, was auch schon extreme Helligkeitsunterschiede erfordert), nutzt man Tone Mapping, um das Bild auf dem kleineren Farbraum des Bildschirm ansprechend abbilden zu können - und das ist sehr vom eigenen Geschmack abhängig, welchen Weg man dabei geht.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Inzwischen habe ich herausgefunden, dass das Ergebnis wesentlich besser wird, wenn man hdrgen eine *.hdr-Datei (und nicht direkt *.tif) erzeugen lässt, und diese dann mit 'convert' in TIFF konvertiert. Ich werde noch ein wenig mit den stonits experimentieren und dann ggf. weitere Erkenntnisse hier posten.

  • Raspberry Pi HQ Camera (12.3MP)

    Das Modell mit dem Schraubobjektiv und IMX477R Sensor?

    Und als Objektiv das 6mm Weitwinkel?

    Nur dass es keine Missverständnisse gibt.


    Das Modul hat jedenfalls keine Blende.

    Das Objektiv zwar schon, aber die ist nicht per Software beeinflussbar.

    Man kann die Blende also als fest betrachten und weiterhin ignorieren.


    Die EXIF-Daten sehen mit dem Hintergrund eigentlich auch gut aus.

    Die Linsenparameter fehlen, aber sonst scheint alles wichtige da zu sein.

    Belichtungszeit und ISO sind angegeben, die Blende fest, damit müsste am arbeiten können.


    Eventuell muss man die Linse auch irgendwie konfigurieren und hat dann die Linsenparameter EXIF-Daten?

    Ist ja schliesslich ein Originalzubehör.
    Bei piHDR klappt das ja auch, allerdings haben die wohl ein anderes Kameramodul verwendet "IMX219".

    Ich würde mich generell am Vorgehen von piHDR orientieren.

    Die schiessen die 6 Fotos mit vorgegebener Zeit, festem Weissabgleich und ISO-Wert.

    So liessen sich die stonits notfalls errechnen.


    Ob das mit den "ev" Werten vom Raspi geht habe ich Zweifel.

    Der Bereich +-12 ist für meinen Geschmack auch etwas gross. Üblich ist +-2 vielleicht +-4.

    Ich habe da irgendwie die Befürchtung, dass die Daten von einer Belichtungsserie, nicht zur nächsten passen.


    Auch bei der Nachbearbeitung würde ich mich an piHDR orientieren.

    Nach dem ersten Aufruf sollten die Fotos vorliegen, da kann man abbrechen und die Aufnahmen für weitere Versuche verwenden.


    Entweder könnte man nun den Aufruf von "hdrgen" anpassen oder man fügt einen Fake-Blendenwert bei den Aufnahmen hinzu und schaut, ob es dann geht.


    Da sich die Blende nicht ändert, kann bei allen Aufnahmen immer er gleiche Wert genommen werden. Bei raspistill soll es einfach gehen Exif als Parameter zu übergeben. Bei der Python-API müsste man mal schauen.

    Gruss
    SHF


Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!