Fuji X-T5 - Bug Reports (jekami)

[Gast]

Werbung (verschwindet nach Registrierung)

vor 1 Minute schrieb kermit66:

Die JPEG-Entwicklung erfolgt in mehreren Einzelschritten. Das ist sind eine ganze Reihe von Bildmanipulationen. Vielleicht kann man auch einige zusammenfassen, z.B. all diejenigen, die z.B. die Gradation betreffen, also Filmsimulation, Lichter und Schatten. Die meisten werden aber sicher unabhängig voneinander durchlaufen, weil sie nichts miteinander zu tun haben, wie Rauschminderung, Vignettierung und Verzeichnung. Wo ich mir aber sicher bin ist, dass die Zwischenergebnisse nicht nochmal zur Sicherheit im Speicher abgelegt werden. Wenn die Daten einmal verarbeitet wurden, sind die Basisdaten einer Berechnung überflüssig und können gelöscht werden.

Gibt es eventuell irgendwo Speicherbereiche, in denen vorher! Parameter für z.B. die Gradiationskurve je nach Filmsimulation abgelegt werden, die dann für die jpg Berechnung benutzt werden? Wenn die von einem vorherigen Prozess verändert worden sind, warum auch immer, könnte die nächste Jpg Berechnung schiefgehen. War so ein Gedanke von mir.

[Gast]

vor 15 Minuten schrieb tomassini:

@Uwe1956 Das wäre prima, Uwe, ich werde ihnen auch nochmals die Ergebnisse des Forums mitteilen, die ruhen sich mMn zu sehr auf dieser Speicherkarten-Mär aus...

Nur um sicherzugehen, du schreibst doch auch an diese e-Mail Adresse: service_feie@fujifilm.com? Bei mir gab es bisher nämlich keine weitere Rückmeldungen seitens Fuji.

bearbeitet 12. Januar 2023 von Uwe1956

[tomassini]

vor 20 Minuten schrieb Uwe1956:

Nur um sicherzugehen, du schreibst doch auch an diese e-Mail Adresse: service_feie@fujifilm.com? Bei mir gab es bisher nämlich keine weitere Rückmeldungen seitens Fuji.

Genau, macnhmal kommt am gleichen Tag oder nächsten Morgen, manchmal einen Tag später eine Rückmeldung. Vl gehen sie bei dem Thema jetzt auch in Deckung 🙂

[Gast]

Ok, meine Mail ist unterwegs. Harren wir also weiter der Dinge..

bearbeitet 12. Januar 2023 von Uwe1956

[kermit66]

vor 37 Minuten schrieb Uwe1956:

Gibt es eventuell irgendwo Speicherbereiche, in denen vorher! Parameter für z.B. die Gradiationskurve je nach Filmsimulation abgelegt werden, die dann für die jpg Berechnung benutzt werden? Wenn die von einem vorherigen Prozess verändert worden sind, warum auch immer, könnte die nächste Jpg Berechnung schiefgehen. War so ein Gedanke von mir.

Wie der Speicher verwendet wird, wissen wohl nur die Fujifilm Software-Entwickler. Dazu benötigt man internes Wissen der Software.

Generell wird beim Aufruf einer Funktion temporärer Speicher auf dem Stack oder dem Heap allokiert und nach der Verwendung, also beim Verlassen einer Funktion oder auch später wieder freigegeben. Der nächste Funktionsaufruf greift dann wieder auf diesen freigegebenen Speicher zu, etc. In der Regel funktioniert das problemlos. Aus Geschwindigkeitsgründen wird die Firmware sicher in C oder C++ geschrieben sein. Hier kann man auch in Speicherbereiche schreiben, die unzulässig sind, z.B. bei Verwendung eines ungültigen Pointers oder über die Grenzen eines Variablenfeldes hinaus. Da gibt's unendlich viele Möglichkeiten. Bei anderen Sprachen ist das besser gelöst, diese sind aber meist nicht so effizient bzgl. der Ausführungsgeschwindigket. Bei Windows oder anderen Betriebsystemen werden Fehler abgefangen, wenn außerhalb einer gewissen Speichergrenze zugegriffen wird. Innerhalb dieser Grenze kann das Betriebssystem nicht eingreifen, da der Zugriff zunächst einmal in der Hand der Software liegt. Es gibt aber auch Compiler-Fehler oder Fehler in der Hardware. Das kann also eine ganz zufällige Macke sein, die schwer zu finden ist.

