Fuji X Secrets JPEG Entwicklung Kamera vs. PC: Verschoben aus Fragen an Rico

[Gast]

Werbung (verschwindet nach Registrierung)

Nikon:  https://onlinemanual.nikonimglib.com/z30/de/09-07-01.html  inkl. picture Control

die anderen gucke ich jetzt nicht alle durch. 😉

[mjh]

vor 3 Stunden schrieb Rakete:

Aber ist es nicht so, dass die aktuellen Digitalkameras zu einem nicht unerheblichen Teil aus Software bestehen? Ich denke, das lässt sich gar nicht mehr so klar trennen...

Natürlich steckt in jeder Digitalkamera ein Computer und der führt eine Software aus – die Firmware der Kamera. Aber um die geht es hier ja nicht, sondern um Anwendungen, die außerhalb der Kamera auf dem Computer des Fotografen laufen.

[Gast]

vor 5 Minuten schrieb mjh:

Aber um die geht es hier ja nicht, sondern um Anwendungen, die außerhalb der Kamera auf dem Computer des Fotografen laufen.

Genau gesagt geht es hier darum (in meinem Sinne) um das was IN der Kamera läuft (Asic + Firmware) 1:1 auf dem PC laufen zu lassen. Auf das Ergebnis bezogen. Die Firmware ist natürlich auch ein Bestandteil an dem man merken kann, diese triggert auch nur die in "Hardware fest vergossene Software" an, sonst wäre das Nachliefern einer neuen Filmsimulation per Firmware nicht möglich. Also ist z.B. "Reala" nicht einfach nur in einen Chip gegossen, sonst müsste Fuji für eine Chip-Generation vorab schon alle künftigen Filmsimulationen fertig haben und eingeplant haben.

[mjh]

vor 47 Minuten schrieb r1511:

Also ist z.B. "Reala" nicht einfach nur in einen Chip gegossen

Keine Filmsimulation ist „in einen Chip gegossen“, das ist alles Firmware (also Software). Dass diese Firmware für eine bestimmte Hardware geschrieben ist und daher nur auf dieser läuft (ohne dass man sie mit einer virtuellen Maschine emuliert), steht dem nicht entgegen.

Firmware wird in der Regel sehr hardwarenah programmiert; man nutzt die Tatsache aus, dass man exakt weiß, mit welcher Hardware man es zu tun hat. Das steht in einem deutlichen Gegensatz zur Anwendungsentwicklung für PCs und Macs, bei der man sich als Entwickler bemüht, möglichst wenig Annahmen über die Hardware zu machen, die ja bei jedem Anwender ein bisschen anders aussehen kann. Im Ergebnis läuft die Software auf einem breiten Spektrum von Maschinen (wenn auch nicht auf allen gleich schnell), aber nie so flott wir die für eine einzige Hardware programmierte Firmware.

bearbeitet 2. Juli 2024 von mjh

[Gast]

vor 2 Minuten schrieb mjh:

Keine Filmsimulation ist „in einen Chip gegossen“, das ist alles Firmware (also Software).

welcher Teil der Software nun fest verdrahtet im Chip liegt und welcher in der reprogrammierbaren Firmware, das wird nur Fuji wissen. Und der Chiphersteller (die wird nicht Fuji selbst bauen, oder?). DER Algorithmus der jpeg Engine der die höchste Rechenpower benötigt, der wird im Chip liegen müssen, damit es eben schnell weggearbeitet werden kann (Energiesparend, effizient in der Verarbeitung = Vorteil des Asics).

[Gast]

vor 32 Minuten schrieb mjh:

Firmware wird in der Regel sehr hardwarenah programmiert; man nutzt die Tatsache aus, dass man exakt weiß, mit welcher Hardware man es zu tun hat.

jau, das ist so, aber NOCH besser ist es, wenn ein Teil der Software IN der Hardware liegt, eingebrannt, Routinen, welche die Firmware anspricht und dann auf Hardwareebene abgearbeitet wird. DAS ist der entscheidene Unterschied zum PC und der SOftware für diesen. In Netzwerkswitchen z.B. wird sowas gemacht, in Firewalls (appliances) usw. Und eben in Kameras, zumindest gehe ich davon aus. Um es klarer zu beschreiben: Sollte Fuji die Chips herstellen lassen, dann geben sie dem Hersteller Software Routinen an die Hand und sagen ihm: Bau uns diese Routinen fest in die Hardware, die sind für uns fix, die brauchen wir nie dynamisch anpassen via Firmware.

[didole]

Werbung (verschwindet nach Registrierung)

