Defekte Bilder bei Client-seitiger Skalierung

  • Mindestens genauso nervig wie Zitate und Ansprechungen (wurde mir ja angeprangert) sind diese persönliche Meinungen und Besserwissereien in den Threads, das bringt genauso wenig wie "Ich habe das Problem auch" wenn nicht sogar weniger.

    Würden das hier einige Leute (soll sich keiner persönlich angesprochen fühlen, meine das generell, gibt ja viele davon) lassen, würde sich der Umgangston hier auch verbessern und jedem Zugute kommen und diese Diskussionen die nichts bringen wären in vielen Threads auch passé...

    Nichts für Ungut ist nur meine Meinung, normal gebe ich meinen Senf nicht dazu aber muss auch mal gesagt sein :P

    Schönen Tag noch.

    ┌П┐(◉_◉)┌П┐

    2 Mal editiert, zuletzt von TeRRible__KHONS (28. April 2020 um 08:45)

  • Hallo,

    wenn man weiß, dass viele andere auch das Problem haben, dann ist zumindest die Hoffnung da, dass an einer Lösung gearbeitet wird und man das aussitzen kann.

    Ich habe in meinem Forum nämlich noch einen Fall, der wohl noch bei keinem anderen zu finden ist und da ist mit einer Lösung halt nicht zu rechnen. (Diese Userin läd ein Bild hoch, in denen dann Mosaikstückhaft Teile desselben Bildes erscheinen.)

    Viele Grüße
    Petra

  • Hallo,

    Liegt wahrscheinlich auch am selben Problem dass die Bilder fehlerhaft erzeugt.

    Wirste dann sehen wenn das Update da ist und dann kannste immer noch berichten falls es immer noch nicht richtig funktioniert :)

    ┌П┐(◉_◉)┌П┐

    • Offizieller Beitrag

    Erneut getestet, selbes Ergebnis:

    Aufgerufene URL
    /forum/index.php?ajax-upload/&t=e0d1e66ca0047aabab57a0e7498f982b195af1d7
    Referrer
    WoltLab Suite
    5.2.5
    PHP
    7.3.14-1~deb10u1
    Fehlermeldung
    Call to a member function setImageOrientation() on resource
    Art
    Error
    Datei (Zeile)
    /var/www/domain.tld/httpdocs/lib/system/upload/DefaultUploadFileSaveStrategy.class.php (202)
    Stacktrace
    1. /var/www/domain.tld/httpdocs/lib/system/upload/UploadHandler.class.php (107): wcf\system\upload\DefaultUploadFileSaveStrategy->save(…)
    2. /var/www/domain.tld/httpdocs/lib/data/attachment/AttachmentAction.class.php (148): wcf\system\upload\UploadHandler->saveFiles(…)
    3. /var/www/domain.tld/httpdocs/lib/data/attachment/TinyImgAttachmentAction.class.php (141): wcf\data\attachment\AttachmentAction->upload(…)
    4. [internal function] (?): wcf\data\attachment\TinyImgAttachmentAction->upload(…)
    5. /var/www/domain.tld/httpdocs/lib/data/AbstractDatabaseObjectAction.class.php (205): call_user_func(…)
    6. /var/www/domain.tld/httpdocs/lib/action/AJAXProxyAction.class.php (75): wcf\data\AbstractDatabaseObjectAction->executeAction(…)
    7. /var/www/domain.tld/httpdocs/lib/action/AJAXInvokeAction.class.php (94): wcf\action\AJAXProxyAction->invoke(…)
    8. /var/www/domain.tld/httpdocs/lib/action/AbstractAction.class.php (47): wcf\action\AJAXInvokeAction->execute(…)
    9. /var/www/domain.tld/httpdocs/lib/action/AJAXInvokeAction.class.php (61): wcf\action\AbstractAction->__run(…)
    10. /var/www/domain.tld/httpdocs/lib/system/request/Request.class.php (83): wcf\action\AJAXInvokeAction->__run(…)
    11. /var/www/domain.tld/httpdocs/lib/system/request/RequestHandler.class.php (107): wcf\system\request\Request->execute(…)
    12. /var/www/domain.tld/httpdocs/forum/index.php (9): wcf\system\request\RequestHandler->handle(…)

    Nun könnte man natürlich meinen, der Fehler läge in unserer TinyImg-Erweiterung. Das hab ich natürlich auch getestet:

    Aufgerufene URL
    /forum/index.php?ajax-upload/&t=e0d1e66ca0047aabab57a0e7498f982b195af1d7
    Referrer
    WoltLab Suite
    5.2.5
    PHP
    7.3.14-1~deb10u1
    Fehlermeldung
    Call to a member function setImageOrientation() on resource
    Art
    Error
    Datei (Zeile)
    /var/www/domain.tld/httpdocs/lib/system/upload/DefaultUploadFileSaveStrategy.class.php (202)
    Stacktrace
    1. /var/www/domain.tld/httpdocs/lib/system/upload/UploadHandler.class.php (107): wcf\system\upload\DefaultUploadFileSaveStrategy->save(…)
    2. /var/www/domain.tld/httpdocs/lib/data/attachment/AttachmentAction.class.php (148): wcf\system\upload\UploadHandler->saveFiles(…)
    3. [internal function] (?): wcf\data\attachment\AttachmentAction->upload(…)
    4. /var/www/domain.tld/httpdocs/lib/data/AbstractDatabaseObjectAction.class.php (205): call_user_func(…)
    5. /var/www/domain.tld/httpdocs/lib/action/AJAXProxyAction.class.php (75): wcf\data\AbstractDatabaseObjectAction->executeAction(…)
    6. /var/www/domain.tld/httpdocs/lib/action/AJAXInvokeAction.class.php (94): wcf\action\AJAXProxyAction->invoke(…)
    7. /var/www/domain.tld/httpdocs/lib/action/AbstractAction.class.php (47): wcf\action\AJAXInvokeAction->execute(…)
    8. /var/www/domain.tld/httpdocs/lib/action/AJAXInvokeAction.class.php (61): wcf\action\AbstractAction->__run(…)
    9. /var/www/domain.tld/httpdocs/lib/system/request/Request.class.php (83): wcf\action\AJAXInvokeAction->__run(…)
    10. /var/www/domain.tld/httpdocs/lib/system/request/RequestHandler.class.php (107): wcf\system\request\Request->execute(…)
    11. /var/www/domain.tld/httpdocs/forum/index.php (9): wcf\system\request\RequestHandler->handle(…)

    Wie ich auch schon auf GitHub schrieb, kann ich das Problem nicht reproduzieren. Die rotate()-Methode des ImageMagickAdapter liefert ein \Imagick-Objekt zurück [1] und keinen Resource-Pointer. Getestet mit PHP 7.4.4 x64 NTS, imagick module version 3.4.4.

    [1] https://github.com/WoltLab/WCF/bl…s.php#L376-L384

  • Noch eine kleine Wasserstandsmeldung: Das Problem besteht auch weiterhin in Chrome 84.0.4129.0 (soll schon seit 84.0.4126.0 behoben sein). Ich bleibe also dabei, dass dieser Bug nicht dafür verantwortlich ist, zumal es dort lediglich um die Bildausrichtung geht.

    Darüber hinaus besteht das Problem in unserer TinyImg-Erweiterung beispielsweise nicht.

    • Offizieller Beitrag

    Alexander Ebert ich hatte bereits darauf geantwortet. Das Problem bei meinem Kunden war, dass Imagemagick zwar installiert- und im ACP als Prozessor ausgewählt war, Imagick aber nicht aktiviert. Die derzeitige Prüfung ist unzureichend. Besser wäre an der Stelle:

    PHP
    if ($adapter->getImage() instanceof \Imagick) {

    Danke, den Fallback auf die GD-Bibliothek bei einer fehlerhaften Konfiguration hatte ich nicht berücksichtigt.

  • Ich habs eben auch mit Chrome 84.0.4129.0 versucht und gleiches Problem, die fixes aus github lokal damit getestet.

    Ich stimme SoftcreatR zu und wahrscheinlich liegt das Problem irgendwo anders oder der fix von Chrome ist noch nicht richtig 😜

    ┌П┐(◉_◉)┌П┐

  • Ich muss meine Aussage teilweise korrigieren: Der Workaround von Tim funktioniert grundsätzlich. Und im offiziellen Chrome Build 81.0.4044.12 bleibt auch das 2. Testbild heile, trotz Skalierung. Lediglich im aktuellen Canary-Build ist das 2. Testbild defekt, der Workaround greift dort ebenfalls beim 1. Testbild, weshalb ich weiterhin vermute, dass das Problem ein anderes ist, da der Bug, wie bereits geschrieben, bereits behoben ist (wobei durch den Bugfix ein anderes Problem entstanden ist und nun scheinbar Höhe & Breite vertauscht werden).

    Tim Düsterhus ich habe mir sagen lassen, dass das Problem auch im aktuellen Safari auftritt.

    • Offizieller Beitrag

    Lediglich im aktuellen Canary-Build ist das 2. Testbild defekt,

    Das kann ich mit einem Chromium Version 84.0.4130.0 (Developer Build) (64-bit) (d.h. der ungebrandete Chrome) nicht bestätigen:

    scale.mp4

    wobei durch den Bugfix ein anderes Problem entstanden ist und nun scheinbar Höhe & Breite vertauscht werden

    Kannst du das näher erklären?

    • Offizieller Beitrag

    Hallo,

    mein Patch zielt genau darauf ab, dass die vom Chrome gelieferte Bitmap inkonsistent zu der Breite / Höhe des jeweiligen Bildes ist. Insofern ist mir nicht klar, inwiefern eine „vertauschte Breite und Höhe“ ein „anderes Problem“ sein sollen. Dein Verweis auf den Chromium-Bugtracker gibt mir auch keinen Aufschluss über deinen Gedankengang.

    • Offizieller Beitrag

    In dem Issue ging es ursprünglich um die falsche Bildausrichtung, nicht um irgendwelche vertauschten Abmessungen.

    Das hängt aber unmittelbar zusammen, da durch die falsche Ausrichtung das Bildformat abweicht. Eine 2x1 Grafik mit 90° Drehung in der EXIF-Orientation wird vom Browser mit 1x2 Pixel angegeben (nach Anwendung der Drehung entsprechend der EXIF-Information), die Pixeldaten stammen aber vom ungedrehten 2x1 Bild.

    Diese Diskrepanz ist für die fehlerhaft erzeugten Bilder verantwortlich, dieser merkwürdige Effekt variiert abhängig vom Seitenverhältnis.

  • Jap warten das chrome das fixt aber auch mir wurde gesagt dass safari ein ähnliches Problem macht, deckt der temporäre "fix" alle browser mit ähnlichem Verhalten ab?

    Aktuell umgeht das workaround nur das Problem, Nachteil (nehme ich an) die Bilder werden überhaupt nicht skaliert und original hochgeladen, wenn Problem erkannt wird.

    ┌П┐(◉_◉)┌П┐

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!