Im Klartext heißt das jetzt, die Entwickler von Fujifilm für das Problem sensibilisieren, ab und zu nachfragen und nerven und ansonsten abwarten.

[mjh]

vor einer Stunde schrieb kermit66:

Die JPEG-Entwicklung erfolgt in mehreren Einzelschritten. Das ist sind eine ganze Reihe von Bildmanipulationen. Vielleicht kann man auch einige zusammenfassen, z.B. all diejenigen, die z.B. die Gradation betreffen, also Filmsimulation, Lichter und Schatten. Die meisten werden aber sicher unabhängig voneinander durchlaufen, weil sie nichts miteinander zu tun haben, wie Rauschminderung, Vignettierung und Verzeichnung. Wo ich mir aber sicher bin ist, dass die Zwischenergebnisse nicht nochmal zur Sicherheit im Speicher abgelegt werden. Wenn die Daten einmal verarbeitet wurden, sind die Basisdaten einer Berechnung überflüssig und können gelöscht werden.

Die Zwischenergebnisse werden im RAM gespeichert, und das ist ja nichts anderes als der Puffer, von dem der hybride Bildersucher spricht – oder sagen wir, als Puffer zu dienen ist eine der Aufgaben des dynamischen RAM-Speichers. Aber diese Zwischenschritte bleiben nur so lange gespeichert, bis das nächste Zwischenergebnis berechnet ist; danach werden sie nicht mehr gebraucht und ihr Speicherbereich sollte wieder freigegeben werden. Und wenn mehrere Berechnungen auf Pixelbasis auszuführen sind, werden sie sicher in einem Rutsch ohne Zwischenspeicherung erledigt; dazu gehören fast alle Berechnungen, die sich auf Tonwerte und Farben beziehen. Die Rauschunterdrückung, die Nachschärfung und die „Klarheit“ beispielsweise berechnen aber jedes Output-Pixel auf Basis mehrerer Input-Pixel, was wahrscheinlich erfordert, jeweils ein komplettes Zwischenergebnis aller Pixel zwischenzuspeichern.

Ich halte es ja mittlerweile für wahrscheinlich, dass gerade hier der Fehler liegt: Zwei nebenläufige Prozesse nutzen versehentlich denselben Speicherbereich, so dass der eine Prozess Daten in einen Bereich schreibt, der noch vom anderen Prozess genutzt wird, und die so verfälschten Daten führen dann zu unsinnigen Ergebnissen des zweiten Prozesses. Diese verfälschten Daten müssen wohlgemerkt keine Bilddaten sein; es könnte sich auch um eine anzuwendende Gradationskurve handeln, was dann die sonderbaren Solarisationseffekte erklären würde. So etwas passiert aber nur bei einem bestimmten Timing beider Prozesse, und wenn nur einer der beiden gleichzeitig läuft, tritt der Fehler nicht auf.

Aber hier ist es nun wie in der Medizin: Man kann lange auf die mit verschiedenen bildgebenden Verfahren entstandenen Innenansichten des Patienten starren, aber irgendwann muss man ihn aufschneiden und selbst nachschauen. Das ist der Punkt, an dem wir uns hier befinden, aber wir sind alle keine Chirurgen und haben kein Skalpell. Also: Fuji, übernehmen Sie!

[Tommy43]

Werbung (verschwindet nach Registrierung)

vor 6 Minuten schrieb mjh:

