# Warum "resizen" Browser Bilder so häßlich

## manuels

Hallo zusammen,

ich frage mich gerade warum Bilder, die in Webbrowsern nicht in ihrer nativen Größe angezeigt werden immer "so häßlich" angezeigt werden.

Wenn man die Größe eines Bildes in GIMP o.ä. ändert sieht es 100x besser aus.

Warum implementieren Mozilla, MS & co keine "schönen" Algorithmen dafür? An der Rechenzeit kann es doch eigentlich nicht liegen, oder?

Geht mir gerade nur so durch den Kopf und ich kann beim besten Willen keinen Grund finden - ihr vielleicht?

Tschö mit ö

Manuel

----------

## misterjack

 *manuels wrote:*   

> An der Rechenzeit kann es doch eigentlich nicht liegen, oder?

 

Da hast du den wunden Punkt getroffen. Bei einem einzelnen Bild wird man es eher nicht merken, jedoch bestehen manche Seiten aus Zig-Bildern, die womöglich auch nichtmal in Originalgröße angezeigt, sondern vom Browser resized (durch HTML vorgegeben) werden müssen. In Eye Of Gnome ein wenig das Mausrad bewegen (= resizen), bringt meine CPU (3800+) auf >40%.

----------

## schachti

Außerdem soll es ja auch Anwender mit älteren Rechnern geben - wenn man denen einen aufwendigen Algorithmus vorsetzt, warten die zwei Minuten, bevor die Website dargestellt wird.   :Wink: 

----------

## franzf

Ich kann das hier jetzt ehrlich gesagt nicht nachvollziehen. Die einzigen Seiten die ich kenne, welche Bilder resizen sind imageshack.com &co. Mit normalen Seiten, deren Layout mit Bildern erstellt wird, hab ich keine Probleme. Da sind ja meist die Bilder auf die Webseite zugeschnitten. Diese Bilder sind dann auch meist recht klein (ehrlich, wenn ich auf eine Seite geh, bei der Bilder für das Layout von 1600x1400 auf 30x20 skaliert sind, war das mein letzter Besuch...) und damit sollte der Rechenaufwand für SMOOTH_PIXMAP_TRANSFORM  minimal sein.

Wen es also wirklich stört der kann ja mal bei "seinem" Browserhersteller anfragen, ob man nicht eine Option einbauen könnte ala "Bilder mit weniger als XXX Pixel oder einer Größe von YY KB weich skalieren".

Hat vllt. noch einer eine Seite, bei der Layoutgrafiken skaliert werden und das k**** ausschaut?

Grüße

Franz

----------

## franzf

 *misterjack wrote:*   

> In Eye Of Gnome ein wenig das Mausrad bewegen (= resizen), bringt meine CPU (3800+) auf >40%.

 

Der Vergleich hinkt  :Wink: 

1) Wird auf einer Homepage ein Bild genau ein mal (1x) skaliert. Beim Scrollen in EOG gibts ja zig resizeEvent()s.

2) In EOG geht wohl die meiste CPU-Zeit beim Zeichnen drauf. Schieb mal ein Fenster schnell hin und her, da geht die CPU-Last auch ziemlich rauf  :Wink: 

3) Komm ich mit Gwenview (KDE4) selbst bei wildestem resizen nie über 18% CPU-Zeit  :Very Happy:  (Bild: 1280x1024) Und ich hab auch einen AMD64 3800+ (Singlecore)

Ergo:

Ein Bugreport könnte da vllt. wirklich was bringen!

Grüße

Franz

----------

## manuels

Naja, ich komme darauf, da ich unsere Vereinshomepage hoste und viele Noops Artikel schreiben und die Bilder von ihrer Digitalkamara direkt in den Artikel stellen und verkleinern   :Rolling Eyes: 

Das sieht dann nicht nur bloede aus, sondern belastet auch die Bandbreite unnoetig (aber hier will ich mir gerade Abhilfe verschaffen).

