NSString drawAtPoint in Farbe funktioniert nicht? [solved]

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Ich bin ja nicht iOS, darum hab ich den Luxus libjpeg UND ImageIO, je nach belieben ;)

    Aber libjpeg ist frei, sollte kein Problem sein, das statisch bei Dir einzubinden. Du kannst auch mal schauen, ob libjpeg-turbo evtl. auf dem iOS sich kompilieren lässt, die hatten etwas aufgeräumt, denk ich.

    OpenCV läuft ja soweit ich weiss auf dem iOS, und OpenCV nimmt auch libjpeg, also muss es gehen.

    Achso: Und ich verschwende in der Anwendung leider selbst recht viele Zyklen für eine Konvertierung ImageIO/CGImage <--> boost::gil. Muss ich mal geschickt umstellen, aber auf dem Mac ist das nicht ganz so kritisch...
    C++
  • Thallius schrieb:

    Schnelles gutes Skalieren wird normalerweise über Mip-Mapping gemacht und die MipMap entsprechend gewählt.

    Das lohnt sich aber nur, wenn Du oft skalieren musst. Die Mipmap musst Du ja auch erst aufbauen, was ja mehreren Skalierungs-Operationen entspricht. Ich möchte mal bezweifeln, dass iDevices das in Hardware übernehmen (wobei, theoretisch, ist das Teil von ES2? Müste fast?), zumindest wird es nicht lohnen, wenn man nur einmal herunterskalieren will ;)
    C++
  • zerm schrieb:

    Thallius schrieb:

    Schnelles gutes Skalieren wird normalerweise über Mip-Mapping gemacht und die MipMap entsprechend gewählt.

    Das lohnt sich aber nur, wenn Du oft skalieren musst. Die Mipmap musst Du ja auch erst aufbauen, was ja mehreren Skalierungs-Operationen entspricht. Ich möchte mal bezweifeln, dass iDevices das in Hardware übernehmen (wobei, theoretisch, ist das Teil von ES2? Müste fast?), zumindest wird es nicht lohnen, wenn man nur einmal herunterskalieren will ;)


    Jein,

    natürlich sind MipMap besonders effektiv wenn man das gleiche Bild mehrfach skaliert. Aber ich habe damals mehrere Skalier-Verfahren ausprobiert und von der Geschwindigkeit/Ergebnis her war die tatsächlich die beste. Auch wenn man nur einmal skaliert. Ich muss aber auch zugeben, dass ich nicht versucht habe irgendwelche hoch optimierten MMX Routinen zu schreiben.

    Ich weiß nicht wie weit die jpeglibs heute sind, das letzte mal das ich damit gearbeitet habe ist ein paar Jahre her, aber ich nehme einfach mal an, dass die libs gar nicht skalieren, sondern einfach direkt den thumbnail aus dem Foto holen. Damals mußte ich das noch selber programmieren. Da konte man mit der jpeglib tatsächlich nur das große Bild laden. Ich habe dann eine exiflib geschrieben, welche den thumbnail aus dem Foto mit Hilfe der jpeglib decodiert hat. Da gab es dann halt eine Funktion getStampFromImage(). Ich denke sowas wird heute in den libs schon drin sein.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    natürlich sind MipMap besonders effektiv wenn man das gleiche Bild mehrfach skaliert. Aber ich habe damals mehrere Skalier-Verfahren ausprobiert und von der Geschwindigkeit/Ergebnis her war die tatsächlich die beste. Auch wenn man nur einmal skaliert. Ich muss aber auch zugeben, dass ich nicht versucht habe irgendwelche hoch optimierten MMX Routinen zu schreiben.

    Womit hast Du die MipMap erstellt, also mit welchem API-Call? Die einzige Extension (soweit mir bekannt), die MipMaps theoretisch auf der GPU berechnet ist ARB_framebuffer_object. Alles andere ist auch nur C-Code, der ganz primitiv das Bild log_2(max(w,h)) mal skaliert und auf die GPU läd.
    C++
  • zerm schrieb:

    Thallius schrieb:

    natürlich sind MipMap besonders effektiv wenn man das gleiche Bild mehrfach skaliert. Aber ich habe damals mehrere Skalier-Verfahren ausprobiert und von der Geschwindigkeit/Ergebnis her war die tatsächlich die beste. Auch wenn man nur einmal skaliert. Ich muss aber auch zugeben, dass ich nicht versucht habe irgendwelche hoch optimierten MMX Routinen zu schreiben.

    Womit hast Du die MipMap erstellt, also mit welchem API-Call? Die einzige Extension (soweit mir bekannt), die MipMaps theoretisch auf der GPU berechnet ist ARB_framebuffer_object. Alles andere ist auch nur C-Code, der ganz primitiv das Bild log_2(max(w,h)) mal skaliert und auf die GPU läd.


    Da das ganze auf einem properitären (ich kann mit einfach nicht merken wie man das Wort schreibt) System lief mit VXWorks als Betriebssystem, gab es keine Grafik API's. Da haben wir jede Zeile selber gemacht. Aber bitte frag mich nicht mehr. Der Code dürfte irgendwo auf einer meiner zig Backup-CD's rumgammeln.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    Da das ganze auf einem properitären (ich kann mit einfach nicht merken wie man das Wort schreibt) System lief mit VXWorks als Betriebssystem, gab es keine Grafik API's. Da haben wir jede Zeile selber gemacht. Aber bitte frag mich nicht mehr. Der Code dürfte irgendwo auf einer meiner zig Backup-CD's rumgammeln.

    Wie jetzt, also Du hattest die MipMap auf der CPU gebaut?
    Nehmen wir an, ich will mein Bild 50% Skalieren. Ohne MipMap ist das einmal skalieren auf 50%. Mit MipMaps skaliere ich erstmal auf 50%, dann 25%, dann 12,5% etc, kombiniere dann die Pixel in eine MipMap und gebe dann aus der MipMap jeweils drei Bytes des vierten Kanals zurück (da liegen ja die RGB für 50%). Das soll effizienter sein?
    Selbst, wenn man 75% haben will bin ich einfach nicht überzeugt, das MipMap-bauen und samplen schneller sein soll, als einmalig zu skalieren.

    Und gerade Downsampling, da reicht ja meist sogar Nearest-Neighbor um akzeptable Ergebnisse zu bekommen...Mhh. Aber gut, mit MipMapping kann ich die MipMap "schnell" mit Nearest-Neighbor aufbauen, und 75%-Skalierung sieht dann dennoch besser aus, als das Ursprungsbild mit Nearest-Neighbor auf 75%.
    C++