Zum Inhalt springen

Wikipedia:Kandidaten für exzellente Bilder/alt3

Abschnitt hinzufügen
aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 12. Februar 2010 um 01:48 Uhr durch Der Wolf im Wald (Diskussion | Beiträge) (Saint Paul’s Cathedral – 11. Februar bis 25. Februar: pro). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Wikipedia:Kandidaten für exzellente Bilder/alt3/Intro


Aktuelle Nominierungen

Bitte neue Nominierungen unten anfügen


LuxRender Entstehungsreihe – 1. Februar bis 15. Februar

Entstehungsprozess eines Bildes in Luxrender. (Ist ein animiertes PNG, sieht man nur voller Größe, WP ignoriert das bei den Thumbs
als video (nicht zur Wahl)
  • Vorgeschlagen und Neutral, Hab gerade ein wenig mit dem LuxRender experimentiert und hab dabei diese Bildreihe angefertigt. Sie zeigt, wie bei dem verwendeten Verfahren das Bild erst nach und nach (Strahl für Strahl) entsteht. Mit zunehmender Anzahl der "Strahlen" reduziert sich das Bildrauschen immer weiter. Also wie bei einer realen Kamera, mit zunehmender Belichtungszeit. Gleichzeitig erlaubt der Renderer die physikalisch korrekte Behandlung von Licht, indem nicht mit Farben sondern mit Wellenlängen gerechnet wird. Das Verfahren ist jedoch sehr aufwändig. Die Berechnung des letzten Bildes dauerte insgesamt 16 Stunden und ist natürlich immer noch nicht 100% rauschfrei. PS: Wer das APNG nicht richtig sehen kann, sollte auf der Bildbeschreibungsseite nach unten scrollen, dort habe ich die Einzelbilder in einer Zusammenstellung verlinkt. -- 21:14, 1. Feb. 2010 (CET)[Beantworten]
Abstimmung
LuxRender verwendet ebenfalls Path Tracing, aber eben mit der MLT-Erweiterung und der Berechnung über die Wellenlänge. -- 19:36, 2. Feb. 2010 (CET)[Beantworten]
  • Kontra, Exotenformat, dass die Mehrheit der Wikipedianutzer ausschließt (Da ist ja Flash Webstandardkonformer) und kann zur Zeit gar nicht als Animation im Artikel genutzt werden. Selbst das Endbild ist noch übel verrauscht (insbesondere der Fuß). Das Objekt ist jetzt auch nicht so perfekt, um den Sinn der Methode zu erklären. Nett, aber nicht mehr. Kragenfaultier 17:16, 3. Feb. 2010 (CET)[Beantworten]
  • Pro - schön dargestellt, ich mag APNG sehr gerne. Denjenigen, die Anzeigeprobleme haben, würde ich persönlich dringend zum Browserwechsel raten ;-) -- Felix König Artikel Portal 18:57, 3. Feb. 2010 (CET)[Beantworten]
MediaWiki kann die schon nicht brauchbar für Artikel rendern. Da hilft kein Browserwechsel. Aktion: Wider freiwilliger Wiederwahlen! Für eine erzwungene WW von Southpark noch in 02/10! 19:17, 3. Feb. 2010 (CET)[Beantworten]
Firefox kann das schön darstellen, als Thumb schaut sich der interessierte Betrachter das Bild sowieso nicht an und meine Meinung bleibt meine Meinung. -- Felix König Artikel Portal 19:57, 3. Feb. 2010 (CET)[Beantworten]
  • Pro Schade, dass man die Animation im Vorschaubild nicht erkennen kann. Wäre ein animiertes gif nicht eine Möglichkeit, das Problem zu beheben? Die gute Ausführung, der Aufwand und die gute Darstellung rechtfertigen das Pro. --Minima Moralia 10:34, 4. Feb. 2010 (CET)[Beantworten]
