Datum: 04.09.2004 Uhrzeit: 17:28:41 Alexander Krause Also Panoramafactory ist besser als ich dachte, hat nach dem Absturz die Datein wiedergefunden und an der Stelle weitergemacht, wo es gecrashed war. Hat fast 1,5 Stunden gedauert (1,5GB-RAM 2GHz-Athlon), nachdem ich Photoshop, Dreamweaver und Browser beendet hatte ist er mir auch nur noch ein mal abgeschmiert. Hier sind die Bilder: http://www.berlin-bits.de/panoramen/hofcafe/ Achtung, das JPG ist groß (26761×4542 Pixel, fast 350MB), also gar nicht erst versuchen, das mit dem Browser zu ö¶ffnen. Die QickTime Datei ist klein. Die Bildqualität ist nicht so gut, die Bildoptimierung von Panoramafactory hat da etwas grob angesetzt, die Tiffs aus den RAW-Datein sind viel schö¶ner (hatte nur keine Lust, das alles jetzt noch mal ohne Bildaufwertung berechnen zu lassen). Mein Fazit: Der aktuelle Standardcomputer ist noch nicht reif für 20Megapixelkameras. Wenn ich mir irgendwann mal nen neuen Compi zulege, dann probiere ich es nochmal in 48 bit…. Die 5 Megapixel reichen voll, es ist kein erheblicher Qualitätsgewinn und die Bearbeitung grö¶ßerer Dateien dauert ewig. Alex — posted via https://oly-e.de —————————————————————————————————————————————— Datum: 05.09.2004 Uhrzeit: 10:21:43 joerg Hallo Alex, > … > Hier sind die Bilder: > http://www.berlin-bits.de/panoramen/hofcafe/ > Achtung, das JPG ist groß (26761×4542 Pixel, fast 350MB), also > gar nicht erst versuchen, das mit dem Browser zu ö¶ffnen. > Die QickTime Datei ist klein. da würde ich auch gerne mal einen Kaffee trinken und den Lavendelduft und den der anderen Kräuter dabei einsaugen. Das Filmchen ist also sehr nett und informativ 😉 > … > Alex Gruß Jö¶rg — http://www.raphael-schule.de http://www.jorgos.info/index1.htm —————————————————————————————————————————————— Datum: 05.09.2004 Uhrzeit: 10:21:43 joerg Hallo Alex, > … > Hier sind die Bilder: > http://www.berlin-bits.de/panoramen/hofcafe/ > Achtung, das JPG ist groß (26761×4542 Pixel, fast 350MB), also > gar nicht erst versuchen, das mit dem Browser zu ö¶ffnen. > Die QickTime Datei ist klein. da würde ich auch gerne mal einen Kaffee trinken und den Lavendelduft und den der anderen Kräuter dabei einsaugen. Das Filmchen ist also sehr nett und informativ 😉 > … > Alex Gruß Jö¶rg — http://www.raphael-schule.de http://www.jorgos.info/index1.htm —————————————————————————————————————————————— Datum: 07.09.2004 Uhrzeit: 13:29:25 Alexander Krause Frank Ledwon schrieb: > Alexander Krause wrote: >> Also ich wollte es mal genau wissen, 24 Bilder rundum im RAW >> Modus fotografiert, mit Photoshop RAW-Konverter auf 5120×3840 >> interpoliert und denn wollte ich sie in Panoramafactory zum >> biggest Bildchen ever“ stitchen… > Mit interpolierten Bildern? Looser -) Also ich hab den Eindruck dass die Bilder die im RAW-Konverter hochgerechnet werden erheblich besser sind als bei einer Standard-Interpolation per Bildgrö¶ße im Photoshop. Klärt mich mal auf falls dem nicht so ist. >> Kann man irgendwo in Panoramafactory den virtuellen Speicher >> hochdrehen? > Klar man steigt einfach von 32bit auf 64bit um PF existiert ja > immerhin schon als 64bit-Version: > Grrrr… ich spar doch auf nen Streamer das neue WW-Objektiv Normlichtlampen Gigabit-Netzwerk Urlaub…. da kann ich mir doch nicht schon wieder ´nen neuen Compi holen. Alex posted via https://oly-e.de“ —————————————————————————————————————————————— Datum: 07.09.2004 Uhrzeit: 16:54:26 Frank Ledwon Alexander Krause wrote: > Also ich hab den Eindruck, dass die Bilder die im RAW-Konverter > hochgerechnet werden erheblich besser sind als bei einer > Standard-Interpolation per Bildgrö¶ße im Photoshop. Definiere besser“ bzw. „erheblich besser“. Der Informationsgehalt der Bilder ändert sich überhaupt nicht also was solls? Wenn es nur darum geht die Grenzen der derzeitigen Hard- und Software aufzuzeigen dann geht das wesentlich einfacher: Gigapixel Images > What kind of supercomputer did you use?! Nothing too fancy. I used a > generic PC with a (modest by today’s standards) AMD Athlon 1800 > processor and 1.5GB of RAM. The OS is Windows XP. Die dafür aufgewendete Arbeitszeit (IIRC mehrere Tage) verschweigt Max natürlich 😉 > Klärt mich mal auf falls dem nicht so ist. Wenn der Weg das Ziel ist dann kann man natürlich zusätzlich zu den diversen Interpolationen vor während und nach dem Stitchen weitere Stö¶rquellen auf die Bilder loslassen. Von der sinnloserweise erheblich vergrö¶ßerten Rechenzeit und dem Mehrverbrauch an Hauptspeicher mal ganz abgesehen 😉 Arbeitet man allerdings ergebnisorientiert dann sollte man sich zunächst die Frage stellen: Wieviele Pixel brauche ich eigentlich wirklich um das Bild ansprechend präsentieren zu kö¶nnen? Für die Darstellung auf dem Bildschirm machen mehrere tausend Pixel breite Bilder keinen Sinn. Das sieht man bei dem Potsdam-Beispiel-Bild ganz gut: Je grö¶ßer das Panobild wurde umso teleperspektivischer wurde der im Viewer darstellbare Ausschnitt. Die Viewergrö¶ße läßt sich auch nicht unbegrenzt erhö¶hen also muß man irgendwo einen Kompromiß finden (auch wenn Eric^WOlympus immer das Gegenteil behauptet). Das Verhältnis von Pano- zu Viewerbreite sieht so aus: Panobreite Viewerbreite 360° FoV Nehmen wir einfach mal folgendes an: Der Viewer soll 600 Pixel breit sein und etwa das von einem 22mm KB-Objektiv erfaßte Bildfeld zeigen kö¶nnen. Der horizontale Bildwinkel des 22er Objektivs ist ca. 80°. Damit erhalten wir eine Panobreite von 2700 Pixel (600*360/80). Gegenbeispiel: Wie groß wäre der anzeigbare Bildwinkel bei einem 10000 Pixel breitem Pano und einer Viewerbreite von 600 Pixel? 21.6° was etwa 100mm KB-Brennweite entspricht 😉 Für hochauflö¶sende tapetentaugliche Panos muß man auch nicht unbedingt neue Hardware anschaffen denn meistens reicht es aus wenn man den minimal mö¶glichen Betrachtungsabstand mittels vorhandener Hardware (Mö¶bel usw.) begrenzt 😉 Gruß Frank“ —————————————————————————————————————————————— Datum: 08.09.2004 Uhrzeit: 8:19:49 Alexander Krause Ich muss natürlich wieder ein bisserl wiedersprechen. Für mich macht nicht ausschliesslich das Umgucken“ und das „Hoch und Runter Schauen“ den Reiz des Panoramas aus. Vielmehr schätze ich die Mö¶glichkeit auf Entdeckungsreise zu gehen rein zu zoomen und kleine Details zu „erschnüffeln“. Wenn ich z.B. ein Hotelzimmer fotografiere ist es doch für den späteren User prima in die angelehnte Külschranktür zu zoomen und die Hausbar zu begutachten oder einen ordentlich aufgelö¶sten Blick aus dem Fenster zu wagen. Dafür sind 10000 Pixel Breite noch zu wenig zumal sich ja mit der E-1 mehr produzieren lässt (ohne hoch interpolieren). Das ist auch der Knackpunkt bei den Java-Viewern die kö¶nnen leider noch nicht so große Bilder verarbeiten. Ich bin aber zuversichtlich dass sich da noch was tun wird und hoffe dass auf lange Sicht nicht nur QuickTime so große Bilder verarbeiten kann. Alex posted via https://oly-e.de“ —————————————————————————————————————————————— Datum: 08.09.2004 Uhrzeit: 14:44:15 Frank Ledwon Alexander Krause wrote: > Wenn ich z.B. ein Hotelzimmer fotografiere ist es doch für den > späteren User prima in die angelehnte Külschranktür zu zoomen > und die Hausbar zu begutachten, oder einen ordentlich > aufgelö¶sten Blick aus dem Fenster zu wagen. Also kurz gesagt: Es werden eigentlich nur bestimmte interessante Stellen mit hö¶herer Auflö¶sung benö¶tigt und das haben die Erschaffer der Viewer auch erkannt und als ROI (regions of interest) oder Hotspots eingebaut 😉 Für den Blick aus dem Fenster und den Blick in den Kühlschrank kö¶nnte man z.B. separate, per Hotspot verlinkte Panos erstellen. Ggf. fügt man nur das hö¶heraufgelö¶ste Fensterbild mit PTZoom ein. Beim Kühlschrank kann man sogar so weit gehen, daß man die Tür hinter dem Betrachter zufallen läßt 😉 Das ist letztlich alles nur eine Frage des Aufwands… > Dafür sind 10000 Pixel Breite noch zu wenig, zumal sich ja mit > der E-1 mehr produzieren lässt (ohne hoch interpolieren). Das Problem liegt natürlich wieder ganz wo anders: Bei Kugel-Panoramen muß die Kugel zunächst auf ein flaches Bild abgerollt“ werden. Sieh dir einfach mal die flache Erde in einem Atlas an das ist im Prinzip das gleiche Verfahren 😉 Beim Anzeigen berechnet der Viewer dann jeweils den gerade gezeigten Ausschnitt und das funktioniert sinnvoll d.h. verzerrungsfei nur in dem vorher gezeigten Verhältnis: Je grö¶ßer das Pano im Verhältnis zum Viewer ist umso kleiner (teleperspektivischer) ist der darstellbare Ausschnitt. > Das ist auch der Knackpunkt bei den Java-Viewern die kö¶nnen > leider noch nicht so große Bilder verarbeiten. Man kann den Java-Viewern nahezu unbegrenzt Speicher zuweisen (-Xmx1024M stellt den Applets 1GB (!) zur Verfügung). Allerdings ändert sich nichts an der Problematik der Verhältnismäßigkeit von Viewer- zu Panogrö¶ße 😉 Gruß Frank“ —————————————————————————————————————————————— Datum: 10.09.2004 Uhrzeit: 24:06:35 Dieter Bethke Frank Ledwon schrieb uns: > Die dafür aufgewendete Arbeitszeit (IIRC mehrere Tage) verschweigt > Max natürlich 😉 Noe, tut er nicht: a.. Time required to capture component images: 13 minutes a.. Time required to set control points: 2 hours a.. Time required to optimize project: 2 days a.. Time required to stitch project: 4 days a.. Time required to blend seams / correct misalignments / finalize image: 3 days Wer lesen kann ist … 😉 — Allzeit gutes Licht und volle Akkus, Dieter Bethke ——————————————————————————————————————————————