Zum CPU-Last-Argument bzw. -Nicht-Argument: Man koennte ja auch in den Einstellungen festlegen ob man das 'smooth-resizen' haben moechte, oder nicht.

Oder der Rechner erkennt wieviel CPU-Zeit auf dem Rechner dafuer verbraten wird und stellt sich automatisch darauf ein.

So das grosse Problem seh ich darin nicht.

----------

## xraver

Könnte es auch daran liegen das Bildeditoren das Bild glätten und Browser eben nicht?

----------

## manuels

Ja, aber wieso machen es die Browser nicht.

Wir haben ein das mit der CPU-Zeit lass ich nicht gelten, da franzf sagt, dass es die CPU nicht so stark belastet wie misterjack meinte.

----------

## think4urs11

 *manuels wrote:*   

> Ja, aber wieso machen es die Browser nicht.

 

Indirekte 'Lehrmethode' an merkbefreite Webserveradmins die meinen es wäre cool 2560*1600px große Bilder im Briefmarkenformat darzustellen (bzw. 160*100 in bildschirmfüllend)?  :Wink: 

Leicht überspitzt sieht es doch so aus:

Wozu sollte ein Browser einen Skalierungsmechanismus ala Lanczos3 implementieren? Es ist viel effektiver die Webseite von Anfang an vernünftig zu designen. Die Skalierung im Browser ist lediglich ein nettes Zuckerl um Versäumnisse des Designers zu kaschieren.

Analoges Beispiel wären PDF's die für highend Druckmaschinen gedacht sind (aka >=1200dpi) anstatt für den Onlinebetrieb welche mit 100dpi anzubieten.

----------

## schachti

 *Think4UrS11 wrote:*   

> Wozu sollte ein Browser einen Skalierungsmechanismus ala Lanczos3 implementieren? Es ist viel effektiver die Webseite von Anfang an vernünftig zu designen. Die Skalierung im Browser ist lediglich ein nettes Zuckerl um Versäumnisse des Designers zu kaschieren.

 

Da aber alle Auflösungen zwischen 800x600 und 1600x1200 in der Praxis durchaus vorkommen (und es sogar User gibt, die 640x480, 1920×1200 oder noch extremere Auflösungen fahren), ist es gar nicht so einfach, das optimal zu machen...

----------

## misterjack

 *franzf wrote:*   

>  *misterjack wrote:*   In Eye Of Gnome ein wenig das Mausrad bewegen (= resizen), bringt meine CPU (3800+) auf >40%. 
> 
> Der Vergleich hinkt 
> 
> 1) Wird auf einer Homepage ein Bild genau ein mal (1x) skaliert. Beim Scrollen in EOG gibts ja zig resizeEvent()s.
> ...

 

Ich habe bewusst übetrieben. Es stimmt, es wird einmal skaliert, aber gerade für dieses Antwortfenster werden 31 Grafiken geladen. Und ein Browser muss auch zeichnen  :Smile:  Schaltet man bei EOG Kantenglättung aus, hat man ähnliche Ergebnisse wie im Firefox.

Übrigens würde mich es auf meinen 400 MHz Win98-Rechner nerven, wenn der aktuelle Firefox bei jedem Resizing wegen Kantenglättung die Möhre erstmal für eine Gedenkminute lahmlegt  :Smile: 

Natürlich ist es bestimmt ärgerlich, dass man Kantenglättung nicht einschalten kann.

----------

## franzf

So, dass das jeder mal ausprobieren (und sehen) kann, hier ein kleines Script (PyQt4), zu speichern als (z.B.) transform_test.py:

