„Hilfe Diskussion:Bilder“ – Versionsunterschied

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 350 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 5 Abschnitte.

Archiv

2003 bis 2006 2007 bis 2009 2010 und 2011 2012 bis 2017 ab 2018

Wie wird ein Archiv angelegt?

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 20 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Der zweite Satz von „Zu beachten ist, dass der Faktor bei Dezimalbrüchen mit Punkt anstatt Komma angegeben werden muss (Beispiel: 1.8 anstatt 1,8). Die mögliche Schrittweite ist ein Zehntel“ ist falsch. Die Grenze für das Umschalten von 220px auf 230px liegt bei ((230px+220px)/2)/220px -> 225px/220px was einen Wert von 1.0227272727272727 ergibt. Im Quelltext zu dem nebenstehenden Beispiel sieht man, das der Bereich an dem Umgeschaltet wird von der Software exakt berechnet wird (PHP rechnet da intern wohl mit Real). Erst nach der Berechung mit exakten Werten rundet die Software auf 10px. --Summer • Streicheln • Note 13:07, 14. Mär. 2018 (CET)Beantworten

Wohl nicht; intern wird mit voller Genauigkeit gerechnet, aber auf das Endergebnis bezogen.

Ist mini im Spiel, gelten die 10px hinterher, ansonsten nur die (abgeschnittenen) Zehntel.

Mir scheint die Hilfeseite richtig; aber die Zusammenhänge sind komplex und das gesamte Unterfangen hier wenig zielführend.

VG --PerfektesChaos 14:57, 14. Mär. 2018 (CET)Beantworten

Der Satz „Die mögliche Schrittweite [des Paramter Hochkant] ist ein Zehntel“ ist definitv falsch. Nebenstehend siehst du, das ein Hunderstmillionstel ausreichen kann. --Summer • Streicheln • Note 15:35, 14. Mär. 2018 (CET)Beantworten

PS: die Zusammenhänge sind hier nicht Komplex ... das ist im Gegenteil popelig einfach. Die Software akzeptiert viele Stellen hinter dem Komma, rechnet damit exakt und ganz am Ende vor der Ausgabe des Ergebnis rundet sie auf volle Zehner. Ich würde das sogar gute Programmierung nennen. -- Summer • Streicheln • Note 15:40, 14. Mär. 2018 (CET)Beantworten

Das gilt alles nur für mini, bei nicht-mini greifen die Zehntel.

Die mini wiederum hängen von der Benutzereinstellung ab; diese kann zurzeit 120, 150, 180, 200, 220, 250, 300, 400px betragen, was sich im Lauf der Jahre aber ändern könnte.

Damit der Bild-Cache im Server nicht lauter Vorschaubilder halten muss, wird auf ganze Zehner abgeschnitten (nicht gerundet, wenn ich den Algorithmus recht erinnere; unter dem Maximalwert den nächstkleineren).

Deine Rechnerei gilt erstmal nur für dich persönlich, weil du offenkundig 220px eingestellt hast. Leser mit anderer Einstellung sehen aber eine andere Breite und bekommen ggf. andere Ergebnisse.

Die ganzen Zehntel gelten für nicht-mini, dann wird die Höhe betrachtet, dann das Ergebnis auf ganze Pixel gesetzt.

Diese gesamte Rumrechnerei hier und im Abschnitt drüber läuft völlig am Zweck des hochkant vorbei und ist für die Katz. Dem Artikel bringt es nichts.

Die internen Berechnungsmodalitäten haben sich in den letzten anderthalb Jahrzehten immer mal wieder etwas geändert und können auch zukünftig betreffend Rundung usw. anders laufen. Es ist absolut sinnlos, hier mit Nachkommastellen den halben Pixeln nachzujagen.

VG --PerfektesChaos 16:09, 14. Mär. 2018 (CET)Beantworten

(Nach links Ausgerückt)

Als Wiederholung damit keine Missverständnisse aufkommen: Der Satz „Die mögliche Schrittweite [des Parameter Hochkant] ist ein Zehntel“ ist definitiv falsch. Defintiv wird ein Wert mir vielen Stellen hinter dem Komma (Dezimalpunkt) eingelesen und zur Berechnung herangezogen. Und kompliziert wird es nur, weil du es kompliziert machst.

• Du verkomplizierst das ganze, indem du persönliche Benutzereinstellungen betrachtest. Lass das weg. Macht die einfache Sache nur kompliziert.
• Du schreibst von Server-Cache etc. Alles nur komplexes Zeug. Die am heimischen Bildschirm angezeigte Bildgröße wird nicht vom physischen Bildparametern sondern von den Paramtern width/height des img-Tags bestimmt. Pures HTML das von der Wikisoftware generiert wird. Simpel
• Das Bild der Messingfigur (heute auch auf der Hauptseite) habe ich in diesem Thread zweimal mit dem Parameter mini eingebunden um dir zu zeigen, das der Parameter Hochkant mindestens bis zur 8ten Stelle hinterm Komma ausgewertet wird. Im Thread darüber habe ich das Bild fünfmal eingebunden - vier davon OHNE den Parameter mini. Damit wäre wohl klar, das deine Vermutung bezüglich des Parameters mini falsch sind.

Wirf alle komplizierten Gedanken über Bord und beschränk dich auf das Einfache. Dann ist klar, dass das Handbuch falsch ist. --Summer • Streicheln • Note 16:52, 14. Mär. 2018 (CET)Beantworten

@PC: Also ich habe als IP logischerweise nicht irgendwas eingestellt, und ich sehe die nebenstehenden Bilder in unterschiedlicher Grüße. 129.13.72.197 17:39, 14. Mär. 2018 (CET)Beantworten

@Benutzer:PerfektesChaos: da Worte dich nicht überzeugen, versuch ich es mal mit einer hoffentlich selbstredenden Tabelle (Effekt bei Standardeinstellung sichtbar):

Hochkantwert	Bild
2.0
2.02273
2.06819
2.1
2.11364
2.15910
2.2
2.20455
2.25001
2.29546
2.3
2.34091
2.38637
2.4

Die Hochkantwerte mit 5 Nachkommastellen wurden wie oben beschrieben berechent und liegen genau an der Schwelle, an der das Bild vergrößert wird. Substrahiert man von dem jeweiligen Wert 0.00001, dann wird das Bild sprunghaft kleiner. --Summer • Streicheln • Note 12:22, 15. Mär. 2018 (CET)Beantworten

Ich sehe hier nirgends einen Unterschied, die Bilder sind alle jeweils exakt gleich breit, sowohl die beiden oben anfangs, als auch die in der Tabelle (natürlich nur innerhalb der jeweiligen Gruppe). Solche merkbefreiten Spielereien dienen nichts sinnvollem, das hängt primär von den persönlichen Einstellungen, von den Browsereinstellungen, dem Ausgabegerät und sonstwas ab, wer meint damit irgendwas für alle gleich machen zu können, oder auch nur ein "schönes Seitenlayout" generell hinzubekommen, der hat den Schuss nicht gehört. Grüße vom Sänger ♫ ^(Reden) 14:08, 9. Mai 2018 (CEST)Beantworten