Nee, denn GIF kann maximal 256 Farben darstellen. -- Felix König Artikel Portal 15:53, 4. Feb. 2010 (CET)[Beantworten]
Unfug. --Dschwen 15:56, 4. Feb. 2010 (CET)[Beantworten]
Ja man kann auch 24 Bit-Farben mit GIF erreichen. Allerdings ist die Unterstützung dafür noch mieser als für APNG. -- 16:54, 4. Feb. 2010 (CET)[Beantworten]
Noch mieser? Das faellt mir schwer zu glauben. Immerhin kann man in voller GIF89A Standarkonformitaet ein true color gif Bild erzeugen. APNG ist nicht mal ein Standard. --Dschwen 00:51, 5. Feb. 2010 (CET)[Beantworten]
GIF auch nicht. --Phrood 17:16, 5. Feb. 2010 (CET)[Beantworten]
Diskussion

Fuer Kaustiken braucht man keine Berechnung mit Wellenlaengen. Fuer die Farbverlaeufe auch nicht. Es duerfte sich dabei auch kaum um Beugung handeln. Wellenlaenge in der Berechnung sollte man mittels Dispersion demonstrieren. --Dschwen 21:40, 1. Feb. 2010 (CET)[Beantworten]

Ach verdammt, das meinte ich ja. Sieht man z.B. am oberen Rand des Glases. -- 21:42, 1. Feb. 2010 (CET)[Beantworten]
Da muss man aber wirklich mit der Lupe gucken. Das Motiv finde ich somit ungeeignet. Eine beleuchtete facettierte Kristallglasfigur waere deutlich besser geeignet. Sowas kann man auch mit POV-Ray erzeugen. --Dschwen 21:56, 1. Feb. 2010 (CET)[Beantworten]
  • Wie ist denn die Reihe 1, 5, 20, 50, 100, 1400, 4150 S/px motiviert? Insbesondere der Sprung von 100 auf 1400 erscheint mir vergleichsweise groß. Könntest du evtl. statt der 50 die 400 nehmen? Dann wären die Intervallverhältnisse ähnlicher. Viele Grüße, --Quartl 21:51, 1. Feb. 2010 (CET)[Beantworten]
PS: fällt eigentlich nur mir auf, dass das 1400er Bild anderes als die anderen Bilder gefärbt ist, oder liegt das an meinem Renderer? --Quartl 20:20, 3. Feb. 2010 (CET)[Beantworten]

Wollen wir wirklich Animationen auszeichnen, die in einer nicht unerheblichen Zahl aller Browser (Internet Explorer, Safari und andere Webkit-Browser) nicht korrekt dargestellt werden können? --Hk kng 18:31, 2. Feb. 2010 (CET)[Beantworten]

