• Neuer Gutscheincode unseres Partners Schutzfolien24:
    DSLR-Forum2025
    Dauerhaft 10% Rabatt auf alle Displayschutzfolien und Schutzgläser der Eigenmarken
    "Upscreen", "Screenleaf", BROTECT" und "Savvies".
    Der Code ist für alle Geräteklassen gültig.
  • Stimmt ab über die Sieger des DSLR-Forum Fotowettbewerbs September 2025.
    Thema: "Straßenfotografie s/w"

    Nur noch bis zum 30.09.2025 23:59!
    Jeder darf abstimmen!
    Zur Abstimmung und Bewertung hier lang
  • Ich freue mich bekannt geben zu können, dass das DSLR-Forum einen neuen Aktionspartner gewinnen konnte.

    Saal Digital bietet Fotoprodukte in HighEnd-Qualität.
    Alle Informationen dazu gibt es demnächst hier.
  • In eigener Sache!

    Liebe Mitglieder, liebe Besucher und Gäste
    ich weiß, es ist ein leidiges Thema, aber ich muss es ansprechen: Werbung, Werbeblocker und Finanzierung des Forums.
    Bitte hier weiterlesen ...

  • Nicht erreichbare Adressen im Benutzerkonto
    Wir bekommen zurzeit eine große Anzahl an E-Mails, die das System zum Beispiel als Benachrichtigungen an Nutzer verschickt,
    als unzustellbar zurück, weil z.B. die Adressen nicht erreichbar sind oder das Postfach gar nicht existiert.
    Stellt doch bitte sicher, dass die Benachrichtigungen, die ihr vom System erwartet, auch zugestellt werden können.
    Nicht erreichbare E-Mail-Adressen sind dazu wenig hilfreich.
    Danke!
WERBUNG

Web-Fotos in 1:1-Auflösung noch zeitgemäß?

Bei Nutzung von JS geht das auch ohne cookie, wie es das von SssnakeDoc genannte Script leider erfordert.

Zwar wird tatsächlich ein Cookie gesetzt, aber wo ist das Problem? Das machen so viele Seiten und keinen juckt´s.

Auch JS haben nicht alle Nutzer aktiviert (was zwar Unsinn ist, aber Fakt).
 
Ich verstehe zwar bis bís heute nicht, warum so viele Leute auf ihren Tablets surfen, aber diese Unsitte (oder sind es nur die eigenen, schlechten Augen?) muss ich halt irgendwann akzeptieren, wenn ich die mind. 15% der Besucher nicht von der Seite ausschließsen will,
Tablets haben gegenüber regulären PCs/Notebooks einen Vorteil: Man kann relativ schnell Teile der Seite per Fingergeste vergrößern. Tablet-Besitzer tun das auch ständig - oft schon ganz unbewusst. Von daher muss auch nicht immer alles schon in Normaldarstellung perfekt groß und gut lesbar sein.
Andererseits stellt diese Möglichkeit noch höhere Anforderungen an die Bildqualität; was in Normaldarstellung noch fein aufgelöst aussieht, wird durchs Zoomen dann unscharf und artefaktbeladen.

Es gibt je nach Gerät und Software anscheinend eine Obergrenze fürs Zoomen; daran könnte man sich orientieren. Wovon die abhängt, habe ich noch nicht rausbekommen.

Wie die Tablet-Browser standardmäßig (d. h. beim Öffnen der Seite) skalieren, ist mir ebenso ein Rätsel. Es funktioniert auf jeden Fall anders als an regulären Browsern, die die Seiten entweder 1:1 oder mit einer bestimmten Skalierung zeigen. Es gibt im Mobilbrowser keinen festen Zoom-Wert von z. B. 150 oder 200%, sondern die Standarddarstellung hängt von der Konstruktion der Seite ab.