Aber hier ist es nun wie in der Medizin: Man kann lange auf die mit verschiedenen bildgebenden Verfahren entstandenen Innenansichten des Patienten starren, aber irgendwann muss man ihn aufschneiden und selbst nachschauen. Das ist der Punkt, an dem wir uns hier befinden, aber wir sind alle keine Chirurgen und haben kein Skalpell. Also: Fuji, übernehmen Sie!

Warum denke ich an dieser Stelle daran, das hier sicher bald eine Visualisierung von @zoom folgt? 😂 Aber nur die Ruhe, ist kein Auftrag, nur ein Gedanke 😉.

bearbeitet 12. Januar 2023 von Tommy43

[hybriderBildersucher]

vor 23 Minuten schrieb mjh:

Die Zwischenergebnisse werden im RAM gespeichert, und das ist ja nichts anderes als der Puffer, von dem der hybride Bildersucher spricht – oder sagen wir, als Puffer zu dienen ist eine der Aufgaben des dynamischen RAM-Speichers. Aber diese Zwischenschritte bleiben nur so lange gespeichert, bis das nächste Zwischenergebnis berechnet ist; danach werden sie nicht mehr gebraucht und ihr Speicherbereich sollte wieder freigegeben werden. Und wenn mehrere Berechnungen auf Pixelbasis auszuführen sind, werden sie sicher in einem Rutsch ohne Zwischenspeicherung erledigt; dazu gehören fast alle Berechnungen, die sich auf Tonwerte und Farben beziehen. Die Rauschunterdrückung, die Nachschärfung und die „Klarheit“ beispielsweise berechnen aber jedes Output-Pixel auf Basis mehrerer Input-Pixel, was wahrscheinlich erfordert, jeweils ein komplettes Zwischenergebnis aller Pixel zwischenzuspeichern.

Ich halte es ja mittlerweile für wahrscheinlich, dass gerade hier der Fehler liegt: Zwei nebenläufige Prozesse nutzen versehentlich denselben Speicherbereich, so dass der eine Prozess Daten in einen Bereich schreibt, der noch vom anderen Prozess genutzt wird, und die so verfälschten Daten führen dann zu unsinnigen Ergebnissen des zweiten Prozesses. Diese verfälschten Daten müssen wohlgemerkt keine Bilddaten sein; es könnte sich auch um eine anzuwendende Gradationskurve handeln, was dann die sonderbaren Solarisationseffekte erklären würde. So etwas passiert aber nur bei einem bestimmten Timing beider Prozesse, und wenn nur einer der beiden gleichzeitig läuft, tritt der Fehler nicht auf.

Aber hier ist es nun wie in der Medizin: Man kann lange auf die mit verschiedenen bildgebenden Verfahren entstandenen Innenansichten des Patienten starren, aber irgendwann muss man ihn aufschneiden und selbst nachschauen. Das ist der Punkt, an dem wir uns hier befinden, aber wir sind alle keine Chirurgen und haben kein Skalpell. Also: Fuji, übernehmen Sie!

In der Medizin ist es ja mittlerweile so, daß bildgebende Verfahren aus der hochdifferenzierten Vorbereitung komplexer und riskanter Maßnahmen (dazu gehören nicht nur chirurgische Eingriffe, sondern zunehmend auch die moderneren, neuen interventionellen  nicht-invasiven verfahren von früher konservativen Fachbereichen wie Innere Medizin und Radiologie) nicht mehr wegzudenken sind. Und gerade auch intraoperativ (!) werden zunehmend bildgebende Verfahren als imminenter Bestandteil invalider verfahren genutzt. Die Medizin ist also weiter, als Du vermutest. Bspw. werden inzwischen viele OPs mit intraoperativen CT (!!) Verlaufskontrollen und 3-D-Kontrollen radiologisch oder sonografischer Art oder sogar diagnostisch- interventioneller endoskopischer (also optischer) Art geführt. Hightech Medizin ist da viel weiter, als Aussenstehende glauben....

 