Bei SVG-Grafiken ist es auch nicht anders *duck* -- 19:31, 2. Feb. 2010 (CET)[Beantworten]
Ich bin grundsätzlich gegen APNG. Das Format ist eine Eigenentwicklung von Mozilla und nicht von der PNG-Entwicklergruppe standardisiert. --Phrood 20:07, 2. Feb. 2010 (CET)[Beantworten]
In dem Fall bleibt nur noch ein langer Schlauch von Grafik über, denn GIF als einzig animierte Alternative ist hierfür vollkommen unbrauchbar (256 Farben Limit). -- 21:16, 2. Feb. 2010 (CET)[Beantworten]
Ich finde, ein Mosaik aus vier Bildern mit abnehmendem Rauschen wäre genauso informativ wie die Animation. --Phrood 21:27, 2. Feb. 2010 (CET)[Beantworten]
Zu den SVGs: Derzeit sind sechs SVGs als Exzellent ausgezeichnet. Vier von ihnen können vom server-basierten Renderer in vielen verschiedenen Größen unabhängig vom Browser in einwandfreier Qualität wiedergegeben werden. Mahuri.svg und Rubik's cube v3.svg werden aufgrund eines Fehlers im Renderer librsvg nicht bei jeder Vergrößerung korrekt wiedergegeben. Nur bei Mahuri erreicht der Fehler eine erkennbare Größe: bei kleinen Thumbnail-Darstellungen werden die Highlights in den Augen verschluckt. Alle anderen Fehler sind quasi unsichtbar.
Insofern scheint mir der Vergleich nicht zu passen. Wird nicht dargestellt ist halt doch etwas anderes als wird mit kleinen Fehlern dargestellt. Sobald jemand versuchen würde, eine SVG-Animation zu nominieren oder eine Grafik, bei der der Renderer massive Fehler produziert, würde ich ebenfalls Bedenken anmelden. --Hk kng 23:09, 2. Feb. 2010 (CET)[Beantworten]
GIF als einzig animierte Alternative ist hierfür vollkommen unbrauchbar (256 Farben Limit) das ist natuerlich gleich in mehrfacher hinsicht falsch. Erstens ist GIF nicht die einzig animierte Alternative (ogg!!), und zweitens ist es auch nicht vollkommen unbrauchbar, da das 256 Farben-Limit pro frame gilt. Mit einem frame-delay von 0 kannst Du GIF-Dateien mit quasi beliebig vielen Farben konstruieren (das ist nur nicht allgemein bekannt). --Dschwen 19:40, 3. Feb. 2010 (CET)[Beantworten]
Jedes der GIF-Einzelbilder hat aber eine eigene 256 Farben fassende Palette. Um Echtfarbenbilder als GIF abzuspeichern, muss man das Bild im schlimmsten Fall in 16x16 Pixel große Blöcke unterteilen, für die jeweils eine eigene Palette mitgespeichert wird. So etwas wurde von den GIF-Entwicklern nie vorgesehen. Das ist eine sehr hässliche Methode, die außerdem zu unnötig großen Dateien führt. --Phrood 16:51, 4. Feb. 2010 (CET)[Beantworten]
16x16 Bloecke ist ein total konstruierter und hier voellig irrelevanter Fall. Farbzahl << Pixelzahl, duerfte hier locker gelten. Unnoetig gross werden die Bilder dadurch nicht. Das erlidigt auch APNG vs. OGV, oder allgemein die Wahl eines nicht verlustfrei komprimierten Formats. Oder wie wilst Du deinen aus den Fingern gesogenen Fall noch viel besser komprimieren? --Dschwen 00:49, 5. Feb. 2010 (CET)[Beantworten]
Nein. Die gerenderten Bilder enthalten Rauschen; nahe beieinander liegende Pixel mit derselben Farbe sind die Ausnahme. Dass die Bilder unnötig groß werden, lässt sich berechnen: Farbtabelle+16x16 indizierte Farben = 256*3 + 16*16*1 = 1024 Byte; dagegen 16x16 Echtfarben: 16*16*3 = 768 Byte. Das ist nur der unkomprimierte Fall; man muss außerdem beachten, dass jedes GIF-Frame einzeln komprimiert wird, sodass die Kompressionsmethode ihr Potenzial nicht ausschöpfen kann. Mir ist auch kein Programm bekannt, das die Aufteilung eines Echtfarbenbildes in möglichst große GIF-Einzelbilder mit je 256 Farben übernimmt. Kennst du eines? --Phrood 17:14, 5. Feb. 2010 (CET)[Beantworten]
Na ja, 25% mehr Speicherbedarf (modulo Kompression, die aber auf Grund des von Dir erwaehnten Rauschens eh nicht relevant sein duerfte). Ist ja ohnehin voellig egal. Die OGG-Theora version hat nicht einmal ein achtel der Groesse der APNG-version, ist ein sauberer Standard und bietet quasi garantierte Abspielbarkeit sowohl im thumb als auch in der Vollversion (diverse Playeroptionen, HTML5, Silverlight, Java). --Dschwen 16:57, 8. Feb. 2010 (CET)[Beantworten]


Es ist bezeichnent, dass sich die Diskussion mittlerweile nur noch um das Dateiformat dreht. Die simulierte Physik scheint hier niemanden zu interessieren. Das Bild verkommt so zu einem blossen "Gimmick". Anders kann ich es mir nicht erklaeren, dass niemand die krassen Fehler in der Bildbeschreibung anspricht und das niemand sieht wie ungeeignet das Motiv fuer diesen besonderen Typ Renderer ist. Der Witz an dem Programm ist eben nicht dass das Bild aus dem Rauschen entsteht. Das ist nur ein kleiner Nebeneffekt des Algorithmus. --Dschwen 19:12, 3. Feb. 2010 (CET)[Beantworten]