Ich habe z. B. auf meinen Seiten die Breite im CSS mittels "max-width" definiert in der Meinung, Geräte mit kleineren Bildschirmen würden sich dann anpassen und die Schriftgröße normal halten. Ein normaler Desktop-Browser, dessen Fenster man verkleinert, tut das auch. Dagegen der mobile Browser macht von der Verschmälerung keinen Gebrauch; stattdessen gibt es dort relativ lange Zeilen, und der Text wird sehr klein.
 
Eigentlich hatte ich gedacht, mit meinen Experimenten aus #15 eine ebenso einfache wie praktikable Möglichkeit gefunden zu haben: Bilder grundsätzlich in vierfacher Auflösung anlegen, aber dann deutlich stärker komprimieren.

Leider hat sich gezeigt, dass das in der Praxis gar nicht so leicht umzusetzen ist.
In dem HTML-Editor, den ich bisher verwende (Dreamweaver CS4) kann ich zwar grundsätzlich die großen Bilder einbinden und auf halbe Ausgabelänge und -höhe einstellen (so hatte ich ja auch die Testseite erstellt), aber das geht alles nur manuell. Ich muss also für jedes einzelne Bild, das ich einbinden will, die Höhe und Breite Größe durch Kopfrechnen oder per Taschenrechner halbieren und entsprechend eintragen. Es gibt in der Software nichts, womit man das halbwegs automatisieren könnte.
Da ich mittelfristig über die Migration meiner Seiten auf Wordpress nachdenke, habe ich dort entsprechende PlugIns gesucht und bin ebenso wenig fündig geworden. Es gibt zwar eine Reihe von Retina-Optimierungs-PlugIns, aber die arbeiten alle sehr kompliziert und versuchen, vorab die Auflösung des Displays festzustellen und dann geich die richtige Bildgröße zu liefern. Das setzt außerdem voraus, dass man die interne Skalierung von Wordpress verwendet und Bilder in höherer Auflösung hochlädt, aus der das PlugIn dann alle Bildgrößen selber skalieren kann. Das gefällt mir aus verschiedenen Gründen nicht, z. B. weil ich ein Logo/Wasserzeichen in immer gleicher Größe in die Bilder setzen möchte (und zwar manuell platziert, nicht automatisch per PlugIn).
Am ehesten würde noch das PlugIn "WP Retina 2x" funktionieren, wenn man es auf den "Debug Mode" stellt, der ungeachtet der Ziel-Display-Auflösung immer das Bild in Retina-Auflösung einbettet. Aber der Debug-Mode ist eigentlich nicht für den Dauerbetrieb vorgesehen und schreibt immer automatisch ein "log file".

Am liebsten wäre mir ein Verfahren, bei dem ich Bilder in Retina-Endauflösung hochladen und ohne weitere Maßnahmen so einbinden könnte, dass sie mit exakt halbierter Vertikal- und Horizontalauflösung auf den Seiten erscheinen. Noch habe ich so eine Option nicht gefunden.
Kennt jemand vielleicht eine Möglichkeit mittels CSS? Also eine Option, Bilder grundsätzlich in halber Höhe und Breite einzubetten? Bisher habe ich nur die Möglichkeit gefunden, eine feste Maximalgröße zu definieren.
 
Zuletzt bearbeitet:
Ich muss also für jedes einzelne Bild, das ich einbinden will, die Höhe und Breite Größe durch Kopfrechnen oder per Taschenrechner halbieren und entsprechend eintragen. Es gibt in der Software nichts, womit man das halbwegs automatisieren könnte.
Dann würde ich einfach die großen Bilder per Script (oder mittels IrfanView-Batch) auf 50% skalieren, diese Bilder in die Seite einbinden und danach das JPG vor dem Publizieren wieder tauschen (das kann man per Batch-Script auch automatisch durchführen). Man muss nur aufpassen, dann die originale eine durch zwei teilbare Größe besitzen.

Aber gut, das ist halt "meine" gute, alte manuelle Methode ohne HTML-Editor und dem FTP-Client als Upload-Tool, bei der ich genau weiss, was wo liegt, was ich hochlade und dass mir kein Editor dort irgendwie herein pfuscht. Ob das mit Dreamweaver auch geht, weiss ich nicht.