```
from PyQt4 import Qt

import sys

if len(sys.argv) < 2:

   print "Benutzung:"

   print "python " + sys.argv[0] + " <filename> [scaleFactor]"

   sys.exit(1)

if not Qt.QFile.exists(sys.argv[1]):

   print "Die Datei existiert nicht!"

   sys.exit(1)

app = Qt.QApplication(sys.argv)

px = Qt.QPixmap(sys.argv[1])

if px.isNull():

   print "Konnte die Datei nicht als Pixmap laden. Ist " + sys.argv[1] + " wirklich ein Bild?"

   sys.exit(1)

scale = 0.5

if len(sys.argv) == 3:

   scale = float(sys.argv[2])

start = Qt.QTime.currentTime()

px1 = px.scaled( px.size() * scale, Qt.Qt.KeepAspectRatio )

stop = Qt.QTime.currentTime()

msecFast = start.msecsTo(stop)

print "FastTransform dauerte " + str(msecFast) + " msec"

start = Qt.QTime.currentTime()

px2 = px.scaled( px.size() * scale, Qt.Qt.KeepAspectRatio, Qt.Qt.SmoothTransformation )

stop = Qt.QTime.currentTime()

msecSmooth = start.msecsTo(stop)

print "SmoothTransform dauerte " + str(msecSmooth) + " msec"

rat = float(msecSmooth) / float(msecFast)

print "Smooth dauert " + str(rat) + " mal so lange wie Fast"

print "Skaliert wurde von " + str(px.width())+"x"+str(px.height()) + " auf " + str(px1.width())+"x"+str(px1.height())

view = Qt.QGraphicsView()

scene = Qt.QGraphicsScene()

view.setScene(scene)

item1 = Qt.QGraphicsPixmapItem(px1)

scene.addItem(item1)

item2 = Qt.QGraphicsPixmapItem(px2)

scene.addItem(item2)

item2.setPos(item1.boundingRect().bottomLeft())

view.show()

sys.exit(app.exec_())
```

Das sagt mir dann z.B.:

```
$ python pixmap_transformation.py test.jpg 0.05

FastTransform dauerte 124 msec

SmoothTransform dauerte 214 msec

Smooth dauert 1.72580645161 mal so lange wie Fast

Skaliert wurde von 2560x1920 auf 128x96
```

Also, ein Bild von 2560x1920 auf 128x96 mit SmoothTransform zu skalieren dauert 1.73 mal so lange wie mit FastTransform...

Ist jetzt natürlich kein Benchmark, aber zeigt ungefähr die Richtung an (so wie glxgears).

Beide Bilder sieht man dann auch noch in einem GraphicsView  :Smile: 

Grüße

Franz

EDIT:

 *misterjack wrote:*   

> Ich habe bewusst übetrieben. Es stimmt, es wird einmal skaliert, aber gerade für dieses Antwortfenster werden 31 Grafiken geladen. Und ein Browser muss auch zeichnen  Schaltet man bei EOG Kantenglättung aus, hat man ähnliche Ergebnisse wie im Firefox.
> 
> Übrigens würde mich es auf meinen 400 MHz Win98-Rechner nerven, wenn der aktuelle Firefox bei jedem Resizing wegen Kantenglättung die Möhre erstmal für eine Gedenkminute lahmlegt 
> 
> Natürlich ist es bestimmt ärgerlich, dass man Kantenglättung nicht einschalten kann.

 

31 Grafiken, die alle nicht skaliert werden müssen. Und seit wann skaliert der Browser die Webseite, wenn man die Fenstergröße ändert? Neues Feature vom Firefox3?  :Smile: 

Grundsätzlich würde mich aber mal ein Link interessieren, wo man sowas auch sehen kann! Denn langsam glaub ich dass Konqueror die Pixmaps weich skaliert, weil ich nie Probleme hab...Last edited by franzf on Wed Mar 26, 2008 2:48 pm; edited 1 time in total

----------

## schachti

 *franzf wrote:*   