vor 30 Minuten schrieb r1511:

welcher Teil der Software nun fest verdrahtet im Chip liegt und welcher in der reprogrammierbaren Firmware, das wird nur Fuji wissen. Und der Chiphersteller (die wird nicht Fuji selbst bauen, oder?). DER Algorithmus der jpeg Engine der die höchste Rechenpower benötigt, der wird im Chip liegen müssen, damit es eben schnell weggearbeitet werden kann (Energiesparend, effizient in der Verarbeitung = Vorteil des Asics).

Na ja, aber da Fuji neue Filmsimulatiionen per Software-Update nachliefern kann, zeigt ja ganz deutlich, dass die nicht in Chips verdrahtet sind. Letztendlich ist das ein Algorithmus, der irgendwo definiert ist, und den man ohne jede Abhängigkeit zu einem Betriebssystem in jeder höheren Programmiersprache implementieren könnte - wenn man es wollte. 
 

Fuji will das nicht, und das verstehe ich auch. 

[Gast]

Gerade eben schrieb didole:

Na ja, aber da Fuji neue Filmsimulatiionen per Software-Update nachliefern kann, zeigt ja ganz deutlich, dass die nicht in Chips verdrahtet sind.

jein. Einerseits sage ich ja, dann sind wir wieder am Anfang, es ist eine Ausrede, das die Simulationen NUR per Kamera machbar wären.

Und eine (großer) Teil WIRD in der Hardware liegen, sonst ginge es nicht so performant (auch bei der nachträglichen In-Camera jpeg Erzeugung nicht).

