2.11 RC2 Image upload resize delivers incorrect result

[ManuelB69]

Image upload resizes a picture larger as given in the settings to the given size but orginal image is sized down even more. Unused space is filled with black. Example Maximal width/height 912/720, original picture size 1536x2048, used image space in resized file 320x428 located in the upper left corner. Update: Images in landscape format are resized correctly!

[leofeyer]

What are the exact settings to reproduce this issue?

[ManuelB69]

Hi Leo, ich nutze Xampp 1.7.3 unter Windows und habe die 2.11 RC2 ber eine 2.10.3 geupdated. Das Fehlverhalten tritt bei mir bei jedem Bild im Hochformat auf. Wenn du willst teste ich auch gerne noch einmal auf frischen 2.11 RC2 Installation. LG Wilfried

[ManuelB69]

I have just tried it with fresh installation of 2.11 RC2 with a completly fresh database at its state after completing install.php and the problem is still intact.

[leofeyer]

I just tried it with your settings but everything worked fine on my system (latest 2.11.x branch).

[ManuelB69]

Very strange. Meanwhile I tried to reproduce this issue on my standard 1&1 shared hosting. And the problem with the error-prone portrait format picture resizing occurs again. I can provide you a login for this 1&1 installation if you like.

[leofeyer]

Do you have access to the server configuration? Can anyone else confirm the issue?

[xchs]

I can confirm this issue in my local installation with the current 2.11 branch. That said, I have used exactly the same original image size (1536x2048) as well as the maximum upload image settings specified above in the ticket.

PHP Version 5.3.8

[leofeyer]

@xchs can you please upload the resources you have used in your test?

[xchs]

As requested: http://www.freefilehosting.net/testpic

[leofeyer]

Please try it with 0e6dd0e1c9e1544131f54b02c90e9fe42fd49e1e.

[xchs]

It seems to work now. Well done. (BTW: There is no milestone assigned to this ticket.)

However, during this test I came across with another issue...

[ManuelB69]