> Also, ein Bild von 2560x1920 auf 128x96 mit SmoothTransform zu skalieren dauert 1.73 mal so lange wie mit FastTransform...
> 
> Ist jetzt natürlich kein Benchmark, aber zeigt ungefähr die Richtung an (so wie glxgears).

 

Ich denke, das hängt wesentlich vom Prozessor ab (ob MMX/SSE etc. vorhanden ist oder nicht). Ich könnte mir vorstellen, dass ohne MMX/SSE der Faktor deutlich ungünstiger sein könnte.

----------

## think4urs11

 *schachti wrote:*   

> Da aber alle Auflösungen zwischen 800x600 und 1600x1200 in der Praxis durchaus vorkommen (und es sogar User gibt, die 640x480, 1920×1200 oder noch extremere Auflösungen fahren), ist es gar nicht so einfach, das optimal zu machen...

 

Ich nutze auch Auflösungen von VGA bis WUXGA je nach Gerät an dem ich sitze (meistens WSXGA+).

Wahlweise das kleinste gemeinsame Übel nehmen, das dürfte derzeit bei 800x600 liegen (mit extrem wenigen Ausreißern nach unten) oder aber abhängig von der Fenstergröße des Browsers bzw. der Bildschirmauflösung des Clients unterschiedliche große _vorgerenderte_ Thumbnails ausliefern. (klein=bis 800x600;mittel=bis 1680x1024;groß=alles darüber o.ä.)

Selbst die großen Sites wie youtube/youporn/etc. liefern immer relativ kleine Thumbs aus. Ist ja auch logisch denn a) geht es schneller und b) spart Traffickosten.

Die Vorlieben sind nunmal unterschiedlich; mir persönlich ist es lieber eine Seite wird schnell aufgebaut als in highend Druckqualität. Seiten die mich direkt mit highres 'zuballern' möchten mich nicht als Leser.

Klar könnte man sagen 'sollens die Browserentwickler halt als optional zuschaltbar integrieren' - nur riecht das dann bereits streng nach Bloatware.

----------

## artbody

Ich denke 

Es gibt 2 Arten von User 

Highspeed und fette Maschine

Modem und alten 486er   :Laughing: 

(lacht nicht unser Untermieter hat einen 486er mit Win95 am laufen und beschwert sich immer daß das so lange dauert)

Hier den Konsens zu finden dürfte schwer sein

Und in erster Linie ist es Sache des Webdesigners eine Seite optimal zu gestalten

Jetzt ist natürlich die Frage was ist aus dessen Sicht optimal

Optimal könnte geringer Traffic wie hier im Forum

oder eben Höchstauflösend für z.B. Kunstseiten sein.

Damit geht der Webdesigners erst mal auf die Anforderung des Kunden ein.

Daß hier natürlich versucht werden sollte browserconform bestmöglichste Ergebnisse zu erzielen ist ebenfalls einleuchtend.

Aber jetzt sind wir bereits an dem Punkt, wo sich die M$IE, Gecko, Opera, etc Falle auftut 

Der eine Browser kann das, der andere was anderes....

 :Laughing: 

Und ganz zu schweigen von wirklich sinnvollen Sachen wie SVG oder ähnliches, wo die Unterschiede von Browser zu Browser noch gravierender sind

Mangelde Plugins für Linux (div-x....)

Es ist eigentlich immer noch wie in der Bronzezeit.(Steinzeit haben wir hinter uns - fast)  :Embarassed: 

Aber wie aus den ganzen Anforderungen zu entnehmen ist, mutiert ein Webbrowser zu einer "eierlegenden Wollmilchsau"

Nun gibt es aber auch noch den Grundsatz, mit geringstmöglichem Aufwand das Gewünschte zu erreichen.

Würden sich 90% der Webdesigner daran halten, dann gäbe es sicher keine reine Flashseiten, wo man wenn man kein flash installiert hat/kann (Firmenrechner) nichts sieht.

Schaut man dann von zu Hause auf die Seite findet man ein reines Flashmenü als untereinander angeordnete Menüpunkte