Fuji müsste halt nur alle Teile (Firmware UND den im Chip liegenden "Softwareteil" in ein externes Programm bauen wollen. Es its keine Frage ob es geht, sondern ob man es möchte. Von der Performance wäre es nicht anders als eine Raw Entwicklung in C1, LR, darktable oder sonstwas. Da ist es den Leuten ja auch schnell genug. Zusammen mit der Nutzung heutiger GPUs sowieso. G'scheit programmieren muss man es halt.

[mjh]

vor 8 Minuten schrieb r1511:

NOCH besser ist es, wenn ein Teil der Software IN der Hardware liegt, eingebrannt, Routinen, welche die Firmware anspricht und dann auf Hardwareebene abgearbeitet wird.

Das verringert aber auch die nötige Flexibilität für Firmware-Updates und macht die Korrektur von Bugs in diesem Bereich unmöglich; daher ist es keineswegs die bessere Lösung. Und welche Bildverarbeitungsoperationen sollte es auch sein, bei denen sich ein Custom-Chip lohnen würde? Vereinzelt ist so etwas schon mal gemacht worden, zum Beispiel zur Rauschunterdrückung bei Pentax/Ricoh, aber eine Erfolgsgeschichte war das meiner Einschätzung nach nicht. Die Kameraprozessoren sind durchweg universelle CPUs, ergänzt heutzutage durch KI-Koprozessoren (wie es sie allerdings auch in Desktop-PCs gibt, sei es in der GPU oder ebenfalls einem dedizierten KI-Koprozessor wie Apples Neural Engine). Und auch KI-Prozessoren arbeiten immer noch eine im EEPROM gespeicherte Firmware ab, die sich aktualisieren lässt.

[Gast]

vor 2 Minuten schrieb mjh:

Das verringert aber auch die nötige Flexibilität für Firmware-Updates und macht die Korrektur von Bugs in diesem Bereich unmöglich; daher ist es keineswegs die bessere Lösung. Und welche Bildverarbeitungsoperationen sollte es auch sein, bei denen sich ein Custom-Chip lohnen würde?

Klar, kein Vorteil ohne Nachteil, oder so ähnlich 😉

Bei der "Clarity" und "Korn" könnte das der Fall sein wo es sich lohnen würde. Da sagt Fuji, es ginge mit älteren Kameras nicht, aufgrund der Leistung?? Ob das alles stimmt, wer weiß es schon. Aber wenn denn nun alles ganz unabhängig der Chips sein soll, dann wäre es nur eine CPU Leistungsfrage was geht und was nicht. Dann könnte Fuji wenigstens Reala, sagen wir, auf eine X-E4 und X-T2 bringen, der braucht auch nicht mehr Leistung als ein Provia (der schon in der ollen X-Pro1 läuft).

Aber wie es wirklich läuft unter der Haube, das weiß nur ein Entwickler aus dem Hause Fuji, und den haben wir hier sicher nicht dabei, zumindest nicht ausplaudernd.  🤫

[mjh]

vor 1 Stunde schrieb r1511:

Bei der "Clarity" und "Korn" könnte das der Fall sein wo es sich lohnen würde.

Das Problem mit der Klarheit ist, dass zur Berechnung eines Bildpixels jeweils (vermutlich) Hunderte von Pixeln berücksichtigt werden müssen, während für fast alle anderen Operationen gilt, dass ein Pixel in ein anderes umgerechnet wird. Um solche Berechnungen zu beschleunigen, müsste man auf eine massive Parallelverarbeitung setzen. Ich hatte es schon verschiedentlich erwähnt (u.a. in DOCMA), dass hier ein KI-Koprozessor helfen könnte: Genauso wie Grafikprozessoren für KI-Aufgaben zweckentfremdet werden können, ließ sich ein KI-Koprozessor für Grafikaufgaben nutzen. Sowohl GPUs wie auch KI-Prozessoren enthalten Tausende relativ einfach aufgebauter CPUs, und das ist genau das, was man hier braucht.

Aber wie gesagt: Hier handelt es sich immer noch um frei programmierbare Prozessoren.

[Dare mo]

Ich verstehe einerseits die Überlegungen, ob sowas technisch machbar ist. Andererseits stellt sich mir die Frage, braucht man das wirklich? Was ist denn an der aktuellen Situation so schlimm, dass man alles am PC machen möchte?

Ich kann da jetzt wirklich nur für mich sprechen, aber ich bin sehr froh, wenn ich nicht mehr, oder nur in einem sehr geringen Umfang, am PC Bilder bearbeiten muss.

Meine Erfahrung zeigt auch, wenn man versucht zu viele Dinge in einem zu vereinen, dass das auch dazu führt, daß dies dann auch fehleranfälliger wird. Denn jemehr Komponenten aufeinander abgestimmt werden müssen, umso mehr mögliche Fehlerquellen gibt es. Solange alles Funktioniert mag das eine feine Sache sein, aber die Erfahrung zeigt auch, wenn es doch zu einer kleinen Störung kommt, und sei es dass beim Hochfahren eine Funktion von einer Komponente nicht reagiert, dann steht das ganze System. Darum die Frage, braucht man sowas wirklich? Rentiert sich der Aufwand im Vergleich zum tatsächlichen Nutzen?

bearbeitet 3. Juli 2024 von Dare mo

[Leicanik]

vor 49 Minuten schrieb Dare mo:

Was ist denn an der aktuellen Situation so schlimm, dass man alles am PC machen möchte?

Naja schlimm … Mit X Raw Studio macht man es doch sowieso schon am PC. Und die Bilder müssen ja auch bereits auf dem PC lagern. Da wäre es halt einfacher, wenn man nicht extra die Kamera dranhängen müsste. Naiv (als IT Laie) hätte ich auch erhofft, dass es dann etwas flüssiger laufen würde (obwohl, ich muß es jetzt mal mit meinem neuen MacBook versuchen, mit dem älteren Asus, das ich vorher hatte, lief es schon ein bisschen „zähflüssig“). Und saugt es bei der derzeitigen Lösung nicht auch den Kamera-Akku leer? Alles nicht „schlimm“, aber könnte ein bisschen bequemer werden. Außerdem könnte man dann auch Raws bearbeiten, wenn die Kamera nicht (mehr) da ist.

Bei mir hat die gewisse Umständlichkeit der Handhabung dazu geführt, dass ich dazu neige, entweder gleich die Kamera-JPEGs zu verwenden, oder die Raws doch eher mit C1 zu entwickeln, nicht mit X Raw Studio, was auch wieder schade ist.

(Immerhin hat die Diskussion dazu geführt, dass ich es jetzt mal wieder probieren werde  )

bearbeitet 3. Juli 2024 von Leicanik

[Gast]

vor 2 Minuten schrieb Leicanik:

wenn man nicht extra die Kamera dranhängen müsste. Naiv (als IT Laie) hätte ich auch erhofft, dass es dann etwas flüssiger laufen würde

Ich bin mir sicher, es WÜRDE auch flüssiger laufen. Gute Raw Konverter laufen ja flüssig und das sogar, wenn man weitaus komplexere Veränderungen in einem Rutsch anwendet ("Style" mit ALLEN Einstellungen gleichzeitig). Sehr gute auf entspr. Hardware nahezu in Echtzeit, so ist es bei mir jedenfalls).

X-Raw studio ist vermutlich deswegen langsamer als die Kamera selbst, weil die Übertragung/ Kommunikation dazwischen liegt, zusätzlich vermutlich liegt es an schlechter Programmierung (siehe auch mein Hinweis zum nervigen "maus-over für Vorschau").