[hybriderBildersucher]

@mjhIch verstehe jetzt nicht ganz, was der lachende Smiley zu bedeuten hat....

[mjh]

vor 12 Minuten schrieb hybriderBildersucher:

@mjhIch verstehe jetzt nicht ganz, was der lachende Smiley zu bedeuten hat....

Weil man offenbar jede Analogie kaputt interpretieren kann, wenn man partout will. „Don't bite my finger, look where I'm pointing“ …

[hybriderBildersucher]

vor 1 Minute schrieb mjh:

Weil man offenbar jede Analogie kaputt interpretieren kann, wenn man partout will. „Don't bite my finger, look where I'm pointing“ …

Klar, kann man.... aber es kann auch mal sein, daß man eine ziemlich schräge bis falsche Metapher präsentiert.... wie hier...

egal. ist schon ok...

[Gast]

vor 10 Minuten schrieb mjh:

 „Don't bite my finger, look where I'm pointing“ …

Das sage ich meinen Katzen auch immer, nutzt aber nix .. 😉

[zoom]

vor einer Stunde schrieb Tommy43:

Warum denke ich an dieser Stelle daran, das hier sicher bald eine Visualisierung von @zoom folgt? 😂 Aber nur die Ruhe, ist kein Auftrag, nur ein Gedanke 😉.

Nicht gleich aufschneiden, zuerst auf die neue Firmware (V. 1,30) warten 😉

Hallo, lieber Besucher! Als Forumsmitglied (kostet nix) würdest du hier ein Bild sehen…

Einfach hier registrieren – Wir freuen uns immer über neue Mitglieder!

[kermit66]

vor 3 Stunden schrieb mjh:

Aber hier ist es nun wie in der Medizin: Man kann lange auf die mit verschiedenen bildgebenden Verfahren entstandenen Innenansichten des Patienten starren, aber irgendwann muss man ihn aufschneiden und selbst nachschauen. Das ist der Punkt, an dem wir uns hier befinden, aber wir sind alle keine Chirurgen und haben kein Skalpell. Also: Fuji, übernehmen Sie!

Genau! Spekulieren hilft hier nicht mehr weiter. Jetzt muss der Patient auf den Tisch 😁

[hybriderBildersucher]

vor 14 Stunden schrieb zoom:

Nicht gleich aufschneiden, zuerst auf die neue Firmware (V. 1,30) warten 😉

Hallo, lieber Besucher! Als Forumsmitglied (kostet nix) würdest du hier ein Bild sehen…

Einfach hier registrieren – Wir freuen uns immer über neue Mitglieder!

Am besten  2x tgl. einnehmen lassen...  

[zoom]

...😁

bearbeitet 13. Januar 2023 von zoom

[tomassini]

Der Fuji-Service schweigt beharrlich nach meiner letzten Mail, die Ihnen hoffentlich die "Speicherkartenschuld"-Illusion genommen hat. Und so werte ich das mal als gutes Zeichen!

[Gast]

vor 1 Minute schrieb tomassini:

Der Fuji-Service schweigt beharrlich nach meiner letzten Mail, die Ihnen hoffentlich die "Speicherkartenschuld"-Illusion genommen hat. Und so werte ich das mal als gutes Zeichen!

Bei mir schweigt er auch, nachdem ich meine Konfiguration mit der Bemerkung geschickt hatte, dass die bei einem Forumskollegen unmittelbar zum Fehlerbild führte. 

[Gast]

Am 12.1.2023 um 16:42 schrieb hybriderBildersucher:

 Hightech Medizin ist da viel weiter, als Aussenstehende glauben....

 

... generell dürfen Aussenstehende nicht unterschätzt werden ...

[Gast]

Jetzt hat sich der Fuji Service heute Nachmittag doch gemeldet. Sie konnten den Fehler mit meiner Konfiguration bisher nicht nachstellen, testen aber weiter.