ala

```

<table><tr><td><td/><tr/><tr><td><td/><tr/>....<table/>

```

Alles nichts, was den Einsatz von Flash rechtfertigen würde....

Sowas find ich krass.

----------

## misterjack

 *artbody wrote:*   

> 
> 
> ```
> 
> <table><tr><td><td/><tr/><tr><td><td/><tr/>....<table/>
> ...

 

Das ist aber erst recht Bronzezeit  :Smile: 

----------

## musv

 *manuels wrote:*   

> Naja, ich komme darauf, da ich unsere Vereinshomepage hoste und viele Noops Artikel schreiben und die Bilder von ihrer Digitalkamara direkt in den Artikel stellen und verkleinern  
> 
> Das sieht dann nicht nur bloede aus, sondern belastet auch die Bandbreite unnoetig (aber hier will ich mir gerade Abhilfe verschaffen).

 

Ich bin grad dabei einen Webshop zu programmieren. Und da werden die Produktbilder auf dem Server skaliert. Ich mach das über ein PHP-Script. Du hast dann 2 Möglichkeiten:

Wenn der Server genug Power hat, kannst du die Bilder in Originalgröße auf dem Server lassen, on-the-fly skalieren und das skalierte Bild übertragen.

Die Bilder gleich beim Hochladen skalieren und im kleineren Format abspeichern.Hat den Vorteil, daß du die Bilder immer genau auf die Größe bringst, die du willst. Außerdem sparst du in jedem Fall Bandbreite und hast das o.g. Browser-Resize-Problem nicht. Wenn du's brauchst, poste ich mal das Script.

----------

## TheSmallOne

 *Think4UrS11 wrote:*   

> Analoges Beispiel wären PDF's die für highend Druckmaschinen gedacht sind (aka >=1200dpi) anstatt für den Onlinebetrieb welche mit 100dpi anzubieten.

 

Sollte ein ordentliches PDF nicht sowieso komplett in Vektorgrafik vorliegen und somit sowieso nichts mit dpi zu tun haben?

----------

## manuels

 *musv wrote:*   

> Hat den Vorteil, daß du die Bilder immer genau auf die Größe bringst, die du willst. Außerdem sparst du in jedem Fall Bandbreite und hast das o.g. Browser-Resize-Problem nicht. Wenn du's brauchst, poste ich mal das Script.

 Bastel gerade an was ähnlichem für Joomla.

Hätte schon interesse. Was für ein Library nutzt du denn?

----------

## mastacloak

 *musv wrote:*   

> 
> 
> Wenn der Server genug Power hat, kannst du die Bilder in Originalgröße auf dem Server lassen, on-the-fly skalieren und das skalierte Bild übertragen.
> 
> 

 

Und wenn die skalierten Bilder noch auf dem Server gecached werden, dann muss für jede Auflösung nur einmal skaliert werden und die CPU-Last hält sich in Grenzen.

 *TheSmallOne wrote:*   

> 
> 
> Sollte ein ordentliches PDF nicht sowieso komplett in Vektorgrafik vorliegen und somit sowieso nichts mit dpi zu tun haben?

 

Manchmal braucht man auch noch Bitmaps (insbesondere Fotos) in PDFs, z.B. für Flyer etc. Die lassen sich meist nicht als Vektorgrafik darstellen.

----------

## musv

Library ist die gd. Natürlich muß php das dann auch unterstützen.

Das Script gibt Bilder on-the-fly-resized in der gewünschten Größe aus. Optionale Eingabeparameter ist die maximale Bildgröße - egal ob Breite oder Höhe. Der Aspect Ratio wird beibehalten.

```

<?php