Wiederholt wurden im Artikel Schweinfurt bei der Skalierung der Bildgrößen zweistellige Nachkommastellen (linkes Bild) durch eine halbautomatische Ersetzung auf eine Stelle reduziert (rechtes Bild). Dadurch wurde im langen Artikel das Layout vieler Bilder zerstört und ich musste per Hand alles wieder reparieren.

An diesem Beispiel erkennt man zweifellos zwei Dinge:

1.: Für eine gute Bildgestaltung benötigt man 2 Nachkommastellen

2.: Die halbautomatische Ersetzung sollte entsprechend geändert werden

Grüße --Kim117 (Diskussion) 21:29, 7. Mai 2018 (CEST)Beantworten

Bitte hilf mir auf dei Sprünge: Ich sehe keinen wesentlichen Unterschied zwischen den beiden Bildern. --Digamma (Diskussion) 22:14, 7. Mai 2018 (CEST)Beantworten

Der Unterschied liegt allein bei der Bildlegende: links kompakt im Kasten mit 3 Zeilen, rechts zerrissen in 5 Zeilen, wobei die Überschrift in 2 Zeilen aufgespaltet wurde. Also eine doppelte Verschlechterung: 1. Grafik, mit unnötigen Platzverbrauch, was bei Bildern auf der linken Seite weitere Zerstörungen des Layouts nach sich ziehen kann, durch Versetzung der nachfolgenden Abschnitts-Überschrift nach rechts oder bei nachfolgenden blauen Listen-Punkten, die dann ins Bild hineingehen. 2.: Die Bildlegende wird unübersichtlicher und schwerer lesbar. Fazit: durch halbautomatische Reduzierung auf eine Nachkommastelle kann im schlimmsten Fall sogar ein ganzer, grafisch ausgefeilter Artikel formal ruiniert werden. --Kim117 (Diskussion) 08:00, 8. Mai 2018 (CEST)Beantworten

Ich sehe unangemeldet und angemeldet zwei völlig verschiedene Unterschiede, angemeldet geht es um 2 vs. 3 Zeilen Bildunterschrift, unangemeldet waren es iirc 5 vs. 6 Zeilen. Von der Lesbarkeit des Karte selber her war unangemeldet eher nix zu erkennen, angemeldet geht es so. Das Problem mit der Darstellung von Bildern ist die Abhängigkeit von persönlichen Einstellungen und den Endgeräten, da von der Darstellung auf dem eigenen Bildschirm/Tablet/Wischhandy auf allgemeine Aussagen zu schließen, ist i.d.R. eher nicht möglich. Grüße vom Sänger ♫ ^(Reden) 08:29, 8. Mai 2018 (CEST)Beantworten

Hallo Benutzer:Kim117, es ist schon ein witziger Zufall. Im Abschnitt #Falsche Formulierung auf Hilfeseite hier drüber habe ich mir den Mund fusselig geredet, das die Wikisoftware den Parameter hochkant mehr als nur eine Stelle hinter dem Komma auswertet (auch wenn mir da bis dato nicht zugestimmt wurde, hat jedenfalls niemand revertiert als ich die falsch Aussage auf der Hilfeseite löschte. Und nun sehe ich, das du genau diesen Parameter auf ein Hundertstel ausreizt.

Zu deinem Problem: über den Parameter hochkant kannst du, sofern der Benutzer Standardeinstellungen belassen hat, die exakte Darstellungsbreite eines Bildes vorgeben. Indirekt gibt du damit auch die Breite vor, die für die Bildunterschrift zur Verfügung steht. Da kannst aber leider über die Breite des Textfelds NICHT die Zeilenumbrüche exakt steuern. Der Grund: die Umbrüche werden im wesentlichen über den Zeichenfont gesteuert. Und der ist von Betriebssystem, Browser und Vorlieben des Benutzers abhängig.

Anders formuliert: wo du drei Zeilen siehst, erscheinen bei anderen Benutzern nur zwei oder auch vier Zeilen. Du kannst etwas mit erzwungenen Zeilenumbrüchen (<br />) und geschützten Leerzeichen (&nbsp;) arbeiten ... alles andere ist aussichtslos (es gibt noch etwas härtere Tricks ... aber die machen alle Probleme). --Summer • Streicheln • Note 14:37, 8. Mai 2018 (CEST)Beantworten

@Lómelinde: an dich die Bitte, Kürzen von Hundertstelangaben wie hier zu unterlassen. Ich denke, es ist inzwischen nachgewiesen das die Hundertstelangaben bei Hochkant einen Effekt haben (können). Du solltest es einfach respektieren, wenn andere das Hundertstel verwenden wollen. --Summer • Streicheln • Note 14:54, 8. Mai 2018 (CEST)Beantworten

Ich tue das nicht. --Liebe Grüße, Lómelinde Diskussion 15:14, 8. Mai 2018 (CEST)Beantworten

Um mich als Programmierer des hochkant-Parameters mal einzumischen: Ihr könnt beliebig viele Nachkommastellen reinschreiben, die werden auch berücksichtigt. Aber: Das damit erstellt Thumbnail wird immer auf eine glatte Zehnerzahl gerundet: For caching health: If width scaled down due to upright parameter, round to full __0 pixel to avoid the creation of a lot of odd thumbs.. So meine damalige Begründung, die auch im PHP-Code von Linker.php zu finden ist. Mit anderen Worten: 300 Pixel * 0,75 (der Standard von hochkant) = 225 Pixel, gerundet zu 230 Pixel. Ohne Rundung besteht einfach die Gefahr, dass der Thumbnail-Cache mit unendlich vielen Werten "zugemüllt" wird. Im übrigen pflichte ich Summer bei: Bitte versucht nicht, pixelgenau Bild und Bildunterschrift in Einklang zu bringen. Dafür ist das Web nicht ausgelegt. Zu viele Faktoren spielen bei der Darstellung eine Rolle: Schriftart, Browser, Betriebssystem, benutzerspezifische Thumbnailgröße, mobile Darstellung usw. — Raymond ^Disk. 15:33, 8. Mai 2018 (CEST)Beantworten

Auch das tue ich nicht. Die Umstellung erfolgt per Skript und nicht auf meinen speziellen Wunsch oder nach meinen Vorlieben oder einer zusätzlichen persönlichen Konfiguration.

Ich hatte aufgezeigt, wie man Bildlegenden anders gestalten kann, wenn es tatsächlich eine Legende zu der Abbildung und eben nicht die normalerweise zu erwartende Bildbeschreibung sein soll. Für mich gehört da nur ein sehr kurzer Text hin, der beschreibt was das für ein Bild ist Was das Bild darstellt = Übersichtskarte der Bomberoffensive im Juni 1944.

Ich kürze da aber tatsächlich manchmal bewusst und beabsichtigt den Text und verpacke einen Teil in ref-Tags, damit die Bildlegende nicht so unansehnlich überquillt. Was beim einen gut aussehen mag zeigt bei anderen Murks an. Und überfüllte Bildlegenden empfinge ich als sehr störend. --Liebe Grüße, Lómelinde Diskussion 15:52, 8. Mai 2018 (CEST)Beantworten

