Software, um defekte JPG zu erkennen (was zuverlässig funktioniert...)

Hier im Forum gibts schon ähnliche Themen um dieses Thema. Jedoch sind die dort vorgeschlagenen Programm zumeist veraltet (es gibt auch keine neuen Versionen) oder in uferloser Anzahl... Ich habe zwei drei ausprobiert - keine erkannte die fehlerhaften JPGs,die ich dazwischen hatte.

Daher meine Frage, um nicht alles mögliche installieren zu müssen: Kennt jemand aktuelle Software, die zuverlässig defekte JPGs erkennen kann? Es darf auch Geld kosten, muss keine Freeware sein.

Da frage ich mich doch unweigerlich, warum Du etwas gegen ältere Programme hast? Erkennen sie defekte JPGs moderner Kameras nicht oder laufen sie auf Deinem Rechner einfach nicht mehr?

Am JPG-Standard hat sich seit vielen Jahren nichts mehr geändert, was in Sachen defekte Dateien relevant wäre.

Ich habe für solche Aufgaben immer das Kommandozeilentool djpeg (aus der libjpeg, also der Referenzimplementierung der http://www.ijg.org/ ) genutzt. Das ist natürlich nur dann komfortabel, wenn man solche Aufgaben lieber ohne GUI erledigt.

Wenn es unbedingt eine GUI haben muss, würde ich, trotz des Alters, Bad Peggy nehmen
https://www.coderslagoon.com/
oder ein Beispiel-Screenshot
https://superuser.com/questions/276154/automating-the-scanning-of-graphics-files-for-corruption
Vorteil: es gibt den Quelltext und es läft unter WIn, Linux und MacOS
Nachteil: es kann wohl immer nur ein Verzeichnis scannen.

Ein Tool, welches zuverlässig nicht nur strukturelle Fehler (die auch zu optischen Fehlern führen) findet, sondern auch rein optische Fehler, kann es m.M.n. nicht geben. JPG enthält keine Prüfsumme, womit beim Kippen der "falschen" Bits (z.B. wegen HDD- oder Übertragungsfehler) immer eine Datei entstehen kann, die jeder Dekoder zwar irgendwie dekodiert, bei dem aber bei menschlicher Betrachtung (inkl. dem Wissen, was man in dem Bild erwartet) ein 8x8 Block optisch als defekt wahrgenommen wird.

Bis sowas mal per KI korrekt erkant wird, bedarf es wohl noch vieler Jahre.

Was an Deinem Testbid defekt war bzw. wie sich der Defekt in eniem Bildanzeigeprogram äußert, weisst nur Du. Fehler wie in den Beispielen im letzten Link sollten alle Programme erkennen, wenn sie Fehler nicht einfach ignorieren.

GymfanDE schrieb:

Da frage ich mich doch unweigerlich, warum Du etwas gegen ältere Programme hast? Erkennen sie defekte JPGs moderner Kameras nicht oder laufen sie auf Deinem Rechner einfach nicht mehr?

Zum Vergrößern anklicken....

Natürlich habe ich nichts gegen "alte" Software. Sie nützt jedoch nichts, wenn sie sowas nicht erkennt. DAS sollte eine solche Software aber schon erkennen.

JensLPZ schrieb:

Natürlich habe ich nichts gegen "alte" Software. Sie nützt jedoch nichts, wenn sie sowas nicht erkennt. DAS sollte eine solche Software aber schon erkennen.

Zum Vergrößern anklicken....

Wenn sich die JPG Datei so öffnen lässt, dann ist die ja nicht defekt sondern nur der Inhalt. Ob sie das zuverlässig erkennen lässt wage ich zu bezweifeln...
War die Dateien schon mal in Ordnung?

Genau das ist das Problem ... Ein Defekt in einer Jpg Datei führt nicht
zwingend zu einem Problem bei der Dekompression und Anzeige ... du
"siehst" zwar, dass offenkundig etwas nicht in Ordnung ist, aber das
Programm merkt es nicht. ... Beim gezeigten Beispiel ist es durchaus
möglich, dass die Darstellung einer defekten Datei hergenommen wurde,
und erneut als Jpg kodiert wurde (z.B. um überhaupt ein Bild zu haben).
Das neue Jpg ist damit formal zu 100% intakt (auch wenn es einen
augenscheinlich defekten Inhalt zeigt).

Auch andere Defekte können von den Leseroutinen z.T. aufgrund der
in der Datei befindlichen Marker insofern ausgeglichen werden, als das
zumindest wenn die Leseroutine in den Bereich "korrekter" Daten
kommt, sie vernünftig fortsetzen kann. (Letzteres ist ja bei komprimierten
Daten überhaupt nicht immer der Fall).

Fehler in den Metadaten (Exif/Jpg-Comment/IPTC) können in der Regel
nicht detektiert werden.

Es gab doch eine zeitlang diese bekannten magentafarbenen Flächen in Fotos - alles einwandfreie JPGs. Wie soll ein Programm sowas erkennen?

Laut EXIFs ist dies ein Bild, das vom PSE Origanizer erzeugt wurde, es müsste also noch eine Origianldatei dazu geben.

Ähnlich defekte JPGs (die letzte eigenen, die ich habe, sind von 2003) stellt PSE 11 oder IrfanView auch so dar. Dekodiere ich aber die Originaldatei mit dem erwähnten djpeg (oder einer anderen Software, welche die Fehlermeldungen des JPG-Dekoders nicht einfach ignoriert), dann werden dort entsprechende Fehler ausgegeben.

Da hier das Bild nicht vollständig ist, müsste der Dekoder bei der defekten Originaldatei mind. das vorläufige Ende des Bildes erkennen.

Klar ließe sich mit genügend Annahmen auch ohne KI ein solches, inhaltlich defektes Bild erkennen. Aber das wären mit Einschränkungen verbunden, z.B. dass es sich hier um ein reales Bild und nicht um ein vom Computer generiertes handelt. Damit ist es höchst unwahrscheinlich, im unteren Teil eine großen Bereich mit exakt dem selben RGB Wert zu finden. Bei einem computergenerierten Bild ist das aber nicht unwahrscheinlich.

Selbst mit einem kamergenerierten JPG könnte sowas passieren (Nachtaufnahme mit kamerainterner Rauschreduizierung durch ein Dunkelbild). Also muss man als weitere Einschränkung nehmne, dass der einfarbige Bereich nicht schwarz sein darf, um als potentieller Fehler erkannt zu werden.

Jens wenn die Datei sich öffnen lässt ist sie nicht Defekt in dem Sinne wie Du es meinst.
Da Du C1 nutzt ..... ist nicht ganz ungewöhnlich dass C1 so etwas beim Export produziert (GPU Settings)

Okay, Leuts, da definiere ich DEFEKT jetzt so, dass das obige Bild früher fehlerfrei war und später dieses typische JPG Problem aufwies.


Software, die mit einer Art "KI" arbeitet, sollte (natürlich nach dem Einlesen des Bildes) problemlos erkennen, dass da was nicht stimmt. Schließlich werden per KI selbst in "einfachen Programmen" wie Photoshop Elements seit Jahren recht zuverlässig Gesichter und sogar wer das ist, erkannt.

Ja, das Bild war vorher fehlerfrei, aus einem Backup konnte ich es wieder herstellen.

Ich hätte wirklich gedacht, dass da mal eine Firma etwas Gehirnschmalz investiert hatte, der Markt in diesem Bereich schon weiter sei. Schließlich ist der Markt dafür durchaus vorhanden.

JensLPZ schrieb:

Ja, das Bild war vorher fehlerfrei, aus einem Backup konnte ich es wieder herstellen.

Zum Vergrößern anklicken....

Dann liegt ein ganz anderes Problem vor. Dann ist das kein fehlerhaftes JPG, und es wird nie eine "KI" geben, die auf dieser Grundlage Fehler erkennen kann.


Wenn es eine fehlerfreie Kopie des Bildes gibt, dann hat sich was nachträglich an der Ursprungsdatei geändert, und das klingt gar nicht gut. Überprüf mal den Datenträger mit dem Fehler - könnte eine langsam sterbende Festplatte sein.

Manni1 schrieb:

Es gab doch eine zeitlang diese bekannten magentafarbenen Flächen in Fotos - alles einwandfreie JPGs. Wie soll ein Programm sowas erkennen?

Zum Vergrößern anklicken....

Eigentlich ist dann nichts einwandfrei....
Ein JPEG ist segmentiert in 8x8 Makroblöcke Pixel, die mit DCT dann in die Frequenzanteile zerlegt werden und die je nach Kompressionsstärke als Werte abgespeichert werden. Farbkanal getrennt, Makroblock für Makroblock. Wenn es also einzelne Bit- oder Bytekipper in den DCT-Werten gibt, hast du also massiv andere Muster oder Farben, danach ist aber wieder alles in Ordnung. Fehlt jetzt in der Reihe ein Makroblock im Stream kommt es zum Durcheinander, wo im Bild der eigentliche Makroblock hingehört und es ist jetzt nicht mehr klar, ob das jetzt ein Y oder Cb oder Cr-Farbblock ist, also gibt es einen Farbsprung und ab dann ist halt alles lila. Oder grau, weil es völlig fehlt. Das Bild sollte laut Header so und so groß sein, damit ist es vollkommen klar, daß jetzt genau x Makroblöcke kommen müssen, es sind aber nur die Hälfte der Makroblöcke dafür da, also wird der Rest grau gemalt. Der Decoder hat das also schon mitbekommen...
Hier in dem Vogelbild fehlen aber nicht einzelne Werte in den DCT-Werten, wodurch ein Block dann irgendwie komisch aussehen würde (das ist in der Tat schwer zu finden ohne Referenz!), sondern es fehlen zunächst Blöcke in Cb und Cr, später in allen 3 Farbkanälen (die Beine), und dann mit den Füßen ist es wieder in Ordnung.

So die Theorie... KI ist zwar in aller Munde, hier aber nicht nötig.

JensLPZ schrieb:

Ja, das Bild war vorher fehlerfrei, aus einem Backup konnte ich es wieder herstellen.

Zum Vergrößern anklicken....

Hast du das defekte noch? Mich würden beide Varianten mal interessieren...
Haben die Dateien unterschiedliche Grössen?

Hallo Leuts, ja natürlich habe ich sowohl die defekte als auch die originale noch. (Bin halt ein Backup Fan.) Die würde ich bei Bedarf per PM aus meiner Cloud teilen.

Ja, Manni, Du hast natürlich Recht: Sowas deutet normalerweise auf ne sterbende HD hin. (Das ist übrigens auf ner schnellen Class 40 PCIe SSD.) Support habe ich natürlich, kann die ruck zuck tauschen lassen. Ich will das aber mal noch etwas beobachten. Das ganze Windows mit allem hab ich natürlich auch gesichert, ist aber trotzdem schon einiger Aufwand, das alles wiederherzustellen.

Thema JPG:
Ich meine mit KI folgendes: Wenn ich mir das Bild anschaue, erkenne ich sofort den Fehler. Und sowas muss die KI auch können. Ich denke, wenn sie Gesichter in Bildern identifiziert und dort sogar erkennt, WER das ist, sollte das doch eigentlich kein Buch mit sieben Siegeln sein. Sie sollte also das Bild einlesen und sich anschauen und eine solche graue (oder wie bei defekten Speicherkarten) bunte Flächen erkennen - zumindest als verdächtig markieren.

War das jetzt ein zufälliger Fund?
Wenn das jetzt mit der Datensicherung passiert und man die dann weiter spiegelt, dann könnte man die Daten letztendlich doch verlieren.

JensLPZ schrieb:

Ich hätte wirklich gedacht, dass da mal eine Firma etwas Gehirnschmalz investiert hatte, der Markt in diesem Bereich schon weiter sei. Schließlich ist der Markt dafür durchaus vorhanden.

Zum Vergrößern anklicken....

Genau letzeres bezweifele ich. Das defekte Original zu dem Bild kann problemlos ohne KI als Defekt identifiziert werden.

Ich frage mich immer noch, warum bei dem hier hochgeladenen Bildes in den EXIFs der "Elements Organizer 15.0" als Software eingetragen ist. Für mich gibt es dazu nur eine Antwort: die Thumbnail-Size im Organizer ist recht groß eingestellt und das Bild, das Du hier hochgeladen hast, ist nicht das u.U. defekte Original sondern das vom Organizer daraus erzeugte (recht große) Thumbnail.

Oder kann der Orignizer mittlerweile Bilder bearbeiten?

Gnauso, wie die Fettecke von Joseph Beuys für ihn Kunst und für die Putzfrau Müll war, kann bei einem Bild, das sich korrekt dekodieren lässt, kein Automatismus entscheiden, ob de Inhalt korrekt oder falsch ist.

GymfanDE schrieb:

...Ich frage mich immer noch, warum bei dem hier hochgeladenen Bildes in den EXIFs der "Elements Organizer 15.0" als Software eingetragen ist.

Für mich gibt es dazu nur eine Antwort: ....

Zum Vergrößern anklicken....

Deine Antwort war falsch.

Meine RAWs entwickle ich ausschließlich mit C1 (immer aktueller Version), der Feinschliff passiert im Photoshop CC (immer aktuelle Version).

Als Katalog für alle Bilder nutze ich schon seit zig Versionen Adobe Elements. Wenn man dort die Schlagwörter (TAGs) je Bild vergibt und dann die Beschriftung der Bilder samt Schlagwörter in die JPGs schreibt, trägt sich der Elements Organizer 15.0 ein.

Das ist die richtige Antwort.


PS: Wenn Lightroom als Adobe Anwendung alle Schlagwörter des PSE Organizers übernehmen würde, wäre ich dafür schon bei LR. Aber auch die aktuelle LR Abo-Version lässt nach dem Import des PSE Katalogs mehrere Tausend Bilder ohne TAGs. Das ist eine ganz ganz schwache Adobe Leistung.
Andererseits bin ich seit vielen Jahren zufrieden mit dem Elements Organizer. Somit bleibt der Organizer mein Katalog.

Okay, das war jetzt komplett OT.

Jens, eine Frage zum Verständnis.
Der klassige Dateivergleich ist keine Option?

isibitz schrieb:

Jens, eine Frage zum Verständnis.
Der klassige Dateivergleich ist keine Option?

Zum Vergrößern anklicken....

Da müßtest Du schon mit Prüfsummen arbeiten. Der klassische Dateivergleich guckt nur auf die Datum und Dateigröße.

Tänzer schrieb:

Da müßtest Du schon mit Prüfsummen arbeiten. Der klassische Dateivergleich guckt nur auf die Datum und Dateigröße.

Zum Vergrößern anklicken....

Es gibt doch auch Programme, die Binär vergleichen?

Ich stehe jetzt vor dem gleichen Problem. Ich habe am Sonntag aus 5 RAW Dateien die eingebetteten JPG’s extrahiert und angesehen. Alle 5 JPG’s waren in Ordnung. Gestern wollte ich sie mir noch mal ansehen und zwei davon sind beschädigt. Die Daten sind auf einer internen 3TB HDD. Datei Größe und Datum blieb unverändert. Alle aktuellen Bildbetrachtern (IrvanView, FSViewer, Windows Fotoanzeige) öffnen die Bilder ohne Problem. Auch hier rein zufällig entdeckt.


Die oberen zwei Bilder sind die Originalen, die unteren die Defekten. Die roten Kreise habe ich zur Unkenntlichmachung eingefügt.

Seit diesem Beitrag hier rechne ich jetzt auch immer eine Prüfsumme auf meine Datensicherung mit FCIV. Dauert lange und zeigt leider auch nicht an, wann es fertig ist.

Interessant ist, dass mein altes PSP aus 1996 diese Dateien nicht öffnet. Also erkennen kann man die Defekten Bilder schon.

Ich hatte im Dezember schon mal Problem mit der Festplatte. Da konnte ich eine ZIP Datei nicht öffnen und WIN 10 wollte etwas reparieren.

Ich habe dann alle Daten herunter genommen und die Festplatte neu formatiert. Anschließend mit H2testw komplett überprüft. Alles OK. Auch CrystalDiskInfo sagt, das alles gut ist. Ich werde die Platte jetzt wohl doch tauschen müssen.

JensLPZ schrieb:

PS: Wenn Lightroom als Adobe Anwendung alle Schlagwörter des PSE Organizers übernehmen würde, wäre ich dafür schon bei LR. Aber auch die aktuelle LR Abo-Version lässt nach dem Import des PSE Katalogs mehrere Tausend Bilder ohne TAGs. Das ist eine ganz ganz schwache Adobe Leistung.
Andererseits bin ich seit vielen Jahren zufrieden mit dem Elements Organizer. Somit bleibt der Organizer mein Katalog.

Okay, das war jetzt komplett OT.

Zum Vergrößern anklicken....

Gibt es da nicht die Möglichkeit über Xmp Dateien den Transfer zu machen?
Zwischen LR und der Bridge geht es so.
Also im pse die Xmp erzeugen und dann in lr einlesen / importieren.