/**   Die Datei wandelt ein Bild in eine bestimmte Gr&ouml;&szlig;e um. <br>

*   Get-Parameter:   <br>

*      pic:   -   Pfad + Bild, was umgewandelt werden soll<br>

*      maxsize   -   [optional]   Maximale Gr&ouml;&szlig;e des Bildes in Pixel<br><br>

*   R&uuml;ckgabewert:<br>

*      Bild im jpg-Format.

*/

/* Header auf Bild umschalten */

header("Content-type: image/jpeg");

/* Get-Variablen einlesen */

$maxsize   =   ($_GET["maxsize"])?intval($_GET["maxsize"]):100;

$pic      =   "../../../".$_GET["pic"];   // Pic-Verzeichnis

/* Die dummdämlichen Leerzeichen wieder in die Dateinamen reinmachen.

*   Man sollte sowas verbieten. 

*   HTML-Entities hab ich mal rausgelassen, Das kann sonst 'n schönes

*   Theater noch mit Umlauten werden. Ich will's gar nicht ausprobieren.

*/

$pic      =   str_replace("_____"," ",$pic);

/* Image-Handler erstellen */

$image_info = getImageSize($pic) ; // see EXIF for faster way

    

/* Mime-Type unterscheiden */

switch ($image_info['mime']) {

   case 'image/gif':

       if (imagetypes() & IMG_GIF)  { // not the same as IMAGETYPE

           $image_src = imageCreateFromGIF($pic) ;

        } else {

           $ermsg = 'GIF images are not supported<br />';   

        }

        break;

   case 'image/jpeg':

       if (imagetypes() & IMG_JPG)  {

           $image_src = imageCreateFromJPEG($pic) ;

      } else {

           $ermsg = 'JPEG images are not supported<br />';

      }

        break;

   case 'image/png':

       if (imagetypes() & IMG_PNG)  {

           $image_src = imageCreateFromPNG($pic) ;

      } else {

          $ermsg = 'PNG images are not supported<br />';

      }

        break;

   case 'image/wbmp':

       if (imagetypes() & IMG_WBMP)  {

           $image_src = imageCreateFromWBMP($pic) ;

      } else {

           $ermsg = 'WBMP images are not supported<br />';

      }

        break;

   default:

       $ermsg = $image_info['mime'].' images are not supported<br />';

        break;

}

    

    

/* Resize-Abschnitt

*   Wir ermitteln erst, welcher Wert von beiden der größere ist.

*   Der wird dann als Maxsize angenommen, der andere wird dementsprechend angepaßt.

*

*   Danach wird ein neues Image mit der ermittelten Größe erstellt (image_dst)

*   Das Quellimage wird auf das neue kopiert mit Größenänderung

*   Zum Schluß werden die beiden Images zerstört.

*/    

if (!isset($ermsg)) {

   $width_src    = imagesx($image_src);

    $heigth_src = imagesy($image_src);

        

        

    /*   An dieser Stelle wird erstmal überprüft, ob wir überhaupt

    *   skalieren müssen. Wenn die maxsize der größeren der beiden

    *   Bildmaße entspricht, dann sparen wir und den Resize.

    */       

   $bigside   =   max($width_src, $heigth_src);

   if ($bigside == $maxsize)   {

       imageJPEG($image_src);

    }   else   {

        

      if ($width_src > $heigth_src)   {

      

         $width_dst   =   $maxsize;

         $heigth_dst =   round($heigth_src * $maxsize / $width_src);

      

      }   else   {

      

         $heigth_dst   =   $maxsize;

         $width_dst   =   round($width_src * $maxsize / $heigth_src);

      }

         

   

      $image_dst = imageCreateTrueColor($width_dst,$heigth_dst);

      imageCopyResampled($image_dst, $image_src, 0, 0, 0, 0, $width_dst, $heigth_dst, $width_src, $heigth_src);         

      imageJPEG($image_dst);         

      imageDestroy($image_dst);

    }

   imageDestroy($image_src);

}

?>

```

Die Zeile

```

<img src="img_builder_script.php?pic=bild.jpg&amp;maxsize=500" />