Please excuse my longer term absence. I had a forced break :( After your fix the image resizing is now working correctly for landscape and portrait format picture uploads.

[ghost]

Leider ist dieser Fehler bei mir noch präsent. Und zwar immer dann, wenn in beide Richtungen skaliert wird. Bsp: Originalgröße 1920x1200, Limits bei 800x600.

In der Funktion resizeUploadedImage wird ja dann zuerst die Höhe skaliert und dann die Breite. Wenn ich den zweiten Schritt auskommentiere, erfolgt der erste Schritt so wie es sein soll (960x600). Beim zweiten Schritt macht es aber den Anschein, als wird nicht das bereits richtig erstellte Bild als Basis genommen, sondern ein anderes. Die finale Größe ist zwar richtig (800x500), aber das Bild nimmt nur das obere linke Viertel ein und der Rest ist schwarz.

Getestet mit einer 2.11.1 auf einem Dev- und einem Live-System.

Dev: PHP 5.3.9-ZS5.6.0, GD bundled (2.0.34 compatible), libJPEG 6b Live: PHP 5.3.8, GD bundled (2.0.34 compatible), libJPEG 8

[plakart]

Kann den Fehler bestätigen. Getestet in Contao 2.11 und bei 2.11.1 auf verschiedenen Server (Strato, domainfactory, 1&1). z.B. mit PHP Version 5.2.13, GD Version bundled (2.0.34 compatible)

Contao-Systemeinstellungen: http://www.plakart.de/ct-upload-fehler/systemeinstellungen-2-11-1.png

Beispiel-Foto, das fehlerhaften Upload auslöst: http://www.plakart.de/ct-upload-fehler/fehler-bild.jpg

Ergebnis des fehlerhaften Uploads: http://www.plakart.de/ct-upload-fehler/fehler-ergebnis.jpg

In den SystemLogs ist der Upload ganz normal protokolliert: "File "fehler-bild.jpg" uploaded successfully and was scaled down to the maximum dimensions"

[leofeyer]

@plakart Ging es auf diesen Servern mit der 2.10 ohne Fehler?

[plakart]

Ja. Auf den selben Servern sind auch noch 2.10-Versionen installiert. Die laufen problemlos.

[proxymus]

@leofeyer Ich habe gestern auch das Update von 2.10 auf 2.11.1 durchgeführt und seitdem das Problem, dass Bilder beim Upload einen schwarzen Rand haben. Vorher hatte ich das Problem nicht.

[takkk]

@leofeyer habe dasselbe problem.

• contao 2.11.2
• php 5.3.4
• gd version 2.0.34

[Luminanz]

Gleiches Problem mit folgender Konfiguration:

• contao 2.11.2
• PHP 5.2.17
• GD Version bundled (2.0.34 compatible)

[takkk]

scheint wohl definitiv ein 2.11-bug zu sein. @leofeyer wäre super, wenn man den beheben könnte...

[takkk]

habe einen temporären bugfix für version 2.11.2. file system/modules/backend/FileUpload.php zeile 288 bis 303 ersetzen durch:

    // The image exceeds the maximum image width
    if ($arrImageSize[0] > $GLOBALS['TL_CONFIG']['imageWidth'] && $arrImageSize[0] > $arrImageSize[1])
    {
        $blnResized = true;
        $this->resizeImage($strImage, $GLOBALS['TL_CONFIG']['imageWidth'], 0);
    }

    // The image exceeds the maximum image height
    elseif ($arrImageSize[1] > $GLOBALS['TL_CONFIG']['imageHeight'])
    {
        $blnResized = true;
        $this->resizeImage($strImage, 0, $GLOBALS['TL_CONFIG']['imageHeight']);
    }

[Luminanz]

@takkk besten Dank für den vorübergehenden patch, funktioniert einwandfrei!

[ghost]

Sollte man vielleicht noch kurz erwähnen, dass der Patch nur funktioniert, wenn auf Breite ODER Höhe skaliert wird.

[takkk]

@KBeng hat man denn beim fileupload noch andere möglichkeiten?

[ghost]

Es kann ja sein (s. mein Beispiel oben), dass das Bild nach dem Upload nach den globalen Limits auf beide Maximalwerte skaliert werden muss. In der Funktion läuft das nacheinander ab. Und nur wenn das gemacht wird, tritt der Fehler überhaupt erst auf.

[leofeyer]

Hopefully fixed in 5e92113e0f0158beb7f7769d84d6cd3f081a8afe.

[ghost]

Problem behoben. Vielen Dank!

[AndreasA]

Eine Frage: Wäre es nicht sinnvoller "floor" anstatt "ceil" beim Berechnen der zweiten Bildlängen zu verwenden? Es kann nämlich (zumindest ist es mir einmal passiert) - wenn auch selten und vermutlich auf Rundungspräzision zurückzuführen passiert, dass bei ceil das resultierende Bild um 1 Pixel zu hoch war.

Oder eventuell noch besser, am Ende nochmal kontrollieren, ob ein Wert höher ist als der maximal erlaubte und dann auf diesen zurecht zu stutzen quasi (wenn der Unterschied nur 1 Pixel beträgt oder so)

[leofeyer]

Dafür bräuchte ich zunächst bitte ein Bild, das den Fehler verursacht.

[AndreasA]

Kann man irgendwie ein Bild anhängen? Allerdings kann ich ein Beispiel nennen, wo es fix auftritt. - Ich finde selbst nicht mehr das Bild wo ich das Problem zum ersten Mal hatte und zwar: Einstellung für maximalie Bildgröße (Größe zum Bildverkleinern): 600x750 (also 600 Weite und 750 Höhe) Danach ein Bild hochladen mit 601x751 und das Endresultat ist 601x750

Das ist jetzt zwar extrem selten der Fall, dass man gerade so ein Bild hat, aber auch hier sollte das Ergebnis trotzdem passen... Vor allem kann es eben auch unter anderen Umständen auftreten, hier handelt es sich noch nicht einmal um einen Präzisionsfehler (allerdings kann es sicher auch wegen Präzisionsfehler auftreten).

[AndreasA]

Ergänzend möchte ich anmerken, dass das Problem vermutlich nur bei der Weite auftritt und nicht bei der Höhe (hatte ich oben falsch erwähnt) und zwar, weil nach der neu Berechnung eben nochmal überprüft wird, ob die Höhe passt und gegebenenfalls eben korrigiert wird auf die maximale Höhe und dann die Weite neu berechnet wird. Allerdings wird danach die Weite halt nicht mehr kontrolliert.

[leofeyer]

In der Tat scheint es mit round() sehr viel akkurater zu sein. Geändert in 460244f1bb62097854eeec47a3d720d94bf4b04b.

[AndreasA]

Wegen PHP Genauigkeit sollte man eventuell auch noch bcmul und bcdiv zum Ausrechnen verwenden - wobei mit der Verwendung von round dürfte das quasi eh hinfällig sein.

[proxymus]

Kommen diese Änderungen in einer neuen Version zum Einsatz oder muss ich die Dateien selbst anpassen?

[AndreasA]

Sollten in 2.11.3 dann enthalten sein. P.S. valumsFileUploader hat die Änderungen (wenn auch noch mit "ceil" anstatt "round") bereits umgesetztt.