Ich sah bisher angemeldet wie unangemeldet bei extrem unterschiedlichsten persönlichen Schriftgrößeneinstellungen in meinen beiden Notebooks mit sehr unterschiedlichen Bildschirmgrößen und bei unterschiedlichen PC's in diversen Stadtbüchereien bei einer Bildlegende mit zwei Nachkommastellen immer überall das exakt selbe Layout, mit selben Zeilenumbruch. Abweichungen gibt es offensichtlich demnach nur in selteneren Fällen, die dann nicht als Maßstab dienen sollten (und mobile Geräte sollten sowieso nur eine Nebenrolle spielen, da man es im Webdesign nun mal nicht allen Recht machen kann). Und auch im seltenen, obigen Fall waren es 2 vs. 3 bzw. 5 vs. 6 Zeilen. Also selbst hier bei zwei Nachkommastellen ein besseres Ergebnis als bei einer. Die Sache ist doch eindeutig: zwei können zu besseren Ergebnissen führen, als eine. --Kim117 (Diskussion) 12:09, 9. Mai 2018 (CEST)Beantworten

Hi Kim117, ich bin ja voll bei dir, das man zwei Stellen bei dem Hochkantparameter verwenden darf (unter Strich ist es übrigends so, das man mit einer Nachkommanstelle 20px Sprünge hat während es bei 2 Nachkommastelle 10px Sprünge sind). Ich möchte dir nur trotz deines Test die 'Illusion' nehmen, dass du Zeilenumbrüche über Breitenangabe des Textfensters steuern kannst. Ein ganz simples Bsp.: ein Brillenträger wählt die Schrift auf seinen Mobile so, das er auch ohne Brille lesen kann. Schon stimmen die Umbrüche nicht mehr. Und ironischerweise gibt man dann genau dem Clientel, das mehr Mühe beim Lesen hat und gute Formatierung am dringensten bräuchte, die schlechteste.

Versteh mich bitte nicht falsch - ich will dich nicht von einer bestimmten Technik überzeugen. Aber HTML-Dokumente geben dem Brower beim Zeilenumbruch viel Spielraum. Sieh meinen Betrag mehr als Hilfestellung oder Anregung denn als Kritik (ich werde ganz sicher nicht in deinen Artikel nacheditieren). --Summer • Streicheln • Note 12:38, 9. Mai 2018 (CEST)Beantworten

Fummeleien der Art 1.0 → 1.03 sind sinnfrei.

• Die Breite eines Miniaturbildes hängt von den Benutzereinstellungen ab; nicht angemeldete Leser erhalten zurzeit 220px (ändert sich ab und zu) und angemeldete können 120px, 150px, …, 250px, 400px einstellen.
• Die Breite von Texten hängt generell von den Font-Einstellungen bei den Lesern ab; welche Schriftart im Browser vorgegeben, und in welcher Größe, und wie gut sind die Augen des Lesers? Das bedingt die Breite der Buchstaben, und welches Text-Layout sich daraus ergibt, aus deren Aufsummierung.
• Die Desktop-Skins bewirken teilweise bei identischen Browser-Vorgaben kleine Unterschiede in hier relevanten Details. Insbesondere aber auf Mobilgeräten werden völlig andere Darstellungkonzepte verfolgt, die sich obendrein häufig ändern.
• Bilder werden in Pixeln px bemessen; Schriftzeichen in Maßeinheiten em und derlei. Das Verhältnis beider Maßeinheiten ist signifikant von Geräten und Betriebssystemen und Browsern abhängig.
• Der Hochkant-Parameter dient dazu, stark querformatige oder Wolkenkratzer-Bilder in der Basis-Darstellung besser zu präsentieren. Daraus ein Gefrickel zu machen, wie sich die Bildlegende in der Seite präsentieren solle, ist eine missbräuchliche Spielerei. Die eigentliche Aufgabe des Hochkant-Parameters, nämlich das geeignete Seitenverhältnis, wird lediglich von der ersten Dezimalstelle gesteuert (siehe oben: For caching health: If width scaled down due to upright parameter, round to full __0 pixel to avoid the creation of a lot of odd thumbs.)
• Nichts von all diesen Basteleien wird über die Jahre Bestand haben, weil es keine Anforderung an irgendeine Software gibt, diese pixelgenauen Rechnereien unterstützen zu müssen oder gar zu garantieren. Sie sind deshalb absolut wertlos und führen nur zu überflüssiger Beschäftigung der Bearbeiter und vergeuden die Zeit der Autoren.

VG --PerfektesChaos 13:56, 9. Mai 2018 (CEST)Beantworten

Aber so was von +1. Wer sich mit solchen merkbefreiten Kinkerlitzchen tatsächlich beschäftigt, sollte dieses absurde Tun dringend überdenken. Grüße vom Sänger ♫ ^(Reden) 14:04, 9. Mai 2018 (CEST)Beantworten

@PerfektesChaos @Benutzer:Sänger: ich (und auch Raymond) raten dem Benutzer Kim117 nicht zu seiner Formatierungsmethode zu. Warum man ihm aber unter Heranziehung von Extremwerten (1.0 → 1.03) sinnfreies Arbeiten vor den Kopf knallt und dann auch noch ein praktisch geschrienes +1 hinterher kommt, ist mir nicht begreiflich. Ohne eueren Auftritt wäre es sicher auch gegangen. --Summer • Streicheln • Note 14:24, 9. Mai 2018 (CEST)Beantworten

Damit kein Missverständnis entsteht: habe zwei Nachkommastellen nur in einigen Sonderfällen, wie bei obigem Bild mit Übergröße, verwendet. Ansonsten habe ich bei Bildern mit dem Parameter hochkant allermeist überhaupt keinen Zusatz gemacht. Vielleicht beruhte die ganze Diskussion nur auf diesem Irrtum, da ich mich zu wenig deutlich ausgedrückt habe. Grüße --Kim117 (Diskussion) 11:29, 10. Mai 2018 (CEST)Beantworten

Hi Kim117, wir haben es hier mit zwei Dingen zu tun, die etwas durcheinander gelaufen sind.

1. dein Versuch, Zeilenumbrüche in der Bildunterschrift durch die Bildbreite zu steuern ist nicht sinnlos ... wird aber nicht immer und überall den gewünschten Effekt haben. Siehe z.B. mein 'Brillenargument' weiter oben (deine Tests werden korrekt sein - deine Methode wird aber oft nicht funktionieren wobei 'oft' eine schwer zu definierende Variable ist). Wäre hier etwas ruhigeres Fahrwasser, dann könnte man vernünftig besprechen wie du deinem Ziel trotzdem sehr nahe kommst (wird auch in der Praxis gemacht - aber eher intuitiv). Du gibst alle Zeilenumbrüche der Bildunterschrift per <br> vor und wählst die Zeilenlänge manuell genügend kurz. So kurz, dass sie bei allen vernünftigen Schriftgrößen/-arten nicht noch zusätzlich durch den Brower umgebrochen werden. Intuitiv wird das gelegentlich gemacht, wenn z.B. unter einer Grafik eine Farblegende mit kurzen Zeilen steht. Lässt sich leider nicht ganz einfach beschreiben ... (selten mach ich das selbst und wir können uns gerne auf einer Artikeldisk am konkreten Beispiel besprechen). Man muss aber bei all dem Wissen - man Erhöht durch diese Tricks nur die Wahrscheinlichkeit, das die Umbrüche wie gewünscht dargestellt werden (wenn z.B. ein Benutzer eine Bildbreite von 150px in seinen per. Einstellungen hat, ist dagegen kein Kraut gewachsen).

