Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] imagecopyresized vs imagecopyresampled

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Erledigt] imagecopyresized vs imagecopyresampled

    Normalerweise müsste imagecopyresized doch merklich schneller sein als imagecopyresampled, oder?


  • #2
    Wenn Du insgesamt in den Sekundenbereich kommst, wird das vielleicht bemerkbar.

    Kommentar


    • #3
      ja also ich lade z.b. bilder von einer digicam mit 8 megapixel hoch... das dauert fast eine minute bis die sache beendet ist (inkl. thumbnail generieren und abspeichern).

      Kommentar


      • #4
        Und was daran dauert nun genau wie lange?
        Hochladen: ?
        Thumbnail erstellen: ?
        Speichern: ?

        microtime() kan Dir da vielleicht wieterhelfen. Ich tippe mal darauf, dass das Hochladen den größen Teil beansprucht. Oder was veranstaltet das Skript da alles?
        Wozu brauchst Du für ein thumbnail eigentlich imagecopyresampled? Soll da noch irgendwas auf das Bild drauf (ein Wasserzeichen o.ä.)?

        Kommentar


        • #5
          nein das hochladen kann unmöglich so lange dauern. habe eine ADSL Leitung wo up und downstrem den vollen Speed haben, knapp 1 MB pro Sekunde. Im FTP lade ich das Bild im null-komma-nix auf den Server. So schnell kann ich kaum gucken.

          Muss also wenn mich nicht alles täuscht am lahmen Server liegen. Mein Grafikprogramm verkleinert so ein Bild auch im null-komma-gar-nichts und mein PC ist auch kein 500 Mio Rechenzentrum wie 1&1 ...daher versteh ich das schon mal gar nicht. Ob die das wohl mit absicht bremsen???

          gute Frage. Also:

          imagecopyresized zerhackt das Bild nur. Dementsprechend super sieht es dann auch aus. Es schnippst einfach successive jeden xten Pixel weg, genauso wie es der Browser macht wenn man im HTML-Code ein Bild Zwangsverkleinert (was totaler schmarrn ist).

          imagecopyresampled macht es richtig: Überschüssige Pixel werden nicht einfach weggeschnippst sondern es werden vorher jeweils x benachbarte Pixel multipliziert und auf die RGB werte geteilt, also interpoliert. den genauen algorithmus hab ich grad auch nicht im kopp. aber auf diese weise bleiben keine alten pixel bestehen sondern das gesamte bild basiert auf einer neuen berechnung. wo ein pixel raus gekickt wurde, haben die nachbarpixel dessen eingenschaften zu einem gewissen prozentsatz geerbt. für das auge sieht das dann entsprechend sensationell aus. besser jedenfalls, als einfach pixel raus zu schmeissen. da wirkt die grafik wie legosteine aus 20 meter entfernung. aber nicht immer: manchmal hat man glück, etwa dann wenn das bild genau 100 x 100 pixel gross ist. da macht sich imagecopyresized nicht so sehr negativ bemerkbar. aber jetzt nimm mal ein bild mit 371 x 239 pixel ... da kann dann nur noch asymetrisch rausgeschnippst werden, und das bild wirkt im schlimmsten fall so als hat da mal eben jemand ne zeile verrückt.

          meine idee war jetzt zu prüfen, ob das bild "copyresized-tauglich" ist. wenn ja: damit. wenn nicht: copyresampled. oder erst mit copyresized den grössten schmarrn raus (bei 8 megapixel ist das eine ganze menge, wenn man später nur ein 300 x 200 pixel bild will), und den rest nochmal mit copyresampled überschmirgeln.

          die beiden dinger kann man sich wie schmirgelpapier vorstellen. copyresized ist ein ganz grobes, da könnte man meinen es geht schneller eine menge x abzutragen. copyresampled ein sehr feines Aluminiumoxid mit 1,5µ Körnung (Display-Politur ). Eine menge x trägt sich damit langsamer ab, dafür ist das finish top und nicht grob.

          Bleibt mir wohl nur das ausprobieren, wird wohl ne lange nacht was...
          mktime ist ne gute idee. gibts nicht auch einen tollen befehl damit die cpu-laufzeiten bei jedem befehl protokolliert werden?

          Kommentar


          • #6
            Es gibt auch für php profiler, die den zeitlichen Aufwand auswerten.
            zB http://dd.cron.ru/dbg/

            Und nichts gegen GD, aber ImageMagick ist idR besser geeignet.
            Datei speichern und dann mogrify aufrufen ...sofern verfügbar.

            Kommentar


            • #7
              habe eine ADSL Leitung wo up und downstrem den vollen Speed haben
              Habe ich ja noch nie gehört.
              Sicher dass dein Upload = Download ist ?

              Kommentar


              • #8
                Zitat von FiredUp
                habe eine ADSL Leitung wo up und downstrem den vollen Speed haben
                dann häteste aber SDSL, oder wie das auch immer heist
                Wie man Fragen richtig stellt

                Kommentar


                • #9
                  Wenn Upload genauso schnell wie Download wäre, könnte jeder einen eigenen Server sich in die Bude stellen.
                  Die meisten denken denken immer »bohhhhh was fürn Download ...« und beziehen auch das auf den Upload.
                  Wissen aber garnicht , dass der Upload garnicht so schnell ist.

                  Und bei grafischen Dingen fallen die meisten auf die Fresse, weil sie ihre Codes einfach nur schlamperhaft programmiert haben, und dann sich sich wundert, warum es so lange dauert.
                  Oder vergessen einfach, wieviel Speicher eigentlich verbraucht wird.
                  Die GDlib ist nunmal kein Grafikprogramm !!!

                  bei 8 megapixel ist das eine ganze menge
                  Sagt eigentlich garnichts aus.
                  Wie Breit und wie Hoch sind denn die Bilder ?
                  Sind die Bilder hier zu groß, kann es passieren, dass granichts passiert
                  (was fürn Satz)

                  Kommentar


                  • #10
                    knapp 1 MB pro Sekunde. Im FTP lade ich das Bild im null-komma-nix auf den Server. So schnell kann ich kaum gucken.
                    Das darf man dem OP dch wohl unterstellen, bewerten zu können, oder?

                    Die GDlib ist nunmal kein Grafikprogramm !!!
                    paint.exe nennt sich auch Grafikprogramm. GDLib stellt die gewünschte Funktionalität doch bereit. Wo ist das Problem? (Bis darauf, das ImageMagick einfach bessere Ergebnisse liefert.)

                    Sind die Bilder hier zu groß, kann es passieren, dass granichts passiert Smile
                    (was fürn Satz)
                    Genau, was für'n Satz. Damit unterstellst Du OP doch schon wieder extreme Dummheit.

                    Kommentar


                    • #11
                      Zitat:
                      Sind die Bilder hier zu groß, kann es passieren, dass granichts passiert Smile
                      (was fürn Satz)
                      Genau, was für'n Satz. Damit unterstellst Du OP doch schon wieder extreme Dummheit.
                      *lol*

                      Damit meine ich, ob die Bilder in ihrer Breite oder Höhe zu groß sind, nicht Dateigröße.
                      Die GDlib steigt im Gegensatz zu Paint (oder sonstigen Müll) aus, wenn Bilder zu große Breiten und Höhen haben.

                      Kommentar


                      • #12
                        Zitat von CIX88
                        Die GDlib steigt im Gegensatz zu Paint (oder sonstigen Müll) aus, wenn Bilder zu große Breiten und Höhen haben.
                        Sicher, dass es dann nicht einfach nur daran liegt, dass die Dateigröße zu groß wird?

                        Kommentar


                        • #13
                          Sicher, dass es dann nicht einfach nur daran liegt, dass die Dateigröße zu groß wird?
                          100%ig sicher ...
                          Die Dateigröße hat bei der GDlib erstmal überhaupt keine Bedeutung.
                          Diese ist nur das Resultat nach dem Speichern des Bildes.

                          Wer z.B. Photoshop hat, kann das nachvollziehen.
                          Egal welche Dateigröße vorliegt, das Bild Bild belegt im Speicher immer die selbe Größe, welche sich aus Breite, Höhe, Farbtiefe, Aplhakanäle etc. ergibt.

                          EDIT:
                          Achso, die jeweilige Auflösung des Bildes kommt auch noch dazu ^^^.

                          Siehe -> Datenmenge eines Bildes !

                          Kommentar


                          • #14
                            Zitat von CIX88
                            100%ig sicher ...
                            Die Dateigröße hat bei der GDlib erstmal überhaupt keine Bedeutung.
                            Diese ist nur das Resultat nach dem Speichern des Bildes.
                            Wenn du eine Speicherbeschränkung durch memory_limit hast, kann das durchaus kritisch werden, da meines Wissens nach Bilder bei der Bearbeitung mit der GD Library in ein GD-internes Format umgewandelt werden, welches deutlich mehr Speicher belegt.

                            Kommentar


                            • #15
                              Wenn du eine Speicherbeschränkung durch memory_limit hast, kann das durchaus kritisch werden
                              Genauso ist das ...

                              Deshalb fallen viele auf die Fresse wenn sie ihr PHP-Code (bezogen auf GDlib) unsauber oder recht wilde programmieren.

                              Nehmen wir an, wir wollen ein Thumnail erstellen (einfaches Beispiel).

                              Zuerst muss das eigentliches Bild geladen werden, hier wird schon das erste mal Speicher verbraucht.
                              Dann erzeugen wir ein neues Bild, dann wird nochmehr Speicher verbraucht.
                              Fällt alles zusammen über den Limit-Bereich, wars das schon

                              Wenn dann der erzeugte Speicher nicht frei gegeben wird (sehe ich sehr oft hier im Forum), braucht sich keiner wundern, wenn das Bild nur teilweise bis garnicht erzeugt wird, und das ohne Fehlermeldungen.

                              Das ist fast das gleiche, wenn man 20 und mehr Programme auf dem Rechner zugleich laufen lassen will, irgendwann sagt der Rechner »NÖ« und bleibt stehen

                              Kommentar

                              Lädt...
                              X