Ein X-Raw Studio PRO könnte auch deshalb sehr flüssig und recht fehlerfrei laufen, weil es in den Funktionen grundsätzlich schlank gehalten werden könnte: jpeg Einstellungen, Beschnitt und ein gescheites Export Modul. Fertig. Nix mit "verbessern KI", komplexe Farbmodule usw.

[EchoKilo]

vor 1 Stunde schrieb r1511:

Gute Raw Konverter laufen ja flüssig und das sogar, wenn man weitaus komplexere Veränderungen in einem Rutsch anwendet ("Style" mit ALLEN Einstellungen gleichzeitig).

Das geht auch im RAW Studio: Profile (JPEG Einstellungs-Sammlungen) erzeugen und einem Bild auf Knopfdruck zuweisen. 

Du hast recht, dass die Trägheit des Programms durch die Kommunikation mit der Kamera verursacht wird. Jede Veränderung am Bild verursacht einen kompletten Entwicklungszyklus (RAW zur Kamera, Entwickeln, JPEG zurück). Wenn man das einschränkt (entwickeln nicht bei Maus-Over und nur bei Klick auf einen Menüpunkt, wäre das etwas flüssiger). Sollte man an- oder abwählbar machen. Aber dann geht das spielerische Ausprobieren verloren, was man vermutlich erreichen wollte. Vielleicht, wenn man das aktuelle RAW in der Kamera cached/zwischenspeichert würde man etwas Zeit gewinnen.

Ich befürchte aber, wenn die komplette Logik auf ein PC -Programm übertragen wird, öffnet Fuji sich eine Buchse der Pandora: jede Änderung an der JPG-engine einer Kamera müsste zeitnah im Studio nach implementiert werden und es werden zusätzliche Wünsche auftauchen: Beschnitt wurde schon genannt, warum auch nicht den Horizont begradigen etc.?

Die aktuelle Variante hat schon ihren Charme: lässt sich auf alten und neuen, großen und kleinen Rechnern benutzen, bietet einen großen Bildschirm und man kann die (neuesten) Bilder in Fuji Qualität entwickeln. Wenn ich mehr will, nehme ich einen spezialisierten Entwickler mit mehr Funktionen. 

Ich benutze das Studio allerdings selten, rege mich also selten über die USB Geschwindigkeit meines Rechners auf.

Implementieren kann man alles, aber Aufwand und Nutzen sind zu verschieden. Soll Fuji erstmal den AF auf Vordermann bringen.

bearbeitet 3. Juli 2024 von EchoKilo

[Gast]

vor 4 Minuten schrieb EchoKilo:

und es werden zusätzliche Wünsche auftauchen: Beschnitt wurde schon genannt, warum auch nicht den Horizont begradigen etc.?

ja, Beschnitt, Ausrichten, Gitter einblenden, Perspektiv-Korrektur. Aktuell mache ich das in einer Software mit den Fuji jpegs, das wäre also gut im Fuji Konverter direkt zu haben. Und die jpegs aus dem X-Raw Konverter müssen sogar für eine Größenänderung, was in den Export Dialog gehört) extra angepackt werden. Und sei es nur für die Ausgen in 2000px Kantenlänge.

vor 4 Minuten schrieb EchoKilo:

Soll Fuji erstmal den AF auf Vordermann bringen.

Das sagst Du jetzt einem der nur noch manuelle Objektive für die X hat.  🙂

[EchoKilo]

vor 6 Minuten schrieb r1511:

Das sagst Du jetzt einem der nur noch manuelle Objektive für die X hat.  🙂

Ach, erst kaufst Du keine Fuji Produkte (Objektive) mehr und dann sorgst Du Dich um Aufgaben für den Programmierer von Fujifilm? 😉

[Gast]

vor 20 Minuten schrieb EchoKilo:

und dann sorgst Du Dich um Aufgaben für den Programmierer von Fujifilm?

haha, ja genau  😉  darum schreibe ich auch sicherheitshalber von der X-Raw Studio PRO Version, die kostet dann natürlich etwas Geld damit die Abteilung da auch leben kann.

[kermit66]

vor 2 Stunden schrieb r1511:

X-Raw studio ist vermutlich deswegen langsamer als die Kamera selbst, weil die Übertragung/ Kommunikation dazwischen liegt, zusätzlich vermutlich liegt es an schlechter Programmierung (siehe auch mein Hinweis zum nervigen "maus-over für Vorschau").

