Panorama Community

Zitat von »mhc1«

könnte es sein, das die modernen Kameras intern bessere Optimierung durchführen als man manuell hinterher erreichen kann ?????

Kann ich nicht bestätigen!!
Von den JPEG´s, die die K10D in den Grundeinstellungen produziert, bin ich persönlich enttäuscht.
Jetzt könnte man hingehen und die Einstellungen anpassen... aber ich glaube dann wäre ich je nach Motiv nur am einstellen und rumfummeln.

Ich leiste mir deshalb den Luxus, erst nachträglich die Enstellungen zu verändern und auch erst nachträglich selber zu bestimmen welche Stelle ich abwedele oder aufhelle.
Ich möchte garnicht das mir die Kamera die Entscheidung abnimmt, welche Pixel automatisch bearbeitet werden sollen.
Eine einmal intern entwickelte z.B. abgesoffene Stelle kann man bei JPEG´s nicht mehr retten, weil einfach die Bildinformationen wegentwickelt worden sind.

Natürlich ist das evtl. Mehrarbeit... aber wie schon geschrieben: I my digitale Dunkelkammer.

Automatiken, machen IMHO Sinn wenn sie einen lästige Arbeit abnehmen.
Keinen Sinn machen sie wenn sie nicht meine Vorstellungen an das Bild erzeugen.

Letzendlich muss aber jeder seinen eigenen Workflow finden.

Gruß
Ralf

 

Zitat von »mhc1«

könnte es sein, das die modernen Kameras intern bessere Optimierung durchführen als man manuell hinterher erreichen kann ?????

Bei den Kameras, mit den ich intensiver Kontakt hatte (speziell Canon DSLR) finde ich deutliche Vorteile im RAW, speziell wenn es um das retten ausbrennender Lichter geht. Ist ja irgendwie auch klar, wo im JPEG 5 Stufen für die Tonwerte 250 bis 255 zu Verfügung stehen, einer davon ist reinweiß, habe ich im RAW je nach Bittiefe der Kamera 80 und mehr Stufen (eine davon reinweiß) das man dort eine feinere Differenzierung hinbekommen kann, sollte logisch sein.

 

Zitat von »mhc1«

Z.Bsp: zeigt meine D80 in der Vorschau ein otimiertes JPD - egal was immer ich einstelle. Speziell in Lichtkritischen Situationen sieht dieses Bild deutlich besser aus als ich es mit allen erdenklichen Mitteln selber machen kann. (Das JPG auch) Ich meine in Bezug auf D- Lightning und Entrauschen usw. ist das JPG Bild so derbe gut, das es nur noch der WA ist, der für das RAW spricht. edit:

Das kann an der guten D80 oder Deinen schlechten RAW-Umsetzungen liegen, such Dir was aus. ;-)

Zitat von »mhc1«

Ich werde in Zukunft mal Teste mit JPG & RAW aufnehmen. Mal sehen, was der Unterschied tatsächlich ist.

Mach das mal mit kritischen Situationen mit dem Hang zum Ausbrennen. (Sonne mit weißen Wölkchen)
Manches kann man dann zwar aus dem JPEG noch retten, man bekommt aber oft Probleme mit Posterization, so dass die geretteten Bereiche kontrastreicher /härter aussehen als im RAW.

Zitat von »Rajko«

Welche Programme nutzt ihr für die RAW Verarbeitung?

Lightroom, Bridge, Lightzone, RAW-Shooter Essentials.
Heutzutage wegen das angenehmeren Workflows aber fast nur noch Lightroom.

Zitat von »'Tom!«

Lightroom, Bridge, Lightzone, RAW-Shooter Essentials.
Heutzutage wegen das angenehmeren Workflows aber fast nur noch Lightroom.

Ist der workflow in Lightroom wirklich mindestens genauso gut und "effekiv" wie es im RSE ist (war) ??

Dann muss ich mir das Ding echt mal installieren...

Ist Lightroom auch genauso schnell ( bei gleicher HW natürlich) ?
Kann man - wie im RSE - eine bachentwicklung im Hintergrund laufen haben und gleichzeitig andere Bilder bearbeiten und "vorbereiten" ?