Zur Illustration des Artikels Monte-Carlo-Algorithmus wäre das Bild gar nicht mal so schlecht. --Phrood 20:03, 3. Feb. 2010 (CET)[Beantworten]
Ich rendere gerade mit Maxwell ein Bild in 8500x3500px. Das Bild brät seit 80 Stunden kooperativ auf einer 20x8Core Renderfarm vor sich hin und würde vom aktuellen Noisefaktor nicht mal die Hürde bei den Quality Images überstehen. Heute sagte der Fotograf auch noch zu mir: "Dreh bitte das hintere Streiflicht noch 5 Grad nach rechts .. Mental Ray rules ! Zum Bild fällt mir noch der Martin Newellsche Utah teapot ein - dann fände ich es viel besser. Eine Cornell Box wäre der Traum, denn dann könnte man die Bounces schön sehen.   &#x95; Richard &#x95; [®] &#x95; 00:10, 5. Feb. 2010 (CET)[Beantworten]
PT/MLT ist optimal fuer GPGPU computing geeignet. Aktuelle CPU Implementationen sind eigentlich heute schon von gestern :-). --Dschwen 00:45, 5. Feb. 2010 (CET)[Beantworten]
Wo bleibt mein Board mit 32 SLI Slots ? 85.181.43.250 01:01, 5. Feb. 2010 (CET)[Beantworten]
Für LuxRender gibt es bereits erste Implemetierungen von OpenCL, was das Rendern etwa um Faktoren 20-50 beschleunigt. Allerdings wohl noch nicht so ausgereift, das man es bedenkenlos in einer Produktivumgebung einsetzen könnte. [1] -- 15:33, 5. Feb. 2010 (CET)[Beantworten]



American International Building 4. Februar bis 20. Februar

American International Building
Abstimmung



Admiral (Schmetterling) – 8. Februar bis 21. Februar

Photo eines Admirals an einer Mauer
Abstimmung
Diskussion



Wildkaninchen – 11. Februar bis 24. Februar

Süßes Kuschelhasi
Abstimmung
Diskussion

Kippt das nach rechts weg?? --kaʁstn 14:41, 11. Feb. 2010 (CET)[Beantworten]

Vielleicht haut es gleich ab? Die Haxen sind m.E. gerade.-- Alt Wünsch dir was! 19:55, 11. Feb. 2010 (CET)[Beantworten]



Saint Paul’s Cathedral – 11. Februar bis 25. Februar

Die Saint Paul’s Cathedral im Januar 2010
Abstimmung
Diskussion

Könnte das Bild in den Artikel eingebunden werden? --Äbäläfuchs Möchtsch rede?Oder bewärte? 15:17, 11. Feb. 2010 (CET)[Beantworten]

done --kaʁstn 15:28, 11. Feb. 2010 (CET)[Beantworten]
Danke. --Äbäläfuchs Möchtsch rede?Oder bewärte? 17:26, 11. Feb. 2010 (CET)[Beantworten]



Chicago – 11. Februar bis 25. Februar

Downtown Chicago Skyline bei Sonnenaufgang.
  • Vorgeschlagen und Neutral. Weil hier grade so wenig los ist ;-). Das Bild ist im letzten Fruehling frueh(!) morgens entstanden. Lichtverhaeltnisse aendern sich bei Sonnenaufgang sehr schnell, was die Panoramaerstellung nicht gerade einfacher macht. Das Bild ist mit knapp 70MP angemessen aufgeloest. Alles was senkrecht sein muss ist es auch :-). --Dschwen 14:59, 11. Feb. 2010 (CET)[Beantworten]
Abstimmung
Diskussion

Auf Höhe des Krans läuft eine Sensorfleckreihe konsequent durch ;-). --Backlit 15:12, 11. Feb. 2010 (CET)[Beantworten]

Neben der Kranreihe ziehen sich noch einige weitere Sensorflecken durch das Bild… --kaʁstn 15:43, 11. Feb. 2010 (CET)[Beantworten]