Tablets haben gegenüber regulären PCs/Notebooks einen Vorteil: Man kann relativ schnell Teile der Seite per Fingergeste vergrößern.
Ob man das als Vor- oder Nachteil sieht, ist wohl Geschmackssache.

Es gibt je nach Gerät und Software anscheinend eine Obergrenze fürs Zoomen; daran könnte man sich orientieren. Wovon die abhängt, habe ich noch nicht rausbekommen.
Wenn ich den Max-Zoom meiner zwei Android-Browser sehen (Chrome und den von CyanogenMod), dann ist das ca. Faktor 6-7.5, womit man schon ganz nah an den zuvor erwähnten 800ppi wäre.

Bei Chrome kann man auch noch die Zoom-Verhinderung der Webseite deaktivieren. Wer das tut und sich danach wundert, wenn die Bilder schlecht aussehen, ist m.M. nach selber Schuld.

Zwar wird tatsächlich ein Cookie gesetzt, aber wo ist das Problem? Das machen so viele Seiten und keinen juckt´s.
Ich mag sowas halt persönlich nicht, wenn es für die Seite nicht zwingend nötig ist. Von den unbekannten rechtlichen Dnigen in der EU (wir wurden hier ja auch vor ein paar Wochen von dieser schwachsinnigen Zwangsbestätigung genervt) mal ganz zu schweigen.

Die meisten Desktop-Surfer dürften auch immer noch Flash aktiviert haben, trotzdem kommt auf meine Seite keine Flash-galerie.

Auch JS haben nicht alle Nutzer aktiviert (was zwar Unsinn ist, aber Fakt).
Ja und? Dann gehen halt ein paar (unwichtige) Funktionen nicht so, wie von mir gedacht. Die Seite bleibt bedienbar (im Gegensatz zu vielen anderen Seiten). Mehr ist mir für meine Seite nicht wichtig.

Dass eiine einzig per JS aufrufbare Bildanzeige zusätzlich noch negative Auswirkungen in der Google-Bildersuche haben kann, hätte ich zwar nicht erwartet, war aber zumindest Anfang des Jahres so.
 
Kennt jemand vielleicht eine Möglichkeit mittels CSS? Also eine Option, Bilder grundsätzlich in halber Höhe und Breite einzubetten? Bisher habe ich nur die Möglichkeit gefunden, eine feste Maximalgröße zu definieren.
CSS allein bekommt sowas nicht hin. Dafür ist zusätzliches JavaScript nötig. Und Prozentangaben statt Pixelangaben helfen beim IMG-Tag auch nicht weiter, weil sich diese immer aufs Elternelement des IMG-Tags beziehen, und somit die tatsächliche Bildgröße völlig ignorieren.
 
Kennt jemand vielleicht eine Möglichkeit mittels CSS? Also eine Option, Bilder grundsätzlich in halber Höhe und Breite einzubetten? Bisher habe ich nur die Möglichkeit gefunden, eine feste Maximalgröße zu definieren.

Entweder so: <img style="width: 50%">, also als Style-Attribut oder zentral in der CSS-Datei: img { width: 50%;}

Probier mal aus.

Den Umzug auf Wordpress würde ich noch einmal überdenken. Ich bin mittlerweile von CMS komplett weg. Sicherheitsgründe, wenn die Core-Dateien geändert werden, passen die Layouts evtl. nicht mehr etc.
 
Und Prozentangaben statt Pixelangaben helfen beim IMG-Tag auch nicht weiter, weil sich diese immer aufs Elternelement des IMG-Tags beziehen, und somit die tatsächliche Bildgröße völlig ignorieren.

Wenn die Angaben als HTML-img-Attribut gesetzt werden.

Bin nicht sicher, ob das mit CSS nicht doch so funktioniert, wie ich oben geschrieben habe. Mal ausprobieren.
 