[hybriderBildersucher]

Am 12.1.2023 um 15:02 schrieb Uwe1956:

Gibt es eventuell irgendwo Speicherbereiche, in denen vorher! Parameter für z.B. die Gradiationskurve je nach Filmsimulation abgelegt werden, die dann für die jpg Berechnung benutzt werden? Wenn die von einem vorherigen Prozess verändert worden sind, warum auch immer, könnte die nächste Jpg Berechnung schiefgehen. War so ein Gedanke von mir.

Vielleicht werden ja auch "nur" diverse, Pufferkapazität beanspruchende Daten nach Abschluss der Berechnung nicht wieder freigegeben?

Möglicherweise reicht es ja nicht, nur die ressourcenfressenden Simulationen als Aquire-datei zu nehmen und es müssen noch zusätzlich andere alten Dateien im Puffer ungelöscht herumliegen?  Oder zusätzliche andere Einstellungen an der Kamera als weiterer Risikofaktor dazukommen? Oder nur rbestimmte aw-Dateien, die sich schlechter komprimieren lassen und daher recht hoher Rechenaufwand und hohe Pufferbelegung nötig ist ?

ES scheint ja keineswegs so zu sein, daß der Fehler immer mit den Aquire-Dateien bei jedem Nutzer reproduzierbar ist.... nicht sicher reproduzierbare Fehler sind die absolute Hölle für Diejenigen, die den Fehler suchen....

[Frischmilch]

Manchmal würde es schon helfen man sich und Posts anderer nicht gaanz so wichtig nehmen würde. Auch ohne Smily.

 

 

😉

[Jürgen Flens]

Könntet ihr euch bitte darauf besinnen, dass es hier um Freude an der Fotografie und die Instrumente dazu geht? Meine Güte! Warum müssen immer endlose Debatten um Worte geführt werden. Es reicht doch, wenn die Politik sich daran "erfreut". Danke an @Frischmilch!

[FXF Admin]

Wem @Frischmilchs Beitrag seltsam unmotiviert vorkommt: Ich habe 8 off Topic Beiträge ausgeblendet.

Ansonsten was Jürgen sagt.

Gruß
Andreas

[shodan_f]

Ich nutze meist DR-Auto mit Auto-ISO. Bei Szenen mit großen Helligkeitsunterschieden sollte die Kamera doch automatisch DR200 wählen, verbunden logischerweise mit einem Sprung auf ISO250. So kenne ich das von meiner X-T30 (dort dann natürlich mit ISO320) und so sagt es auch das Handbuch. Nur scheint das bei der X-T5 nicht mehr zu funktionieren. Bei Verwendung von DR-Auto wählt sie niemals DR200, es sei denn, ich wähle manuell ISO320 oder höher oder die ISO-Automatik setzt aufgrund der Belichtung ISO320 oder höher. Das muss ein Bug sein, weil DR-Auto jetzt eben nicht mehr „Auto“ ist. Darüberhinaus wäre für DR200 ja nur ein ISO-Wert von 250 notwendig und nicht 320 wie bei X-Trans IV.

Konkret formuliert – ich fotografiere z.B. einen großen, eher dunklen Baum vor hellem Hintergrund, eigentlich eine typische DR200-Szene. DR-Auto ist eingestellt, folgendes macht die Kamera:

bei Auto-ISO: ISO125 DR100 (d.h. zugunsten eines niedrigeren ISO-Wertes verzichtet die Kamera auf DR200)

bei ISO250: DR100 (obwohl ja eigentlich ausreichend für DR200)

bei ISO320 und höher: plötzlich nutzt die Kamera DR200, wie es eigentlich auch vorher zu erwarten gewesen wäre

Habe ich jetzt ein fehlerhaftes Modell oder zeigen alle X-T5 (und evtl. auch die H2) dieses Verhalten?

[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