Noch ein Tipp den du bei 'Sonderformatierung' immer beachten solltest: stell als Test unterschiedlich Wert für die Standartgröße der Vorschaubilder ein ... da fällt die schlechte Formatierung sofort ins Auge.

2. Das zweite Thema ist die Wirkung des Parameter 'Hochkant'. Diesen Parameter als exakte 'Zeilenumbruchshilfe' einzusetzen wird nicht für jeden Brower (Schriftart etc.) funktionieren (als grobe Zeilenumbruchshilfe schon - s.o.). Es ist aber ein toller Parameter um das gesamte Layout zu beeinflussen. Ich erklär nochmal was Raymond (der Programmierer des Hochkantparameters) schrieb: er nimmt den Basiswert der Bildbreite (den Wert aus Einstellungen -> Aussehen -> Standardgröße der Vorschaubilder: - der Standard ist 220px) und multipliziert es mit dem Wert des Parameter 'Hochkant' und verwendet das Ergebnis als neue Bildbreite. Am Ende rundet er noch Bildbreite auf 10px (das ist zur Minderung der Serverlast sehr vernünftig!). Zwei Rechenbeispiele: mit Hochkant 1.0' und 1.1': 220px*1.0=220px; 220px*1.1=242px gerundet 240px. Da der Unterschied zwischen 1.0 und 1.1 ein Zehntel, also 10% beträgt, findet man im Ergebnis auch rund 10% (hier 20px) Unterschied wieder. Raymonds Programm erlaubt aber 10px statt nur 20px! Und wenn du es mit dem Hochkantwert 1.03 durchrechnest (also genau der Wert, den PerfektesChaos oben als sinnfreie Fummelei abtut), dann siehst du, das es gerundete 230px ergibt - man füllt also genau die Lücke von 20px, die zwischen den Hochkantwerten 1.0 und 1.1 liegt. Wem Rechnen nicht so liegt, der kann es auf meiner Ben. bei commons anschauen (siehe dortiges Zitronenbild).

Vereinfacht gesagt: verwendet man nur die erste Stelle hinter dem Komma, macht man 20px Sprünge, verwendet man die zweite Stelle hinterm Komma, macht man 10px Sprünge. Sicher kann man Streiten, ob 10px Sprünge gegenüber 20px Sprüngen sinnvoll sind - vor dem Diskutieren über dem Sinn kommt aber das darstellen der Fakten. Ich persönlich würde dir empfehlen, die zweite Nachkommastelle zu benutzen wenn das Ergebnis bei bloßem Ausprobieren gut aussieht (ich könnte das noch genauer begründen - aber das würde den Rahmen sprengen). Um es nur kurz anzureißen: wer in seinen pers. Einstellungen 400px als Basiswert hat, macht bei der ersten Nachkommastelle 40px Sprünge statt möglichen 10px Sprüngen mit der zweiten Nachkommastelle (Daumenbreite statt Buchstabenbreite) ... das ist dann kein Peanuts mehr.

Aber ganz sicher kannst du dich darauf verlassen, das Raymonds Programm deinen Parameter vernünftig auswertet - selbst wenn du zehn Stellen hinter dem Komma angibst. Und du musst dich nicht rechtfertigen, ob und wie oft du die zweite Nachkommastelle benutzt.

3. nochmal angemerkt: der Ton gefällt mir hier überhaupt nicht. Ganz oben wurde ich mit RTFM (Read the fucking manual; zur Erinnerung - das 'Handbuch' war vor meiner Korrektur nachweislich falsch!) als dummer Junge hingestellt und das gipfelt nun hier im Geschreie vom Sänger. Spart euch das!!! Nach meinem dafür knallt man Benutzern auch nicht eine Methode als Unsinn vor den Latz sondern erklärt warum. Und dazu gehört nun mal, die vermeidlich unsinnigen Herangehensweisen zu besprechen. --Summer • Streicheln • Note 15:50, 10. Mai 2018 (CEST)Beantworten

Vielen Dank für Deine ausführliche Erklärung. Zu obigem linken Bild habe ich mal statt dem Parameter 'hochkant' px benutzt. Bei 345px gab es bei mir in allen Schriftgrößen-Einstellungen das gewünschte, selbe Ergebnis, mit 3 Zeilen auf kleinst möglichem Raum. Während bei 344px die Bildlegende auf 5 Zeilen umsprang. Brächte die Verwendung von px gegenüber dem Parameter 'hochkant' irgendwelche Vorteile? Vermutlich nach Deiner Erläuterung nicht. --Kim117 (Diskussion) 17:46, 10. Mai 2018 (CEST)Beantworten

wie vor einiger Zeit im Kurierbeitrag in der Wikipedia bereits angekündigt wurde, beteiligt sich Wikimedia Deutschland mit dem Projekt „Wiki Loves Monuments goes ECHY 2018“ (ECHY steht für „European Cultural Heritage Year“) am Europäischen Jahr des Kulturerbes. Durch dieses Projekt sollen der Fotowettbewerb weiterentwickelt, die Bekanntheit der Arbeit der Freiwilligen erhöht und auf einem Austausch- und Planungsportal zum Europäischen Kulturerbe auf Wikimedia Commons zur Teilnahme und Mitgestaltung eingeladen werden.

Wie dort dargestellt, sieht es ein Projektbaustein vor, dass der Fotowettbewerb Wiki Loves Monuments weiterentwickelt wird. Dazu wird die aktuelle (technische) Entwicklung, Objekte in ungewohnten Darstellungen zu präsentieren, aufgegriffen und u. a. ein Fokus auf 360°-Panoramen gelegt. So wird es im Rahmen von „Wiki Loves Monuments goes ECHY 2018“ folglich auch Sonderpreise für 360°-Panoramen von Kulturerbestätten geben.

Damit solche Panoramen entstehen können, benötigen freiwillige Fotograf_innen den Zugang zu Kulturerbestätten. Um diesen Zugang zu erleichtern, möchte Wikimedia Deutschland ein Unterstützungsdokument bereitstellen, um freiwilligen Fotograf_innen eine Argumentationshilfe an die Hand zu geben und den Besitzenden und (Zugangs-)Verwaltenden von Kulturerbestätten Informationsmaterial zur Verfügung zu stellen und so möglichst Bedenken oder Vorurteile gegenüber Wikipedia, Wikimedia Commons und freien Lizenzen auszuräumen.

Dieses Dokument soll in Form eines Flyers in gedruckter und digitaler Form erscheinen. Für die Textinhalte gibt es einen ersten Entwurf (Google Doc – zum kommentieren ist kein Account/keine Anmeldung vorausgesetzt). Ich würde mich freuen, wenn ihr zu diesem Dokument bis zum 11.06. Kommentare, Verbesserungsvorschläge und Korrekturen hinterlassen könntet. Das Layout und alles weitere zur äußerlichen Erscheinung erfolgt zu einem späteren Zeitpunkt.