Sind die Bilder der K10D aus Lightroom auch genauso gut wie aus dem Pentax Lab ( das leider nicht gut ist im workflow...)

RSE kann ich ja leider nicht mehr nutzen mit der K10, war aber begeistert vom workflow im RSE mit den istDs RAWs...

Danke für weitere Erfahrungen!

Zitat von »soulbrother«

Sind die Bilder der K10D aus Lightroom auch genauso gut wie aus dem Pentax Lab ( das leider nicht gut ist im workflow...)

Ich habe einmal in das Pentax Lab reingeschaut... 1 Bild probiert und gleich wieder deinstalliert.
Alle RAWs der K10D mache ich jetzt entweder mit ACR oder eben LR und bin sehr zufrieden, auch mit dem Workflow.

Gruß
Ralf

Ich habe jetzt mal ein Pano zum Vergleich gemacht:

Keine Diskussion - RAW ist besser, weil man die Werte besser anpassen kann.
Der Unterschied ist zwar gering und hat seine Ursache der Schwelle des Entrauschers.

Vergleichsweise habe ich gleiche Einstellungen als RAW & JPG (neutral) aufgenommen.
Büro mit Fenster und Deckenstrahler.
Mit Nikon Capture NX leichtes D- Lightning (Fast 10% Color Boost 60%)
und leichtes Entrauschen (Fast: 17% Sharpness 5%)
Kamera (Jpg): Bildoptimierung: Neutral   Langzeitbel: ON, Hohe ISO : HIGH

Ergebnis:
Das JPG war "Glatter" - weil der interne Entrauscher staärker gearbeitet hat.

Ansonsten waren die Bilder erstaunlicherweise ziemlich gleich.

Dadurch, das man die Werte für D- Lightning und Entrauschen (natürlich auch WA) sehr fein einstellen kann - und man 16 Bit TIF als Ergebnis hat ist es keine Frage ob JPG oder RAW : RAW.

Zitat von »mhc1«

Ansonsten waren die Bilder erstaunlicherweise ziemlich gleich.

Ja das ist es, was ich damals auch festgestellt habe (neuen Test habe ich noch nicht gemacht). Allerdings bin ich dadurch auch nicht weiter in die Tiefe gegangen bei dem Thema, sondern gleich beim JPEG Format geblieben.

Dazu noch eine Frage:

Bekanntlich kann man aus einem RAW z.B. scheinbar abgesoffene Bildteile noch retten. Nun stelle ich mir mal einen Innenraum mit einem hellen Fensterbereich an der einen,- und einer dunklen Ecke an der anderen Seite, vor. Bei den überstrahlten Fensterbereichen könnte ich im entsprechenden RAW Bild die Werte nun so anpassen, daß wieder Zeichnung zu erkennen ist und man vielleicht sogar durch`s Fenster sehen kann. Diese Werte muß ich doch aber konstant auf alle weiteren Bilder (auch auf die der dunklen Ecke) übernehmen, oder sehe ich da was falsch? Dann wäre das Fenster zwar ideal, aber meine dunkle Ecke wäre dann komplett schwarz.

Kann man ein RAW Bild auch nur an ausgewählten Bereichen (z.B. Fenster) bearbeiten? Ich kenne das nur so, daß man das RAW Bild entwickelt und später dann z.B. in Photoshop weiter bearbeitet. Dann ist das Format allerdings schon TIFF o.ä. und nicht mehr RAW. Also ab da kann man ja dann auch schon nicht mehr das RAW Potenzial nutzen.

 

Gruß Rajko

Zitat von »soulbrother«

Ist der workflow in Lightroom wirklich mindestens genauso gut und "effekiv" wie es im RSE ist (war) ??

Nach meinem Empfinden: Deutliches Ja!

Zitat von »soulbrother«

Ist Lightroom auch genauso schnell ( bei gleicher HW natürlich) ?

Schwer zu vergleichen, den Lightroom ist ja zusätzlich eine hervorragende Datenbank. Die beiden Anwendungsbereiche können sich tempomässig in die Quere kommen. Wenn ich nur den RAW-Konverter beachte (ohne Datenbankaktivität), würde ich sagen: gleiches Tempo

Zitat von »soulbrother«

Kann man - wie im RSE - eine bachentwicklung im Hintergrund laufen haben und gleichzeitig andere Bilder bearbeiten und "vorbereiten" ?

Ja, das geht, es gehen auch mehrere Batchgruppen im Hintergrund. Würde ich aber, wenn es um Tempo geht, vermeiden, da die Jobs dann parallel ablaufen und im unglücklichsten Fall erst gleichtzeitig nach der nötigen Gesamtzeit fertig sind.

Zitat von »soulbrother«

Sind die Bilder der K10D aus Lightroom auch genauso gut wie aus dem Pentax Lab ( das leider nicht gut ist im workflow...)

Kann ich nicht beurteilen, für meine Canon-Bilder bin ich zufrieden.

Zitat von »Rajko«

Bekanntlich kann man aus einem RAW z.B. scheinbar abgesoffene Bildteile noch retten.

RAW ist keine EierlegendeWollmilchsau.

Über die Vorteile/Nachteile die RAW hat ist eigentlich alles gesagt.
Was du ansprichst ist schon die weitere Bearbeitung, z.B. in PS

Du kannst ja aus dem RAW-Bild mehrere Versionen abspeichern.
Anschliessend werden in PS z.B. mit Masken und Ebenen die Bilder zusammengeführt bez. die Problemzonen bearbeiten.
Diese Schritte sind in der Regel für einzelne Bilder.

Bei Panoramen sollten natürlich alle Bilder einer Serie in den Workflow eingeschlossen werden.
Aber auch hier fünktioniert das Bearbeiten wie bei den Einzelfotos, nur das man eben die Einstellungen auf die jeweilige Serie anwendet.

Gruß
Ralf

Nach den ganzen Beifallsmeldungen fuer PTGui habe ich das jetzt auch mal probiert (hatte ich schon lange vor ) - mit einem Pano, mit dem ich zuletzt ein paar Schwierigkeiten in Hugin hatte. In Hugin hat's auf Anhieb gepasst, aber irgendwie war es ungenau - ich hatte recht viele Kleinigkeiten nachzuarbeiten.

Meine Erwartungshaltung:
Es wird etwas schneller rechnen, etwas besser die Kontrollpunkte finden, etwas besser blenden und etwas komfortabler sein.
So wie bei Dieter, einfach rein und staunen.

Mein Fazit:
Automatisch geht gar nicht. Meine Bilder kommen ungedreht aus der Kamera und somit steht das Pano dann auf dem Kopf. Statt das zu korrigieren dachte ich, ich waere auf dem richtigen Weg die Bilder direkt im images Tab alle zu drehen. Dann kommt aber nur Durcheinander raus. Wenn ich dann mit dem panorama editor die Bilder an die richtigen Stellen zupfe, eine paar offensichtlich falsche Punkte loesche und nochmal mit allem optimiere kommt zumindest ein scheinbar richtiges Kugelpano raus - bleibt aber bei ("This is Bad"). Wenn ich mir die Linsenparameter anschaue, dann hat sich da eine Brennweite von 5-6mm bei crop 1,53 eingeschlichen - das kann ja nicht gehen. Brennweite korrigiert, neu optimiert, wieder alles durcheinander.

Mein Fazit:
Die Wunderwaffe fuer Beginner ist das auch nicht - man kann sich als Unwissender in der Bedienung genauso verzetteln wie mit Hugin oder anderen Tools auch. Es muss mindestens genauso gut gehen wie in Hugin, das ist klar. Irgendwie stehe ich so wie mit Fernbedienung davor und treffe nicht die richtigen Knoepfe. Aber fuer heute reicht's mir erstmal.

Eins ist mir klargeworden (habe ich mir vorher auch schon gedacht):
Wenn hier jemand ueber Hugin, PTGui, Realviz Stitcher oder sonstwas schimpft, weil er damit nicht zum Ziel gekommen ist, dann liegt das zu 90% an der Person und daran, wie gut sie diese oder andere Software kennt und fast nie am Tool. So ein Kurztest (PTGui -Trial gegen Hugin) bringt somit m.E. fuer Einsteiger kein aussagekraeftiges Fazit zusammen.
Hugin finde ich nun gar nicht mehr so unkomfortabel. Der Komfort besteht einfach darin, das es nicht so ueberfrachtet ist und man direkt an alles dran kommt.

Zitat von »soulbrother«

Habe gestern abend mal schnell PTgui 7 auf meinem kleinen Laptop (1,1GHz) installiert, eine Reihe jpgs rein (5+1) und das vollautomatische Ergebnis war - mit diesen Bildern- "erschreckend" gut: Wirklich gut gesticht und geblendet und sogar etwas schneller als hugin auf meinem schnelleren PC (3 GHz)

Aufgepasst,
wenngleich ich mir vorstellen kann, dass PTGui in der Tat etwas schneller stitch und blendet: Wenn Du Hugin und Deinen grossen PC mit JPG's fuetterst wird das auch 'ne ganze Ecke schneller.

Ich bin mal gespannt auf dene Test's von PTGui auf aleteren schon fertigen Panoramen.
Mein erster Test war eher entmutigend, aber ich werde es nochmal probieren.

best, mike

Moin Mike

Ich musste schon einwenig schmunzeln, bei deinem PTGui Test.
Das gleiche Schlüsselerlebniss hatte ich übrigens als ich Hugin ausprobiert habe.

Ich muss dir aber recht geben, das mangelnde Programmkenntniss die grösste Fehlerquelle ist.
Erfahrungen und AHA-Erlebnisse sind ebenfalls wichtig für ein gutes Ergebniss.

Gruß
Ralf

Zitat von »Blockbuster«

Ich musste schon einwenig schmunzeln, bei deinem PTGui Test. Das gleiche Schlüsselerlebniss hatte ich übrigens als ich Hugin ausprobiert habe.

Na ja,
das ist klar und das war auch genauso zu erwarten. Was mich irritiert hat sind die ganzen Convenient functions.
Ich hab's mittlerweile nochmal probiert, den Simple Mode ad acta gelegt und bin auch durch gekommen.

Es geht auch ohne die Bilder in Portrait zu drehen (muss ja auch). Einfach roll fuer alle auf 90 und gut.
Kontrollpunkte bekomme ich mehr als mit Autopano-sift + Ransac, aber schlechter verteilte als mit Autopano-Sift OHNE Ransac und spaeterem Rausloeschen falscher Punkte. Moeglicherweise ist hier noch eine Verbesserung moeglich, wenn man die Bilder gedreht vorhaelt?!

Beim Optimieren komme ich auf aehnliche Werte wie mit Hugin. Auch die Passgenauigkeit ist aehnlich. Das fertige Panorama hat Probleme an genau den gleichen Stellen wie mit Hugin, lediglich der PTGui-Bender kaschiert die Probleme etwas besser als enblend. Hier muesste man zum Vergleich nochmal smartblend heranziehen, was in solchen Situation schon mal besser ist als enblend.

Kontrollpunkte ueberpruefen geht mit Hugin schoener. Dort kann ich den Kontrollpunkttab und die Kontrollpunktliste nebeneinander aufhaben und muss in der liste nur anwaehlen um den Punkt in den Bilder zu sehen. Bei PTGui muss ich hier dauernd wechseln (bei Doppelklick).

Der Schnellpreview in Hugin ist etwa dem Panoramaeditor in PTGui entsprechend - wobei Hugin nicht die Einzelbilder grafisch verschieben kann (was ich aber nur sehr, sehr selten brauche).

Markant schneller fand ich uebrigens weder den Stitch, noch das Blenden. Kontrollpunkte finden ging etwas fixer, aber auch nicht im atemberaubenden Bereich.

Was mit Sicherheit schoener geloesst ist, ist das Einbinden zusaetzlicher (nicht 100% nodalgerechter) Bodenbilder (Viewpoint).

Mein Fazit nach dem zweiten Anlauf:
Kann ich auch mit arbeiten, aber deutlich schneller oder besser werde ich so vermutlich auch nicht. Wie bei vielen Tools ist es auch ein bisschen eine Filisofie-Frage (aehnlich wie Latex vs. Word): Liegt es mir mehr verschiedene dedizierte Knoepfe und Funktionen auszuprobieren oder erarbeite ich mir lieber das Basisverstaendnis. Letzteres hilft bei beiden Tools, ersteres geht nicht bei jedem Tool und faellt manch einem vielleicht leichter.

Hugin hat definitiv ein paar Stolpersteine mehr. Das faengt einfach damit an, dass die beste Moeglichkeit Kontrollpunkte zu finden nicht fest integriert ist und die verfuegbare Loesung (Autopano-Sift mit vbs-Script) auch noch einen (korrigierbaren) Fehler hat. Beim Optimieren mit Hugin sollte man ein Lenstemplate benutzen oder schrittweise vorgehen. Fuer manch einen mag Hugin ueberschaubarer sein. Die Funtionsvielfalt von PTGui ist schon enorm und fuer Neulinge mag das teils auch eher verwirrend sein?!

Markant schneller wird man aber nicht durch ein anderes Tool, sondern durch einen besseren Workflow.

Zitat von »trozzreaxxion«

Es geht auch ohne die Bilder in Portrait zu drehen (muss ja auch). Einfach roll fuer alle auf 90 und gut.

Oder noch einfacher im Register Project Assitent ganz rechts unter <<< Simple die Pfeile zum drehen verwenden. Das Funktioniert auch, nach dem Kontrollpunkt finden, wenn das Panorama auf dem Kopf steht.

Gruß
Tobias

Zitat von »Malum«

Dann vielleicht die PTGui-Basics:

Alle Bilder müssen im Hochformat vorliegen.
Beim Einladen der Bilder immer Lens Type, Crop Faktor und Brennweite im Popup-Fenster eingeben, das sollte ja bekannt sein, dafür Auto abschalten. Auto-EXIF-Funktion- funktioniert z.B. fehlerhaft mit mit meiner Nikon.
Drehen des Panoramas durch Eingabe von "180" in Pitch oder Roll (123-Button im Panorama-Editor), wenn das Panorama auf dem Kopf steht. Passiert immer mal wieder.

Geraderücken:
Im Control-Punkt Editor 2x dasselbe Bild auswählen, jeweils einen Punkt oben und unten auf einer senkrechter Linie setzen, mindestens 2 senkrechte Linien so markieren. Optimieren mit PTGui-Optimizer, dabei müssen alle Pitch und Roll-Häkchen gesetzt sein.
.
Create Pranorama:
PTGui Stitcher verwenden
PTGui Blender verwenden
Kein fast transform
Interpolator Lanzcos

Bei Beachtung dieser Basics gibt es bei den meisten Panoramen keine weiteren Probleme, kein Template o.ä. notwenig, keine Nachbearbeitung von Kontrollpunkten. Bei Multirow-Panoramen mit vielen Bildern ist das Stitchen z.B. des Himmels natürlich problematischer.
Bearbeitungszeit für ein Fisheye-Panorama mit 20 Bildern (Belichtungslayer): 5 Minuten.

Hm. Jetzt stutze ich doch leicht:

Ich kümmere mich überhaupt nicht um die Orientierung der Bilder. Bei 8mm oder WW klappt die VOLLAUTOMATIK super. D.h. ich lade inzwischen per drag&drop die Bilder ein, drücke noch während der Vorschauladezeremonie Align. Probleme hatte ich bisher nur mit dem Tokina 10-17, dort musste ich tatsächlich noch den lens type angeben.

PTGUI ist bei mir als Optimizer immer noch deutlich schlechter als der PanoramaTools Optimizer. Besonders bei Vertikalen braucht PTGUI auch mehr Bilder mit einer Linie als PT und der durchschnittliche Fehler ist höher (wobei ich das am Bildergebnis nicht sehen kann).

Beim Interpolator ist Lanzcos der Hauptgrund für diese flirrenden und flackernden Panos, weil bereits eine starke Vorschärfung stattfindet. Das macht man besser in PS.

Michael

Zitat von »vollmtbi«

Oder noch einfacher im Register Project Assitent ganz rechts unter <<< Simple die Pfeile zum drehen verwenden. Das Funktioniert auch, nach dem Kontrollpunkt finden, wenn das Panorama auf dem Kopf steht.

das habe ich ja beim ersten mal gemacht - da kam aber ach dem Align dann nur Mist raus?!

Ich habe jetzt nochmal mein Hugin Pano mit Smartblend geblendet und siehe da: Gar kein Fehler mehr zu sehen!

Nochmal zu den Zeiten:
6 Bilder, Ausgabe 8000x4000 in Einzellayer und geblendetem Panorama.

Hugin:
Stitch (nona, Poly 3): 4:30 min
Smartblend: 2:30 min
---------------------
7:00 min

PTGui:
PTGui Blender, PTGui Stitcher, fast transform, Interpolator Default, Kompression LZW:
---------------------
7:15 min

Wobei ich gerade sehe, dass nona (der hugin stitcher) ein unkomprimiertes, fertiges Pano (125MB) schreibt und PTGui en anders komrimiertes (88MB) (PackBits?!). Die Einzeltiffs komprimiert nona (35MB) etwas staerker als PTGui (40MB). Da ich auf eine externe USB2-Platte geschrieben habe macht das eventuell einen kleinen Unterschied?!

Wie auch immer - einen wirklich markanten Geschwindigkeitvorteil fuer eins der beider Programme sehe ich hier nicht.
Die Interaktion im Tool selbst finde auch nicht unterschiedlich aufwaendig. Lediglich Dieters Argument (nebenbei beim Fernsehen) stimmt wohl - bei der Interaktion mit hugin muss man schon hinsehen. Aber in beiden Faellen ist der Aufwand mit den Tools selber (~3-5min) wohl wirklich vernachlaessigbar.

An Qualitaet kommt letztlich wohl genau das Gleiche raus - den groessten Einfluss hat hier der Blender: enblend > PTGui Blender -> Smartblend.

Mein (erstmal endgueltiges) Fazit:
Dauert gleich lang und die Ergebnisse sind vergleichbar (wenn nicht identisch). Leichte Komfortvorteile fuer PTGui.
Wie ich eingangs schon sagte:
Wer man Hugin beherrscht, ist's nicht wirklich lohnend sich die interaktiven 5 min komfortabler zu gestalten. Mehr steckt definitiv in der Organisation des Workflows bzw. in der Erlernung besserer Nachbearbeitungstechniken.        

Noch ein Vergleich der Zeiten fuer den Kontrollpunktfinder:
Autopano-Sift via vbs-Datei: 1:30min
Kontrollpunktfinder in PTGui: 0:30min

Pano in Hugin erstellen auf Basis der Datei aus autpano-Sift: < 3min
Pano in PTgui erstellen: < 2 min
Das liegt auch daran, dass ich in Hugin falsche Kontrollpunkte (Ransac Off in Autopano-Sift) loeschen muss, in PTGui war das nicht noetig.

Ich habe dafuer in hugin besser verteilte Kontrollpunkte, aber in meinem Beispiel sah man davon nichts, da Smartblend hier ganz Arbeit geleistet hat.

Insgesamt also ein Aufwand von etwa 12 min bis zum gestitchten Pano + Einzelbildern mit einem Zeitvorteil von etwa 1-2 min fuer PTGui.

Zitat von »trozzreaxxion«

Noch ein Vergleich der Zeiten fuer den Kontrollpunktfinder:
Autopano-Sift via vbs-Datei: 1:30min
Kontrollpunktfinder in PTGui: 0:30min

Pano in Hugin erstellen auf Basis der Datei aus autpano-Sift: < 3min
Pano in PTgui erstellen: < 2 min
Das liegt auch daran, dass ich in Hugin falsche Kontrollpunkte (Ransac Off in Autopano-Sift) loeschen muss, in PTGui war das nicht noetig.

Ich habe dafuer in hugin besser verteilte Kontrollpunkte, aber in meinem Beispiel sah man davon nichts, da Smartblend hier ganz Arbeit geleistet hat.

Insgesamt also ein Aufwand von etwa 12 min bis zum gestitchten Pano + Einzelbildern mit einem Zeitvorteil von etwa 1-2 min fuer PTGui.

Wie ich mir schon dachte, das ist nicht wirklich signifikant. Entscheidend ist wohl wirklich, ob man sich mit "seinem" Stitcher wohlfühlt und mit den Ergebnissen zufrieden ist.

Gruß,
Michael