Ich habe bisher nicht verstanden, warum das gefühlt eine Ewigkeit dauert. Ich habe meine Kamera via USB 3 an meinen Rechner angeschlossen. USB 3 hat eine Mindestgeschwindigkeit von 5 GBit, also mehr als 500 MByte/s. Daten zur Kamera (X-T5) und zurück müsste also in 1/10s erledigt sein. Mein Rechner verwendet eine SSD mit NVMe-Interface und ca. 5 Gbyte/s zur Datenspeicherung. Die Kamera schafft bis zu 20 RAW-Bilder/s mit elektronischem Verschluss. Ich frage mich wo der Flaschenhals ist.

[max2331]

Das Problem am X-Raw Studio und an der Funktionsweise nur mit Kamera ist doch, dass wenn man die Kamera erneuert, man alte RAWs damit nicht mehr bearbeiten kann. Man kann ja nicht mal X-E4 RAWs mit einer X-S10 oder X-T4 bearbeiten obwohl gleicher Sensor und gleiche Engine. Wenn es wenigstens eine Rückwärtskompatibilität gäbe.

[mjh]

vor 2 Stunden schrieb kermit66:

USB 3 hat eine Mindestgeschwindigkeit von 5 GBit, also mehr als 500 MByte/s. Daten zur Kamera (X-T5) und zurück müsste also in 1/10s erledigt sein.

Für die Übertragung eines Bildes in voller Auflösung müssen 120 Megabyte übertragen werden, was bei 5 Gb/s oder 625 MB/s rund 0,2 s dauern würde. OK, das ist nur doppelt so lang wie 0,1 s, aber immerhin. Vielleicht geht es schneller, wenn die Kamera das Bild erst intern auf eine vorschautaugliche Auflösung herunterrechnet, keine Ahnung. Welche Geschwindigkeit erreicht die USB-Schnittstelle der Kamera denn überhaupt in der Realität, wenn man darüber Bilder überträgt? 

[kermit66]

vor 9 Minuten schrieb mjh:

Welche Geschwindigkeit erreicht die USB-Schnittstelle der Kamera denn überhaupt in der Realität, wenn man darüber Bilder überträgt? 

Hier sind die SD-Karten eher der Flaschenhals. Bei der Anwendung des X-RAW-Studios wäre eine Speicherung auf der SD-Karte nicht erforderlich. Also eine Speicher-zu-Speicher-Übertragung sollte schneller laufen. Intern muss die Kamera das bei 20 Bilder/s auch handeln.

[Gast]

Der Export im X-Raw Studio geht ja superschnell, die Raw-Dateien liegen ja lokal auf der Festplatte, das wäre ja analog zu der Engine in der Kamera selbst (= auch schnell). Warum es so lange dauert die Berechnung zu machen, keine Ahnung? Man müsste mal die Datenmenge beim konvertieren auf der USB-Schnittstelle mitschneiden, ich glaube fast, da passiert gar nicht so viel.

Ich denke, es werden doch weder die Raw Datei noch eine jpeg Datei bei dem Vorgang transferiert? Wäre es so, ein Massenexport würde vieeel länger dauern.

bearbeitet 3. Juli 2024 von r1511

[kermit66]

vor 20 Stunden schrieb r1511:

Ich denke, es werden doch weder die Raw Datei noch eine jpeg Datei bei dem Vorgang transferiert?

Die RAW-Datei muss auf jeden Fall Richtung Kamera transferiert werden und das JPEG Retour zum PC. Ohne den kompletten Daten kann die Kamera keine Konvertierung vornehmen. Die Bilddaten sind bezogen auf die Pixelmenge unterschiedlich groß. Die Verzeichung wird korrigiert und andere positionsabhängige Daten (Stichwort LMO).

[Gast]

vor 16 Minuten schrieb kermit66:

Die RAW-Datei muss auf jeden Fall Richtung Kamera transferiert werden und das JPEG Retour zum PC.

Ich hab mir mal die Mühe gemacht einen USB Portmonitor mitlaufen zu lassen; es ist wohl so, es gehen merkbar Daten in beide Richtungen, die Datenmengen würden zu Deiner Aussage auch passen. Dafür geht es dann doch recht zügig, sprich die USB Schnittstelle der Kamera liefert eine recht gute Performance.

[Dein Support für das Forum]

Hat dir das Forum geholfen? So kannst du das Forum unterstützen!

Premium Mitglied werden | Spenden | Bei Amazon* oder eBay* kaufen
Software: Topaz* | DxO Nik Collection* | Skylum Luminar* (–10€ mit Gutschein FXF) | * Affiliate Links