Bei Rückfragen stehe ich euch gern zur Verfügung und danke euch schon mal für euer Feedback.

--Jonas Sydow (WMDE) (Diskussion) 11:04, 4. Jun. 2018 (CEST)Beantworten

wird bei mir falsch angezeigt (gedreht um 90°)--Wheeke (Diskussion) 08:17, 21. Sep. 2018 (CEST)Beantworten

Bei mir nur teilweise, sowohl IE11 und FF52 unter Win7, als auch DuckDuckGo und Chrome unter Android 8 zeigen das richtig. Die App auf dem Wischhandy kann sich allerdings nicht einigen: Unten im Artikel selber wird es liegend, oben in dem üblichen Vorschaubild korrekt ausgerichtet angezeigt. Grüße vom Sänger ♫ ^(Reden) 09:44, 21. Sep. 2018 (CEST)Beantworten

Sieht bei mir normal aus, allerdings wurde das Bild →mal gedreht, vermutlich eine alte Serverversion.

Bitte auch das Intro dieser Seite beachten, deine Anfrage hat nicht wirklich etwas mit der „Gestaltung der Seite Hilfe:Bilder“ zu tun. --Liebe Grüße, Lómelinde Diskussion 10:03, 21. Sep. 2018 (CEST)Beantworten

Das ist freilich richtig. An welche Hilfeseite kann ich mich denn bitte wg solches Problems wenden?--Wheeke (Diskussion) 10:17, 21. Sep. 2018 (CEST)Beantworten

Vermutlich WP:FZW. Grüße vom Sänger ♫ ^(Reden) 10:19, 21. Sep. 2018 (CEST)Beantworten

Steht im Intro: „Fragen zum Hochladen oder Sonstigem können in der Wikipedia:Redaktion Bilder […]“

Gegenfrage ist es noch immer gedreht? Ich habe den Artikel eben mal bearbeitet, um den Server anzustoßen. --Liebe Grüße, Lómelinde Diskussion 10:23, 21. Sep. 2018 (CEST)Beantworten

In der App noch immer, sonst wie gehabt. Grüße vom Sänger ♫ ^(Reden) 10:28, 21. Sep. 2018 (CEST)Beantworten

Immer noch gedreht, firefox. --Wheeke (Diskussion) 11:05, 21. Sep. 2018 (CEST)Beantworten

Bei mir auch Firefox und Win7. Alles normal, aber gestern war Softwareupdatetag. Vielleicht haben die etwas im Bereich Bilder umgebogen. --Liebe Grüße, Lómelinde Diskussion 11:10, 21. Sep. 2018 (CEST)Beantworten

Noch eine Nachfrage, ist bei dir der Medienbetrachter aktiviert? Ich habe zwar auch das getestet, und bei mir sieht alles normal aus, aber da diese Frage hier Wikipedia:Fragen zur Wikipedia#Schwarzer Bildschirm auch gerade hereinkam scheint doch irgendetwas geändert worden zu sein. --Liebe Grüße, Lómelinde Diskussion 11:13, 21. Sep. 2018 (CEST)Beantworten

Diese Bilddatei hat einen Knacks, den sie sich zugezogen hatte, als sie früher mal gedreht wurde. Dabei wurden Fehler gemacht, das ist bekannt. Manche Darstellungswerkzeuge berücksichtigen die halbfertige Drehung, manche ignorieren den Versuch. Auf Commons erörtern, hier absolut falsch. LG --PerfektesChaos 12:06, 21. Sep. 2018 (CEST)Beantworten

Habe nun das aus es: rüberkopiert mit den Formatierungen. steht zwar jetzt richtig. dennoch bleibt der Wurm drin--Wheeke (Diskussion) 13:55, 21. Sep. 2018 (CEST)Beantworten

Benutzer:Steinsplitter hat bei dem Bild im Jan. 2017 das EXIF Rotation-Flag von 6 auf 1 gesetzt (ist zumindest etwas ungewöhnliches). Er sollte daher informiert sein was hiermit geschehen ist. --Summer • Streicheln • Note 07:54, 26. Sep. 2018 (CEST)Beantworten

Auf der Vorderseite ist im Abschnitt "Panoramabilder" zu lesen, das Bild solle nie größer werden als die Breite der Druckversion (ca. 780px). Heißt das, dass in der Vorlage {{Panorama}} die Bildgesamtbreite höchstens mit 780 angegeben werden soll? Ist mir neu, wird in der Vorlagendokumentation nicht erwähnt und mannigfach anders gehandhabt. Es wird aber in Diskussion:Blauen (Badenweiler)#Illustration von meinem Gegenüber behauptet. --Milseburg (Diskussion) 20:34, 30. Okt. 2018 (CET)Beantworten

So wie ich das sehe, bezieht sich das 780px auf Panoramabilder (Bilder mit Breite viel größer als Höhe), die über die normale Bild-Syntax eingebunden werden. Ein breites Bild ist dann häufig breiter als das Browserfenster und erzeugt ein Scrollbalken am Browserfenster. Beispiel mit 1000px:

Die {{Panorama}} ist eine Möglichkeit Panoramabilder breiter einzubinden. Der Scrollbalken erscheint dann hier am Bild selbst und nicht am Browserfenster. Beispiel mit 1000px:

vergrößern und Informationen zum Bild anzeigen

Blick von der Terrasse des Blauenhauses nach Süden auf die Alpenkette.

--Fomafix (Diskussion) 10:56, 31. Okt. 2018 (CET)Beantworten

Fomafix: du solltest bei deinem Bsp. mit 1000px noch ne Schippe drauf legen ... sonst verstehen dich Leute, die einen breiten Bildschirm haben nur schwer. --Summer • Streicheln • Note 11:58, 31. Okt. 2018 (CET)Beantworten

Hier das gleiche Beispiel mit 1500px:

Bild-Syntax:

{{Panorama}}:

vergrößern und Informationen zum Bild anzeigen

Blick von der Terrasse des Blauenhauses nach Süden auf die Alpenkette.

--Fomafix (Diskussion) 12:13, 31. Okt. 2018 (CET)Beantworten

Danke für die Info. Ich verstehe. Allerdings habe ich wohl einen sehr breiten Bildschirm. Bei 1500px sehe ich auch keinen Unterschied. Ab 2000px wird es aber deutlich. Ich schlage vor, dass auf der Vorderseite klarer formuliert wird, dass die 780px nicht der Maximalwert für die Angabe der Bildschirmbreite in der Vorlage Panorama sind. Sonst fangen manche User an, die Werte überall herabzusetzen, wo die Vorlage Panorama verwendet wird. --Milseburg (Diskussion) 15:53, 31. Okt. 2018 (CET)Beantworten

Die 780px hat Benutzer:W!B: am 2. Mai 2006 eingebracht. Damit sah die Seite so aus. Das damalige Beispiel mit div-Einbindung nahm 2000px als Bildbreite und nicht etwa 780. Die Vorlage:Panorama gab es zu dem Zeitpunkt noch gar nicht. --Sitacuisses (Diskussion) 07:46, 1. Nov. 2018 (CET)Beantworten

