Hallo zusammen,

kennt jemand ein Package für React Native mit dem ich Jpg pixelweise bearbeiten kann, oder mehrere jpg per Algorhythmus wie Pixel-Addition oder Pixel-Multiplikation layern kann?

Ich mag nicht stänkern - aber die Suchmaschine deiner Wahl liefert mit dem Suchbegriff "React Native Image Manipulation" sicher ähnliche Ergebnisse wie die Suchmaschine meiner Wahl. Ob die etwas taugen, kann ich nicht sagen - da ich nicht mit React arbeite.

Lieber ssb,

die ersten 30 Ergebnisse auf Google habe ich schon durch.

Ich habe diverse React Native Librarys ausprobiert und bereits mehr als 80 Stunden investiert, um mit diversen NPM Paketen meine Idee ans Laufen zu bringen.
Wenn ich schon hier eine Frage stelle, dann nicht, damit jemand mir versucht Google zu erklären. Immerhin ist dies der Entwicklerbereich in dieses Forum. Hier kennt man sich mit der Google-Suche aus.

Folgende Librarys habe ich schon ausprobiert:

- react-native-gcanvas - Kann nicht mit 4k-Bilder umgehen und stürzt ab
- react-native-skia - kann nicht mit dynamischem Nachladen von Bildern umgehen
- react-native-photo-manipulator - kann keine Pixel auslesen oder setzen
- react-native-image-manipulator kann keine Pixel auslesen oder setzen
- jimp - funktioniert nicht richtig in react native
- react-native-image-tools - merge() ist nicht die Berechnungsart, wie ich Images übereinanderlegen möchte

Falls ImageMagick auf dem Server installiert ist, kannst du auch das nehmen. Muss aber gestehen, dass ich nicht viel mehr über React weiß, als dass es bei Webprojekten zum Einsatz kommt. ImageMagick kann definitiv Ebenen per Addition oder Multiplikation mischen.

Hi Nebula,

ich möchte das in React Native entwickeln, also für Android und iOS. Nicht jedes Package, was in Node oder React funktioniert, läuft auch in React Native - leider. Daher kann ich auch ImageMagick nicht verwenden.

Ich möchte dies gerne ohne Server realisieren, da ich viele Photos zusammenrechnen und diese nicht per 5G an den Server schicken möchte wegen des Traffic-Volumens der Mobilfunkverträge.

Da war ich wohl auf dem falschen Pfad, ich dachte, es geht um eine Webprojekt. Kann man nicht die nativen Frameworks der Systeme gezielt ansprechen? Würde sicher zu effizienteren Apps führen.

Das hättest du durchaus erwähnen können. Woher soll jemand wissen, was du schon erfolglos probiert/evaluiert hast?

Tja - und manchmal ist native Entwicklung dann doch besser, selbst wenn man sie für iOS und Android dann zweimal machen muss.

Kannst du native Frameworks verwenden? Zur Not schreibst du dir dann eine native Bibliothek, die du von React Native aus aufrufen kannst. Eventuell ist das dann auch nur ein Wrapper für zB ImageMagick. Ich habe solche Wrapper schon für zB. Python geschrieben. Aber wie gesagt - ich habe keine Ahnung von React Native (und bereue das auch nicht). Wenn so etwas nicht möglich ist, dann ist es vielleicht die falsche Sprache für das, was du implementieren willst.

Da gebe ich dir Recht; ich hätte das erwähnen sollen.
Ja, ich überlege tatsächlich eine native Library entweder selbst zu schreiben oder was vorhandenen zu wrappen.

Habe mich noch ein wenig schlau gemacht und versuche jetzt die Lösung in Flutter zu entwickeln.

Wenn du da mal nicht vom Regen in die Traufe kommst. Meiner bescheidenen Meinung nach führt bei Apps kein Weg an nativem Code vorbei.

Das dachte ich mir auch gerade.
Es gibt sinnvolle Anwendungsfälle, bei denen die diversen Cross-Plattform Umgebungen sinnvoll sind - selbst wenn sie am Ende kaum mehr bieten als eine gut gemachte Webseite. Die Apps, die zB. auf Elektron basieren, sind im Prinzip eigentlich auch nur WebViews.