Ob das mit Dreamweaver auch geht, weiss ich nicht.
Das geht problemlos. Dreamweaver pfuscht nur nach expliziter Aufforderung im Quellcode einzelner Seiten herum und ändert auch nur exakt das was man will. Vollautomatisch läuft da nichts.
Dass eine einzig per JS aufrufbare Bildanzeige zusätzlich noch negative Auswirkungen in der Google-Bildersuche haben kann, hätte ich zwar nicht erwartet, war aber zumindest Anfang des Jahres so.
Suchmaschinenbots betrachten Webseiten für gewöhnlich aus reiner HTML-Sicht dazu kommt lediglich noch eine CSS-Betrachtung um eventuell Gewichtungen der Wichtigkeit zu erkennen und auch unerwünschte Tricksereien. JavaScript-Einflüsse bleiben somit außen vor.
 
Dann würde ich einfach die großen Bilder per Script (oder mittels IrfanView-Batch) auf 50% skalieren, diese Bilder in die Seite einbinden und danach das JPG vor dem Publizieren wieder tauschen (das kann man per Batch-Script auch automatisch durchführen).
Zumindest für die Erst-Einrichtung der Seite würde das lohnen, um in einem Rutsch viele Bilder zu ändern. Künftige Bilder würde ich dann eher wieder manuell anpassen.

Die meisten Desktop-Surfer dürften auch immer noch Flash aktiviert haben, trotzdem kommt auf meine Seite keine Flash-galerie.
Ich habe Flash seit geraumer Zeit nur noch nach manueller Genehmigung freigeschaltet - und bin angenehm überrascht, wieviele Seiten mittlerweile ohne Flash auskommen. Es betrifft überwiegend noch Seiten von kleineren Firmen etc., die schon vor längerer Zeit erstellt und seither nicht grundlegend überarbeitet wurden.

Bin nicht sicher, ob das mit CSS nicht doch so funktioniert, wie ich oben geschrieben habe. Mal ausprobieren.
Leider geht es nicht. Die 50 % beziehen sich dann tatsächlich auf das übergeordnete Element.

Den Umzug auf Wordpress würde ich noch einmal überdenken. Ich bin mittlerweile von CMS komplett weg. Sicherheitsgründe, wenn die Core-Dateien geändert werden, passen die Layouts evtl. nicht mehr etc.
Für mich dürfte die Umstellung überwiegend Vorteile haben (Editieren der Seite von jedem Rechner aus ohne spezielle Software etc.).
Außerdem scheue ich auf längere Sicht die manuelle Weiterentwicklung des Webdesigns, weil ich doch mehr am Inhalt als an der Form interessiert bin. (Heute ist das große Thema Responsive und Retina; keine Ahnung, was es morgen ist.) Mit Wordpress bekomme ich durch Themes und PlugIns Vieles bequem geliefert, was ich mir sonst mühsam nach Einarbeitung zusammenprogrammieren müsste.
 
Das ist noch nicht so sicher, weil die Seiten überarbeitet und mit mehr Bildern ausgestattet werden sollen.
Ich hatte außerdem gehofft, das Verfahren dann auf Wordpress übertragen zu können (wo ja letztlich auch alles mit CSS formatiert wird).
 
Das ist noch nicht so sicher, weil die Seiten überarbeitet und mit mehr Bildern ausgestattet werden sollen.
Ich hatte außerdem gehofft, das Verfahren dann auf Wordpress übertragen zu können (wo ja letztlich auch alles mit CSS formatiert wird).

Solange es sich nicht um Abertausende Bilder handelt, halte ich den Aufwand für überschaubar. Manches wirst du vielleicht sogar mit BEARBEITEN - ERSETZEN lösen können.

Da es sich ja um reinen CSS-Code handelt, kannst du den doch bestimmt in die CSS-Dateien deines Wordpress-Designs integrieren.
 
WERBUNG
Zurück
Oben Unten