Es ist auf jeden Fall nicht sinnvoll, die Pixelbreite über 780px hinaus zu vergrößern weil man damit in Kauf nimmt, dass ein Scrollbalken auftaucht. Gerade wenn man auch nur auf 1000px geht so fehlen oft nur 10-20% der Bildbreite je nach Einstellung und das ist weder nötig noch zielführend. Sofern ein Bild tatsächlich so ein extremes Bildverhältnis zwischen Höhe und Breite hat, dass man mit 780px nicht hinkommt weil alles zu klein wird, muss man das Bild entweder aus dem Artikel raus lassen oder aber auf eine entsprechend hohe Pixel-Zahl setzen. Ein Scrollbalken macht nur dann wirklich Sinn wenn man auch einen entsprechend großen Bereich des Bildes damit abfahren kann. Alles andere ist nur nervig. --Alabasterstein (Diskussion) 09:23, 1. Nov. 2018 (CET)Beantworten

Von welcher der zahlreichen heute üblichen, sehr unterschiedlichen Bildschirmauflösungen vom Smartphone bis zum Großmonitor gehst du gerade aus? Inwiefern schlägt sich die Entwicklung der letzten mehr als 12 Jahre in deiner Einlassung nieder? Und welcher deiner Sätze gilt: "Es ist auf jeden Fall nicht sinnvoll, die Pixelbreite über 780px hinaus zu vergrößern" oder "muss man das Bild [...] auf eine entsprechend hohe Pixel-Zahl setzen"? --Sitacuisses (Diskussion) 14:06, 1. Nov. 2018 (CET)Beantworten

Hättest du meinen Beitrag auf der Diskussionsseite des Artikels aufmerksam gelesen, müsstest du diese Frage nicht stellen. Es ist auch nicht primär eine Sache der Auflösung. --Alabasterstein (Diskussion) 14:26, 1. Nov. 2018 (CET)Beantworten

Ich habe dir heute schon viel zu viel Aufmerksamkeit geschenkt und bin zum Ergebnis gekommen, dass du nicht weißt wovon du sprichst und das durch Anblaffen deiner Gesprächspartner kompensieren möchtest, was naturgemäß nicht funktioniert. --Sitacuisses (Diskussion) 16:08, 1. Nov. 2018 (CET)Beantworten

Dann frag nicht wenn du dich damit nicht auseinander setzen willst. Und: wie es in den Wald reinschallt, so schallt es auch heraus. Also erspar uns bitte diese gemiemte Diskussionsbereitschaft gleich ganz. --Alabasterstein (Diskussion) 16:13, 1. Nov. 2018 (CET)Beantworten

Wer eine 'Überbreite' (als Bsp. mal 1.500px) so einbinden möchte, das sie die Bildschrimbreite optimal ausnutzt ohne am Browserfenster einen Scrollbalken zu erzwingen hat zwei Optionen:

• Will er, das Detail erkennbar sind, dann muss er die Vorlage Panorama nehmen. Gibt er in der Panoramavorlage eine Breite von 1.500px an, dann erscheint das Bild detailreich. Auf Browserfenstern mit eine Nettobreite bis 1.500px hat das Bild einen Scrollbalken. Sollte das Browserfenster mehr als eine Nettobreite zur Verfügung stellen, werden die Ränder weiß aufgefüllt. Die Detailtreue bleibt bei allen Fenstergrößen gleich.
• Wenn es auf die Detailtreue nicht ankommt, dann muss man die Technik einsetzten, die im Abschnitt „Breites Bild via gallery“ beschrieben ist (habe ich mal eingebaut). Mit der Technik wird auf Detailtreue immer gepfiffen, aber die Nettobreite wird immer optimal ausgenutzt.

Alles andere (feste Pixelbreiten, Parameter Hochkant) ist Murks! --Summer • Streicheln • Note 16:37, 1. Nov. 2018 (CET)Beantworten

Danke, Sitacuisses, dass du W!Bs Edit von 2006 ausgegraben hast. Wenn man vergleicht, was damals gemeint war und heute dasteht, ist die aktuelle Fassung sinnentstellt. Der Trick, von dem W!B damals sprach ist ja heute die Vorlage Panorama. Daher als Formulierungsvorschlag: "Panoramabilder einzubinden ist immer eine gewisse Herausforderung. Grund dafür ist, dass die Größe des Browser-Fensters des Lesers nicht direkt ermittelt werden kann: Also sollte das Bild nie größer werden als die Breite der Druckversion (ca. 780px). Um breitere Bilder einzubinden sollen die Vorlagen {{Panorama}} und {{Große Imagemap}} verwendet werden." Von mir aus, kann das mit den 780px auch ganz raus. Ob die Vorlage "Große Imagemap" noch aktuell ist, weiß ich gar nicht. Ich habe die noch nie verwendet. Stattdessen begegnet mir seit einigen Jahren zum Einbinden von Panoramen auch die Galerie "packed" wie etwa bspw. hier: Sackpfeife (Berg)#Lage. Ich weiß da nie so genau, welche Art der Einbindung ich da nehmen soll. Ich würde es begrüßen, wenn auch dazu mal etwas Erhellendes auf der Vorderseite gesagt werden könnte. --Milseburg (Diskussion) 16:39, 1. Nov. 2018 (CET)Beantworten

Quetsch als Info: die Sackpfeife wurde hier auf gallery umgestellt. --Summer • Streicheln • Note 17:09, 1. Nov. 2018 (CET)Beantworten

Anmerkung: Die Einbindung des Panoramas in Sackpfeife wurde wurde heute von Benutzer:Antonsusi verändert. Ich weiß nicht, ob er diese Disk. kennt. Jedenfalls ist jetzt nur noch in älteren Versionen der Sackpfeife erkennbar, was ich gemeint habe. Ein mit der Galeriefunktion eingebundenes Panorama sieht man bspw. aktuell auch hier: Katinger Watt#Panorama --Milseburg (Diskussion) 13:45, 4. Nov. 2018 (CET).Beantworten

Unter Spezial:Weiterleitung/revision/180996187#Lage bleibt die alte/mittlere Sackpfeife selbstverständlich verfügbar. --Diwas (Diskussion) 00:41, 5. Nov. 2018 (CET)Beantworten

Wie das mit den 780px damals gemeint war oder nicht mag historisch interessant sein. Das Problem wird damit nicht beseitigt. Scrollbalken sind gem. der Barrierefreiheit ganz zu vermeiden. Das gilt nicht nur für Bilder sondern auch für Tabellen mit einer gewissen Überbreite. Diese kann zwar nicht immer vermieden werden. Aber der Grundsatz sagt: es ist generell darauf zu achten und wo möglich zu vermeiden [1]. Wenn nun ein Bild mit 1000px einen Scrollbalken erzeugt dann sind diese 1000px nicht sonderlich weit von den 780px entfernt. Das bedeutet dann für das Bild auch kaum eine merkliche Verkleinerung bei gleichzeitiger Vermeidung der Vorlage Panorama bzw. wenn man sie verwendet und auf diesen Wert setzt dann entsteht dennoch kein Scrollbalken. Da die Anforderungen für die Barrierefreiheit sicherlich mal umfassender gilt als die Vereinbarungen für Bilder sollten selbstverständlich auch bei der Darstellung der Bilder darauf geachtet werden. --Alabasterstein (Diskussion) 17:02, 1. Nov. 2018 (CET)Beantworten