Das Problem ist in der Regel, dass diese Cross-Platform Umgebungen halt immer nur das anbieten können, was auf allen unterstützen Plattformen verfügbar ist. Man kann auch darüber hinaus gehen, aber dann hat man wieder plattformabhängigen Code, also Code der nur auf macOS läuft, oder iOS oder Windows... Zudem hat man eben die teilweise sinnvolle Einschränkung, dass man auf einige native Frameworks nicht zugreifen kann oder dafür viel "Boilerplate"-Code braucht.
Am Ende hat man dann doch oft verschiedene Versionen für jede Plattform, selbst wenn sich Teile des Code auf allen ausführen lassen. Am Ende hängt es dann aber doch auch immer davon ab, was man machen möchte. Da kann es schon sinnvoll sein, viele Möglichkeiten zu evaluieren und sich dann erst zu entscheiden, wenn man den besten Kompromiss gefunden hat - sonst macht man vieles mehrfach und dann hätte man gleich mehrere native Lösungen bauen können.

Stimmt. Das kann man übrigens auch haben, wenn man nativ programmiert, zum Beispiel über Kotlin Multiplatform. Wovon ich aus eigener Erfahrung übrigens auch abraten würde.
Aber dann hätte man wenigstens ein natives GUI, das die Besonderheiten der Platformen nutzen kann.

Aus Anwendersicht spricht nicht viel für Crossplatform-Frameworks. Selbst die wirklich guten Affinity-Apps sind teils etwas fremdartig auf macOS. Aber bei Weitem besser als Adobes Kram. Electron ist aus meiner Perspektive die Pest. Für Teams benötige ich ein Extra-Mikrofon, weil man mich sonst aufgrund des Lüftergesäusels kaum versteht.

Immerhin sind sie nativ.

Das Risiko gehe ich ein. Ich habe jetzt ein Flutter-Package das vermutlich die Lösung für meine Idee ist und ich werde das Thema damit mal ausprobieren.

Flutter scheint ja eben nicht ein Browser zu sein, der dem System mit einer Website eine App vorgaukelt. Aber ich bin noch am Anfang der Recherche.

Flutter kompiliert für die entsprechenden Systeme. Da liegt kein Browser drunter. Es gibt ein paar packages die eigenen Code für die Zielplattform brauchen - generell hält sich dies aber in Grenzen. Ich habe mit Flutter mal angefangen, habe es aber zeitlich nicht weiter geschafft.
Nett ist vorallem, das man nicht bei jeder Code Änderung kompilieren braucht, sondern innerhalb weniger Sekunden die Änderungen sieht. Man braucht leider viel SSD-Speicher, das kostet bei Apple ja ein kleines Vermögen

Ja, das habe ich auch gelesen - immerhin. Dafür muss man sich dann mit der DART-Programmiersprache beschäftigen, die dem Anschein nach sehr nach SWIFT aussieht. Dass da im Hintergrund ein JIT-Compiler läuft ist heutzutage keine Rocket-Science mehr - es wird aber noch immer kompiliert, aber eben bereits im Hintergrund und eventuell wird auch dynamisch gelinkt, was SWIFT im Grundsatz nicht mag - bei ObjC aber Standard ist. Da gab es diesen Ansatz bereits in einer der ersten Xcode-Versionen - wenn du etwas änderst, wird auch nur das kompiliert und durch das dynamische Linken muss man nicht einmal die App beenden um (kleinere) Änderungen gleich testen zu können - geladene Objekte werden einfach "migriert". Kann nicht nimmer klappen, aber dann doch relativ oft während man am Code arbeitet. Hieß damals glaube ich "Pause-Edit-Continue" Feature basierend auf Zero-Link und brauchte einige sehr eigenwillige Konstruktionen im Mach-O Dateiformat.
Aber genau das dürfte dann mit einer größeren Nutzung von Ressourcen einhergehen - in dem Fall war ObjC tatsächlich recht effizient.

Man kann ja auf eine externe SSD oder NVME per Thunderbolt/USB auslagern

Meine ersten Schritte mit Flutter sehen sehr zuversichtlich aus. Habe auf Udemy nen Crash-Kurs gekauft, um schnell in die Syntax rein zu kommen.

Fazit: Ich habe innerhalb eines Monats Flutter soweit gelernt, dass ich meine Idee damit umsetzen konnte. Mit Flutter funktioniert die App um Welten besser als ich es jemals mit React Native hätte hinbekommen können. Die Performance der Bildnachbearbeitung ist wesentlich schneller, da Flutter die App vollständig kompiliert und nicht wie React Native mit Javascript in einer Browser-Umgebung interpretiert.

Das ist schön zu hören.