```

würde dann z.B. das Bild bild.jpg mit maximaler Breite oder Höhe von 500 px ausgeben. Wie man dem Quelltext entnehmen kann, hatte ich Probleme mit Leerzeichen im Dateinamen der Bilder wegen der Get-Parameter. Ich hab das dann so gelöst, indem ich alle Leerzeichen der Bildernamen durch "_____" ersetzt hab. Das Script ist nicht zu 100% von mir. Hab einige Teile davon in irgendeinem Forum gefunden und teilweise übernommen, teilweise abgeändert.

----------

## manuels

hmm, hab ein ähnliches Script mit der GD-Library geschrieben.

Die Bilder die rauskommen sind aber ziemlich häßlich:

http://img179.imageshack.us/img179/7527/httpfarm1staticflickrcovk3.jpg

Das resizen klappt genau so wie bei dir.

Habs schon mit der Funktion imageantialias() versucht, aber die gibt es nicht.

Wie sehen denn deine Bilder aus?

----------

## nanos

Du solltest deine php oder gdlib version überprüfen, bei den früheren versionen waren die Bilder alle so.

Und immer imagecopyresampled() an Stelle von imagecopyresized() verwenden.

Gruß

Roland

----------

## manuels

 *nanos wrote:*   

> Und immer imagecopyresampled() an Stelle von imagecopyresized() verwenden.

 

Bingo, Danke!

Das ganze ist ein "Mambot" geworden und hab ich mal veröffentlicht.

----------

## xraver

 *franzf wrote:*   

> 
> 
> Und seit wann skaliert der Browser die Webseite, wenn man die Fenstergröße ändert? Neues Feature vom Firefox3? 
> 
> Grundsätzlich würde mich aber mal ein Link interessieren, wo man sowas auch sehen kann! Denn langsam glaub ich dass Konqueror die Pixmaps weich skaliert, weil ich nie Probleme hab...

 

Also der IE7 machts.

Orginal: http://img208.imageshack.us/img208/5643/iema7.jpg

400% Zoom: http://img401.imageshack.us/img401/3849/iezoomyh7.jpg

Aber das ist ja nun was anderes als "skalieren der Website je nach Browsergrösse".

----------

## Knieper

```

$maxsize   =   ($_GET["maxsize"])?intval($_GET["maxsize"]):100;

```

-10 geht auch

```

$pic      =   "../../../".$_GET["pic"];   // Pic-Verzeichnis

```

Anfaengerfehler. Fehlendes basename() ermoeglich das Durchwandern anderer Pfade (pic=../../../etc/...).

 *Quote:*   

> Das kann sonst 'n schönes*	Theater noch mit Umlauten werden. Ich will's gar nicht ausprobieren.

 

Falsche Einstellung.

```
$image_info = getImageSize($pic) ; // see EXIF for faster way
```

War das nicht obsolet und wurde durch getimagesize() ersetzt?

```

...

Haufen nicht ueberpruefte Rueckgabewerte

...