Das von Milseburg zitierte Beispiel mit Sackpfeife (Berg)#Lage finde ich übrigens ausgesprochen gut und sauber in der Darstellung. --Alabasterstein (Diskussion) 17:05, 1. Nov. 2018 (CET)Beantworten

Und selbst für 360-Grad-Panorama-Aufnahmen reicht eine Pixelbreite von "um die 800 Pixel" völlig aus, wie das Bild in diesem Abschnitt Eiffelturm#Dritte_Etage_und_Turmspitze zeigt. Die Bildwirkung wird auch in dieser kleinen Darstellung erfasst. Und niemand wird daran gehindert, in das Bild reinzuklicken und es auch in der vollständigen Auflösung zu betrachten. Aber das Bild nun auf 1000px oder 1500px zu strecken bringt (a) nur den unerwünschten Scrollbalken (b) macht den Gesamteindruck des Bildes zunichte weil es faktisch abgeschnitten wird und man gezwungen ist, zu scrollen und ist (c) auch nicht so groß, dass die Menschen, die sich das Bild gerne genauer betrachten würde damit befriedigt wären. Also ich erkenne darin wirklich keinen Nutzen oder Mehrwert. --Alabasterstein (Diskussion) 17:11, 1. Nov. 2018 (CET)Beantworten

Mit Alabasterstein kann man sicher auch eine Löschdiskussion über die Vorlage Panorama führen. Ich verstehe en-WP zur Barierefreiheit durchaus so, dass horizontales Scrollen zulässig ist, wenn es nicht übermäßig ist. Und die Vorlage Panorama ermöglicht genau das. Man scrollt nur beim Bild und nicht beim ganzen Artikel. Ich finde durchaus, dass die Bildwirkung eines Panoramas leidet, wenn es nur noch als winziger Streifen dargestellt wird. Das kann nicht besser sein, besonders nicht für Menschen mit Sehbehinderung. Ich fand auf de-WP dazu bisher keinen Konsens. --Milseburg (Diskussion) 17:56, 1. Nov. 2018 (CET)Beantworten

Wenn die Bildwirkung eines Panoramas schlecht ist obwohl es die gesamte Standard-Artikelbreite zur Verfügung hat dann ist es nichts weiter als ein schlechtes Bild und durch die parametrisierbare Breiteneinstellung auch nicht verbesserbar.

Details kann man auch bei Verdoppelung der Bildbreite nicht wirklich erkennen, so dass der Mehrwert nicht wirklich hinreichend begründet wird. Wenn ich mich bei einem Panorama, welches 25000x6000 Pixel misst (und solche Panoramas sind heutzutage auch keine Seltenheit mehr) für Details interessiere bin ich auch dann gezwungen, in die 100%-Ansicht zu wechseln auch wenn ich dem Bild in der Panorama-Funktion eine Bildbreite von 5000px zubillige. Horizontales Scrollen ist horizontales Scrollen, ob ich das am Artikel oder am Bild mache ändert nichts daran, dass Menschen mit Beeinträchtigungen das Erfassen unnötig erschwert wird. --Alabasterstein (Diskussion) 08:22, 2. Nov. 2018 (CET)Beantworten

Dieses Pauschalurteil ist eine Beleidigung all der Artikelbearbeiter, die Panoramen entsprechend ihres Bildinhaltes in Artikel einbauen. Es ist auch in sich nicht schlüssig, denn wenn die Panoramen, wie du meinst, eh nichts erkennen lassen, kann den Benutzern mit Beinträchtigung das Scrollen auch egal sein. Im übrigen habe ich den Eindruck, dass du noch nie eine Wikipedia-Seite auf einem Mobilgerät angeschaut hast, sonst würdest du nicht so viel von Scrollen reden. Versuche bitte wieder aus dem Geisterfahrer-Modus rauszukommen und konstruktiv mitzuarbeiten, das führt sonst zu nichts Gutem. --Sitacuisses (Diskussion) 08:59, 2. Nov. 2018 (CET)Beantworten

Dieses Panoramagedöns sollte aus Artikeln fernbleiben. Fotos, die als Vorschaubild nichts erkennen lassen, haben nichts in Artikeln zu suchen. Und Bilder, die man nur mit Sondersoftware angucken kann, sind völlig fehl am platz. --M@rcela 11:31, 2. Nov. 2018 (CET)Beantworten

Die Aussage „Und Bilder, die man nur mit Sondersoftware angucken kann, sind völlig fehl am platz“ kann ich zu 100% unterstützen. Hat dummerweise aber mit dieser Diskussion nichts zu tun weil der Benutzer bei Panoramabildern keine Sondersoftware einsetzen muss. --Summer • Streicheln • Note PS: mich stören Signaturen, die mit den Namen in der Versionsgeschichte in keinerlei Zusammenhang stehen. Macht Dritten nur unnötig Arbeit Diskussionen zu verfolgen ...

Es müßte erstmal geklärt werden, was mit Panoramaaufnahmen eigentlich gemeit ist. Da kommen mehrere Fälle in Frage:

1. Kugelpanoramen oder Ähnliches, dazu braucht man Spezialsoftware, sonst sind die Ansichten ziemlich sinnlos.
2. Bilder mit großem horizontalem Erfassungswinkel - kann man nicht pauschal einordnen, dieses Bild hat knapp 270° horizontal, ist als normales Vorschaubild brauchbar
3. Schlauchbilder mit wesentlich mehr Ausdehnung horizontal als vertikal - das muß aber nicht zwingend ein Panorama sein.

Letztere bieten nur begrenzt Aussagekraft. Egal, wie man sie einbindet, bereiten sie immer irgendwelche Probleme. Der Mehrwert hält sich in Grenzen. --M@rcela 18:13, 2. Nov. 2018 (CET)Beantworten

Das ist eine Frage der Seitenverhältnisse, zu denen Summer sich weiter unten schon ausführlich ausgelassen hat. Ich muss dir widersprechen. Wenn es um Aussichten (Berge, Türme) oder Übersichten (Landschaften) geht, besitzen eigentlich nur Bilder mit extremem Seitenverhältnis genügend Aussagekraft, z.B. Rimberg (Hinterland).--Milseburg (Diskussion) 18:26, 2. Nov. 2018 (CET)Beantworten

---

Neeeiiinnn, muss man nicht vorher klären! Aus dem Kontext geht hervor, das mit Panoramabilder alles gemeint ist, das viel breiter als hoch ist und auf dem man die Dinge erkennen kann ohne die Augen zu verdrehen (was denn beispielsweise bei Kugelpan. im Rohformat der Fall wäre). Meinetwegen kannst du das Bild eines Turms, das viel höher als breit ist gerne als (Sonderfall oder auch nicht) Panorama bezeichnen. In dieser Diskussion gehen wir vom ganz einfachen Fall aus. Einfach weil einfach einfach ist. --Summer • Streicheln • Note 18:32, 2. Nov. 2018 (CET)Beantworten