```

Nicht sehr defensiv geschrieben. Ich hoffe das liegt so nicht auf Servern.

----------

## manuels

 *artbody wrote:*   

> 
> 
> Es ist eigentlich immer noch wie in der Bronzezeit.(Steinzeit haben wir hinter uns - fast) 
> 
> 

 

Aus aktullem Anlass: http://www.heise.de/newsticker/Erste-Browser-schaffen-Acid3-Test--/meldung/105589

Ich bin der Meinung optionales antialiasing fuer Bilder waere keine Bloatware. Ich denke mal, dass die Browser sowieso auf Bibliotheken aufsetzen, die die Bilder rendern (?).

Ein weiterer Bibliotheksaufruf waere kein riesen Aufwand.

Aber wo wir gerade dabei sind: Noch so eine Sache, die ich nicht verstehe.

Wieso wird beim Versenden von Dateien keine Progressbar in der Statusleiste angezeigt? Der Browser weiss doch wie gross die zu verschickenden Daten sind.

----------

## nanos

 *artbody wrote:*   

> 
> 
> Aber wo wir gerade dabei sind: Noch so eine Sache, die ich nicht verstehe.
> 
> Wieso wird beim Versenden von Dateien keine Progressbar in der Statusleiste angezeigt? Der Browser weiss doch wie gross die zu verschickenden Daten sind.

 

Du meinst beim Upload von Dateien?

Das wäre natürlich eines der begehrtesten Features da ein Progressbar mittels php nur über Umwege realisierbar ist.

Bei Joomla 1.5 kann man mehrere Dateien über Flash raufladen, aber da ich prinzipiell gegen Flash bin, wäre mir eine Browserlösung wesentlich lieber.

----------

## schachti

 *manuels wrote:*   

> Wieso wird beim Versenden von Dateien keine Progressbar in der Statusleiste angezeigt? Der Browser weiss doch wie gross die zu verschickenden Daten sind.

 

Ich vermute, weil 99,9% des Traffics vom Server zum Client gehen und die allermeisten Benutzer nur herunterladen, nicht hochladen.

----------

## manuels

 *schachti wrote:*   

> Ich vermute, weil 99,9% des Traffics vom Server zum Client gehen und die allermeisten Benutzer nur herunterladen, nicht hochladen.

 

Das schon, aber wenn mal viel Traffic in die andere Seite geht ist sowas schon _sehr_ wünschenswert.

----------

## musv

 *Knieper wrote:*   

> Nicht sehr defensiv geschrieben. Ich hoffe das liegt so nicht auf Servern.

 

Doch liegt es   :Twisted Evil: 

Gründe dafür:

Ich war an dem Tag ziemlich gefrustet und hatte da keinen Bock noch großartig zu testen.

Ganz egal, was du an der Stelle für Pic als Parameter übergibst, es hat keine Auswirkungen, denn aus dem ganzen Script kommt ein Image raus. D.h. steckst du was anderes rein, kriegst du nur 'ne Fehlermeldung. Falls du ein Sicherheitsrisiko darin siehst, gib mir ein Beispiel, mit dem man das Script an der Stelle ausnutzen könnte. Falls es funktioniert, änder ich es.

Es funktioniert

Um überhaupt von diesem Script Notiz zu nehmen, mußt du schon in den Quelltext des Shops reingesehen. Über die URL siehst du die Parameter nicht. 

Im Grunde genommen hast du aber recht.

----------

## Knieper

 *musv wrote:*   

> Ganz egal, was du an der Stelle für Pic als Parameter übergibst, es hat keine Auswirkungen, denn aus dem ganzen Script kommt ein Image raus. D.h. steckst du was anderes rein, kriegst du nur 'ne Fehlermeldung.

 

Dh. firmeninterne Bilder, die Nacktbilder der Freundin etc. sind kein Problem? Ausserdem duerfte die Fehlermeldung mMn. nicht durchkommen (hab's nicht ausprobiert), da der Header schon ganz oben geschrieben wird. Es funktioniert auch nur unter der Annahme, dass der MIME-Typ korrekt erkannt wird - solche Annahmen sollte man nicht machen.

Anderes Bsp.: jmd. kann ueber ein genauso wenig defensives Skript in eine beliebige Datei schreiben. Durch "Zufall" schreibt er einen jpeg-Header und ploetzlich hat er mit Deinem Script eine wunderbare Ausgaberoutine fuer beliebige Dateien.

 *Quote:*   

> Um überhaupt von diesem Script Notiz zu nehmen, mußt du schon in den Quelltext des Shops reingesehen.

 

Eigentlich sollte der html-Text ausreichen, wenn ich das Bsp. richtig gelesen habe und das mache ich zu gern.   :Very Happy: 

----------