Sitacuisses: welche meiner Aussagen wertest du als Pauschalurteil? Darin bleibst du unklar. Sehr wohl lese ich Wikipedia auch mobil. Dein Eindruck ist folglich falsch. Editieren mit mobilen Endgeräten (bis auf Kleinigkeiten) ist mir freilich zu fummelig. Kenne aber auch niemanden, der größere Änderungen am Artikel an seinem Handy ausführt. Aber das ist leider auch nicht wirklich zielführend, weil die Barrierefreiheit ganz grundsätzlich mal für alle Endgeräte zu gelten hat. Dass man das nicht immer erfüllen kann ist klar. Hier aber haben wir es gleich mit mehreren Möglichkeiten zu tun, wie man Panoramen einbinden kann und dann ist es sicher mal legitim über die Möglichkeit zu diskutieren, die gewisse Probleme schafft. Bitte unterlasse Unterstellungen wie "Geisterfahrermodus" und "nicht konstruktiv", denn ansonsten muss ich davon ausgehen, dass in Ermangelung von Sachargumente du dich in persönliche Frotzeleien flüchtest, was ich bei dir aber generell oft beobachtet habe. --Alabasterstein (Diskussion) 12:17, 2. Nov. 2018 (CET)Beantworten

Die Bedenken im Zusammenhang mit der Barrierefreiheit sind nicht neu und wurden bei der Löschdiskussion zur Vorlage {{Panorama}} 2010 schon durchgekaut und zurückgewiesen. Der Löschantrag wurde abgelehnt, die Vorlage blieb und wird auch vielfach genutzt. Das brauchen wir hier nicht zu wiederholen. Mich würde eher eine Verbesserung der Formulierung auf der Vorderseite interessieren und was es zur Vorlage {{Große Imagemap}} und zu der Galeri-Alternative (s.o.) zu sagen gibt. Der Aufguss-Diskussion blendet das aus. PS: Wieso es für Menschen mit Beeiträchtigung besser sein soll, wenn man etwas kleiner macht, habe ich noch nicht verstanden. --Milseburg (Diskussion) 14:28, 2. Nov. 2018 (CET)Beantworten

Zur Barrierefreiheit: ich finde es sehr gut, das hier an selbige gedacht wurde. Weil genau das, also das 'im Hinterkopf behalten', wichtig ist. Daran Denken ist allerdings nicht mit darüber Diskutieren gleichzusetzen! Ohne jede Frage stellt die Vorlage Panorama für manche Menschen ein Barriere da. Auf der anderen Seite ermöglicht sie vielen Menschen "Blicke", die sie ohne die Vorlage nicht hätten. Der Gedankenlose Einsatz sollte entsprechend vermieden, der sinnvolle Einsatz durchgeführt werden. Das daran Denken ist das alles Entscheidende. Und leider leider geht Barrierefreiheit den Meisten Kollegen mehr als am Arsch vorbei.

Zu „Mich würde eher eine Verbesserung der Formulierung auf der Vorderseite interessieren und was es zur Vorlage {{Große Imagemap}} und zu der Galeri-Alternative (s.o.) zu sagen gibt“ (Zitat Milsbhrg): Auf Große Imagemap würde ich nicht weiter eingehen wollen. Das ist meines Erachtens eine Erweiterung der Vorlage Panorama mit Spielereien (Hier sind alle Einbindungen gelistet ... also so gut wie keine ... es gibt keine erkennbaren Vorteile, nur Nachteile für die Barrierefreiheit und das Ding sollte verschwinden).

Bleiben noch die Vorlage Panorama und die Gallerie-Technik. Als ich die Gallerie-Technik 2015/16 beschrieb, [2],[https:// de.wikipedia.org/w/index.php?title=Hilfe:Bilder&diff=153004150&oldid=152078810] hatte ich fast keine Hoffnung das sie auf der Seite bestand hat. Deshalb hielt ich den Aufwand in Grenzen.

Ein verbesserter Text sollte zwei Teile enthalten. Einen beschreibenden Teil, wie die Techniken jeweils angewandt werden. Also beispielsweise die Funktion der Parameter (das steht schon weitgehende da).

Als zweites sollte eine Empfehlung rein, wann welche Technik sinnvoll ist. Oben (1. Nov. 2018 16:37 Uhr) habe ich einen wichtigen Aspket aufgeschrieben, wann welcher Technik der Vorzug zu geben ist. Oben ging es um den Aspekt, ob es mehr auf den Überblick oder Detail ankommt.

Es gibt noch einen zweiten Aspekt, der für die Entscheidung wichtig ist. Milseburg hat das oben mit „winziger Streifen“ beschrieben. Dazu ein fiktives Beispiel: wenn ich mehrere Kilometer der chinesischen Mauer abfotografiere und durch Stichen ein Panorama erzeuge, erhalte ich ein sehr sehr breites Bild mit kaum Höhe. Als ganzes auf einem Bildschirm dargestellt, ergäbe es eine haardünne Linie. In dem Fall wäre die einzig sinnvolle Darstellung in wählbaren Ausschnitten - genau das macht die Panoramavorlage ja.

Für die Technik mit Gallerie gibt es also offenbar ein Band von sinnvollen Seitenverhältnissen. Hier habe ich mal ein paar Seitenverhältnisse aufgelistet.

• c:File:Panorama Schwerin Wasserturm Neumuehle.jpg: umseitig als Bsp. verwendet. Seitenverhältnis 11.070 / 852 = 12,992
• c:File:PanoBlauen-IMG 6623-6637 900.jpg: in dieser Disk. als Bsp. (bzw im Artikel Blauen (Badenweiler)) verwendet. Seitenverhältnis 6962 / 900 = 7,735
• c:File:Sackpfeifen-Vorhöhen.jpg: in dieser Disk. als Bsp. verwendet. Seitenverhältnis 2.591 / 485 = 5,342
• c:File:Panorama von der Milseburg.jpg: in Milseburg verwendet. Seitenverhältnis 15.922 / 2.000 = 7,961
• c:File:Forestry Forwarder Ösa 250 2.jpg: Bsp. für sehr breitformatiges Foto auf Vorderseite Seitenverhältnis 4.000 / 1.640 = 2,439

Ich würde sagen, das Seitenverhältnisse von etwa 4 bis 7,5 sinnvoll mit der Gallerie-Technik dargestellt werden können. die Vorlage Panorama macht etwa von 5,5 bis unendlich Sinn. Und unterhalb von 4 ist konventionelle Einbindung angezeigt (normale Bilder haben nebenbei ein Seitenverhältnis von 4:3=1,333 bis 3:2=1,5). Das wären nur grobe Richtwerte. Das Argument mit der Detailansicht oben bliebe.

Diese Grafik hat übrigens eine Seitenverhältnis von 6.000 zu 400 - also sage und schreiben 15! Und sie ist in Türkische Lira#Inflation sinnvoll eingebunden. Und wird sogar per Bot täglich aktualisiert. Die Vorlage Panorama kann also durchaus Sinn machen. --Summer • Streicheln • Note 16:47, 2. Nov. 2018 (CET)Beantworten

Danke für deine Erläuterungen, Summer. Ich möchte dich ermuntern, sie auch auf der Vorderseite umzusetzen. Ich denke, die {{Große Imagemap}} kann raus. --Milseburg (Diskussion) 18:33, 2. Nov. 2018 (CET)Beantworten