Archivfestigkeit 500 Jahre!!!

[matadoerle]

Werbung (verschwindet nach Registrierung)

Hallo,

herzlichen Dank für die tiefer gehenden Informationen. Wenn ich mir anschaue, was es da so gibt dann wäre doch DNG, Version 1.3 unkomprimiert mit ca. 25 MB ein gutes Format?

Eaxkt 2 Bytes pro Pixel plus TAG Overhead und Vorschau.

 

Oder welchen Vorteil bringen die dreifachen 75 MB dieses Formats bei der Archivierung?

Das ist ein lineares DNG mit lossless JPG komprimiert, das kann jede Version.Egal ob low oder high, 12 Megapixel zu je 2 Byte pro Farbpixel gibt 2x3x12=72.

 

Nochmals als Frage, ob ich das jetzt richtig verstanden habe. TIFF ist zwar nett, hat aber eigentlich keinen Standard-Charakter; DNG nutzt die gleichen Verfahren wie TIFF, beschränkt sich aber auf bestimmte Standards und wäre vorzuziehen?

 

Zu deiner letzten Ausführung:

Ja, das begann mit Version 1.2 und wurde in Version 1.3 sogut wie perfektioniert.Soviel ich weiß, verwendet C1 diese Korrektur-Metadaten (siehe dein Baustellenbild) und natürlich alles, was von Adobe kommt. SilkyPix kann als einziger (?) RAW-Konverter diese Korrekturdaten direkt aus den Panasonic-RAW Dateien interpretieren.

Mein CaptureONE 5.2 kann weder DNG lesen noch erzeugen (auch wenn es die Anwahl als Ausgabeformat erlaubt - Fehlermeldung!).

Silkypix Developer Studio 4.0 kann das DNG Version 1.3 NICHT korrekt interpretieren, weil es die TAGs wohl nicht verarbeitet ..

 

EDV, IT und Konsorten sind alles Vollidioten (ich darf das sagen, weil ich meine Kollegen zu gut kenne) .. ich gehe jetzt und mache Fotos.

Gruß Thorsten

[Zitterhuck]

TIFF ist zwar nett, hat aber eigentlich keinen Standard-Charakter...

 

Das stimmt aus Archiv-Sicht nicht, hier ist es der Standard.

 

Mein CaptureONE 5.2 kann weder DNG lesen noch erzeugen (auch wenn es die Anwahl als Ausgabeformat erlaubt - Fehlermeldung!).

Silkypix Developer Studio 4.0 kann das DNG Version 1.3 NICHT korrekt interpretieren, weil es die TAGs wohl nicht verarbeitet...

 

Na, siehst Du? Das sagt doch alles...

[isaac]

Hallo Thorsten!

dann wäre doch DNG, Version 1.3 unkomprimiert mit ca. 25 MB ein gutes Format?

Ja, aber lass dich bitte nicht auf die DNG Versionsangabe ein. Einfach mit dieser Einstellung:

 

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

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

 

Oder welchen Vorteil bringen die dreifachen 75 MB dieses Formats bei der Archivierung?

Der Vorteil (?) liegt darin, daß schon das Demosaicing gemacht wurde und auch die kamerainternen Ausbesserungsarbeiten vom DNG Konverter durchgeführt worden sind. Alles was noch notwendig ist, sind Schwarz- und Weißpunkt sowie Farbraum.

 

Nochmals als Frage, ob ich das jetzt richtig verstanden habe. TIFF ist zwar nett, hat aber eigentlich keinen Standard-Charakter; DNG nutzt die gleichen Verfahren wie TIFF, beschränkt sich aber auf bestimmte Standards und wäre vorzuziehen?

Standard (Norm) ist, wenn es durch ein autorisiertes Gremium nach Anhörung der "Öffentlichkeit" beschlossen worden ist. Alles andere sind mehr oder weniger Konventionen zwischen einzelnen Firmen oder Interessensgemeinschaften. Für TIFF zu finden unter ISO 12639:2004 - Graphic technology -- Prepress digital data exchange -- Tag image file format for image technology (TIFF/IT) und für JPG unter anderem bei http://www.jpeg.org/public/wg1n1807.txt.

DNG ist (noch) nicht genormt daher also nur eine Art Konvention zur Erweiterung der TIFF - Tags.

 

Zu deiner letzten Ausführung:

 

Mein CaptureONE 5.2 kann weder DNG lesen noch erzeugen (auch wenn es die Anwahl als Ausgabeformat erlaubt - Fehlermeldung!).

Schau, daß du dir wieder die 5.1.x Version von der Heft-CD installierst. Die neue 5.2er ist ein wenig, nun sagen wir, merkwürdig...

Aber DNG können sie alle, allerdings kein "linear".

Silkypix Developer Studio 4.0 kann das DNG Version 1.3 NICHT korrekt interpretieren, weil es die TAGs wohl nicht verarbeitet ..

SilkyPix wird wohl auf den Adobe Lossless Bug bestehen :-)

[isaac]

Hallo!

Zitat von matadoerle

Mein CaptureONE 5.2 kann weder DNG lesen noch erzeugen (auch wenn es die Anwahl als Ausgabeformat erlaubt - Fehlermeldung!).

Silkypix Developer Studio 4.0 kann das DNG Version 1.3 NICHT korrekt interpretieren, weil es die TAGs wohl nicht verarbeitet...

 

 

Na, siehst Du? Das sagt doch alles...

Sagt in diesem Fall nur was über den Schreiber der obigen Zeilen :-)

[matadoerle]

SilkyPix wird wohl auf den Adobe Lossless Bug bestehen :-)

Nein, ich habe mich wahrscheinlich nicht gut ausgedrückt: Silkypix liest die dateien anstandlos, Farben etc. ist alles o.k. - aber die Objektivkorrekturen (Verzeichnung und Chromatische Aberration) greifen nicht automatisch.

[isaac]

Hallo Thorsten!

Nein, ich habe mich wahrscheinlich nicht gut ausgedrückt: Silkypix liest die dateien anstandlos, Farben etc. ist alles o.k. - aber die Objektivkorrekturen (Verzeichnung und Chromatische Aberration) greifen nicht automatisch.

Dann kann SilkyPix wohl DNG, aber nicht die neueste Version 1.3

Das ist aber kein Fehler von DNG, sondern von SilkyPix.

[winniefoto]

Werbung (verschwindet nach Registrierung)

Die sehr interessante Diskussion der Archivtauglichkeit diverser Formate scheint vorerst zu einem Ruhepunkt gelangt zu sein, so dass ich ohne zu unterbrechen den Fokus auf den Datenbestand als solchen lenken kann.

 

Wenn ich es richtig verstanden habe, sind insbesondere Daten in einem komprimierten Format ab einem "Umfaller" nicht mehr lesbar. Ich denke, dass darunter ein Bit zu verstehen ist, dessen Wert weshalb auch immer ins Gegenteil vertauscht ist.

Was ist nun der beste Weg, solche Dateifehler zu identifizieren. Ich sichere auf etlichen externen Festplatten. Wie kann man feststellen, ob die Dateien auf zwei zu vergleichenden Bit für Bit identisch sind? Und bei Unterschieden, welches die intakte Datei ist?

Oder ist es trivial, dass die Datei einfach nicht mehr öffenbar ist?

[Anzeige]

Ich würde dir das Adobe Creative Cloud Foto-Abo mit Photoshop und Lightroom empfehlen

[Zitterhuck]

Ehrlich gesagt, ich habe keine Ahnung, wie man solche korrupten Files identifizieren könnte. Ich hatte vor Zeiten mal so ein Problem, weil mir eine SW offensichtlich Files beschädigt hatte, die man allerdings durch Laden und neu speichern in PS wieder herstellen konnte. Ich hätte jedenfalls gerne ein Tool, mit dem man Bilder-Files, möglichst im Batch-Modus überprüfen könnte, der damalige Wunsch danach hat allerdings zu keinem Such-Ergebnis geführt...

[isaac]

Hallo!

Wenn ich es richtig verstanden habe, sind insbesondere Daten in einem komprimierten Format ab einem "Umfaller" nicht mehr lesbar. Ich denke, dass darunter ein Bit zu verstehen ist, dessen Wert weshalb auch immer ins Gegenteil vertauscht ist.

Ja, so kannst du das verstehen. Warum ein Bit umfällt, kann viele Gründe haben...

Was ist nun der beste Weg, solche Dateifehler zu identifizieren.

Das macht schon die Festplatte für dich. Je nach Festplatte werden einige wenige fehlerhafte Bits durch eine interne Fehlerkorrektur beseitigt, ab einer gewissen Anzahl von Fehlern liefert die Platte einfach den gewünschten Sektor nicht mehr und ist ein Fall für den Müll oder einen (professionellen Datenretter).

Ich sichere auf etlichen externen Festplatten. Wie kann man feststellen, ob die Dateien auf zwei zu vergleichenden Bit für Bit identisch sind? Und bei Unterschieden, welches die intakte Datei ist?

Wie gesagt, die Platte liefert entweder absolut korrekte Daten oder garkeine.

Wenn die Platte keine Daten liefert, dann kann der Sektor als kaputt betrachtet werden. Dennoch kann man mit spezieller Hard- und Software die Daten aus diesem Sektor noch rekonstruieren, aber welches Bit und in welchem Byte beschädigt war, ist leider nicht mehr feststellbar.

Wenn aber in diesem Sektor nur unkomprimierte Bilddaten sind, dann kann man diese ja visuell begutachten (also diesen Sektor logisch zu den restlichen Sektoren der Bilddatei dazugeben).

Bei einem unkomprimierten Bild wird man wahrscheinlich garnichts bemerken, weil die Bildumgebung um das tote Pixel den Fehler visuell verschwinden läßt (das ist vergleichbar mit toten Pixeln auf einem Monitor oder einem Sensor).

In einer komprimierten Bilddatei sind aber nicht einzelne Pixel abgespeichert, sondern nur eine Bit- oder Bytefolge zu deren Rekonstruktion. Weil aber jedes Folge Bit/Byte genau die ursprüngliche Information aus dem vorherigen Byte braucht, gelingt die Rekonstruktion nicht mehr.

Man könnte jetzt zwar feststellen, welches Bit/Byte den visuellen Fehler verursacht hat und durch Probieren versuchen, wieder den korrekten Wert vorzulegen. Das kann gehen, muß aber nicht gehen.

Man müßte praktisch die Bilddatei bitweise mitloggen und hoffen, daß man anhand des Bitmusters und dem dazugehörigen Algorithmus exakt das richtige Byte erkennt.

Sowas macht man bei einer Faxübermittlung ohne Fehlerkorrektur, weil man weiß, daß gewisse Werte einfach nicht vorkommen dürfen, aber auch da ist es nicht 100%ig sicher und die Software sucht dann halt den nächsten Zeilenbeginn, der aber dann auch die übernächste oder die x-ten Folgezeile sein kann.

Oder ist es trivial, dass die Datei einfach nicht mehr öffenbar ist?

Ja, so ist es, wenn du keine Spezialsoftware dafür hast.

[fax]

Wenn ich es richtig verstanden habe, sind insbesondere Daten in einem komprimierten Format ab einem "Umfaller" nicht mehr lesbar. Ich denke, dass darunter ein Bit zu verstehen ist, dessen Wert weshalb auch immer ins Gegenteil vertauscht ist.

Ja, so kannst du das verstehen.

Viele Kompressionsalgorithmen teilen die Daten in Blöcke auf. Somit bleiben die meisten Daten erhalten, wenn nur ein Block beschädigt ist. Das gilt m.W. auch für JPEG.

 

Wie gesagt, die Platte liefert entweder absolut korrekte Daten oder garkeine.

In der professionellen Datentechnik, bei der Terabytes an Daten täglich umgeschaufelt werden, ist es nicht unüblich, dass einzelne Bits auf dem Weg zum Speichersystem umkippen. Deswegen wird in großen Servern fast ausschließlich RAM mit Hardwareprüfsummen (ECC) verwendet und Dateisysteme mit Prüfsummen (z.B. ZFS).

[winniefoto]

... nach wie vor ist es sehr interessant! Vielen Dank, isaac unf fax.

 

@isaac:

Bzgl. der Intaktheit des Datenbestandes könnte man also folgern: Wenn Archivierung auf lange Sicht in jpeg nicht ratsam ist, hat kurzfristig gesehen jpeg die vorteilshafte Eigenschaft, dass ale jpegs, die geöffnet werden können, 1 zu 1 dem Original entsprechen. Ein Bit-zu-Bit-Vergleich erübrigt sich also. Richtige Folgerung?

Obwohl ich gestehen muss, dass mein erster Gedanke beim Lesen war, dass dies für Festplatten und die Intaktheit von Sektoren gelten mag. Ein beim Kopieren bspw. umgekipptes Bit aber so nicht erkennbar oder gar von Fetplatte per Fehlerkorrektur repariert werden kann.

 

@fax:

Die Blockaufteilung ist ein interessanter Hinweis. Ist in jpeg eigentlich auch ein Vorschaubild integriert? Das würde bedeuten, dass man um die Öffenbarkeit zu prüfen tatsächlich die Datei öffnen müsste, anstatt sich auf die Übersicht des Dateibrowsers zu verlassen.

 

Gibt es Prüfsummen-Dateisysteme auch für unsereins Privatverwender?

[fax]

Gibt es Prüfsummen-Dateisysteme auch für unsereins Privatverwender?

ZFS gibt es auch z.B. für Linux und Mac OS X, wird allerdings nicht offiziell davon unterstützt und die Einbindung ist ziemlich haarig und ineffizient. Zur langfristigen Archivierung eignen sich solche Dateisysteme vermutlich ohnehin nicht besonders gut, weil sie nicht so weit verbreitet sind. ZFS hat allerdings den Vorteil gegenüber anderen kommerziellen Dateisystemen wie Veritas, dass der Quellcode offen verfügbar ist. Eine Methode um Datenübertragungsfehler mit FAT auszuschließen, ist mir leider nicht bekannt. Selbst RAIDs helfen wenig, wenn das Bit davor schon gekippt ist.

[Zitterhuck]

@fax: Kennst Du den so ein von mir gewünschtes Tool zur Integritätsprüfung?

[fax]

Nein, ich wüsste auch nicht, wie man das implementieren sollte, ohne Prüfsummen an einer anderen Stelle abgelegt zu haben. Für die Prüfsummenerstellung und Prüfung gibt es allerdings Werkzeuge. Da googelt man am besten nach MD5.

[Anzeige]

Guck dir auch mal das Sony 12-24 G Master an

[immodoc]

Hi,

 

anregende Lektüre zu dem Thema:

 

The 500 year archive ? The Register

 

von immodoc. Viel Spaß beim Lesen!

[Zitterhuck]

Nein, ich wüsste auch nicht, wie man das implementieren sollte, ohne Prüfsummen an einer anderen Stelle abgelegt zu haben. Für die Prüfsummenerstellung und Prüfung gibt es allerdings Werkzeuge. Da googelt man am besten nach MD5.

 

Nun gut, schade. Was ich nicht verstehe: PS meckert ein zu ladendes Foto an, wenn es Integritätsprobleme gibt. Den Hintegrund müsste man kennen und dann könnte es doch ein Tool geben, der eben solche Files sucht, oder? Mehr will ich ja gar nicht und ich bin mir auch nicht sicher, ob das was mit dem OS und seinem Filesystem zu tun hat...

[winniefoto]

Um Dateien auf ihre Bit-für-Bit-Übereinstimmung zu testen, verwende ich gerade das freeware-Programm Anti-Twin. So kann ich feststellen, ob bei der Erstellung der Kopie auf der USB-Platte ein Fehler entstanden ist. Darüber hinaus, ob sich später eine Abweichung ergeben hat. Innerhalb der Ergebnisse lässt sich nach Ordnern auswählen, was sehr hilfreich ist.

Dies zu meinen Bestrebungen, mit einfachen Bordmitteln die Datenübereinstimmung zu testen.

Anregungen oder Anmerkungen sind sehr willkommen!

[Zitterhuck]

Das scheint mir eine nicht unwichtige Option für ein Backup zu sein, mein Problem löst es nicht, da es nicht auf OS-Ebene besteht... Trotzdem Danke!

[rotfl_de]

...Ich hätte jedenfalls gerne ein Tool, mit dem man Bilder-Files, möglichst im Batch-Modus überprüfen könnte...

 

ich hab durch zufall grad wieder diesen beitrag entdeckt.

 

um einen binärvergleich von quell- und zieldateien unter windows im batch durchzuführen, fallen mir zwei programme ein:

 

- wintwins (freeware, uralt, ob das unter win7 noch läuft?)

- ZTreeWin

 

mit ZTreeWin v1.49 habe ich gerade ein komlettes bilderverzeichnis binär verglichen. funktioniert demnach unter win7 64bit.

 

ZTreeWin kann man bei ZTreeWin File Manager (XTree compatible) runterladen.

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

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

[Zitterhuck]

Danke für Deine Mühe! ich bin mir aber noch nicht einmal sicher, ob die binäre Integrität das Problem ist. Das kann auch ein CS internes Problem sein...

[systemcam128]

Prozesskette: Aufnahme unter kalibrierten Bedingungen mit digitaler Kamera und Ausbelichten auf speziellen Farbfilm per Laserbelichter. Haltbarkeit: 500 Jahre.

Und schon nach 100 Jahren stellt man dann fest das die Filme hinüber sind aber es die Firma nicht mehr gibt die man verklagen könnte.

Filme sind sowieso das allerschlechteste Mittel ein Brand und alles ist weg. Viel besser sind verlustfrei Digitalkopien. Medium ist egal Hauptsache redundant und verteilt und alle par Jahre umkopiert. Das hält mit minimalem Aufwand für die Ewigkeit.

[Anzeige]

Viele User im Forum fanden auch die Lumix GH5 interessant

[H.P]

eine Firma die heute ein Entwicklungsgerät für den Amateurbereich bereit stellen würde, die digitale Daten der Kamera ausließt und auf Meterware von Diafilm belichten würde............wäre ein Segen und eine riesige Marktlücke,Filmfabriken würden auch wieder profitieren und der Analog Bereich wäre auch glücklich Ich sollte dies patentieren lassen

 

Das wäre mein Traum und wer mit dem Argument kommt,wenn ein Brand wäre ist auch alles futsch ist nicht nur ein bißchen gaga,sondern er sollte morgens gar nicht aus der Haustüre treten..............es könnte ihm ja auch ein Backstein auf den Kopf fallen und er wüßte dann nicht einmal mehr, daß man ja zwei Filme machen könnte und an 2 verschiedenen Lagerplätzen sicher aufbewahren

[systemcam128]

treten..............es könnte ihm ja auch ein Backstein auf den Kopf fallen und er wüßte dann nicht einmal mehr, daß man ja zwei Filme machen könnte und an 2 verschiedenen Lagerplätzen sicher aufbewahren

 

Auch zwei Lagerplätze können abbrennen und der Aufwand für die verlustbehafteten Kopien den man bei richtig großen Datenbeständen treiben müsste wäre viel zu hoch im Vergleich zu digitalen Kopien.

[matadoerle]

nur dass es viel einfacher ist, ein Filmlager vor Brand und Hochwasser zu schützen als eine Festplattenbatterie - letztere muß ständig mit Strom versorgt, aufwändig gekühlt und elektrisch abgesichert werden; hat also "geringfügig" höhere Betriebskosten, während erstere in jedem Keller mit einmaligem Aufwand (Aufbewahrungsbox) problemlos zu "installieren" ist .. alle mir bekannten Archive, die Dokumente unverändert - also authentisch - bewahren wollen, arbeiten aus guten Gründen mit Film. Das ändert nichts an der Tatsache, daß ein Festplattenarray natürlich auch eine denkbar gute Lösung darstellen kann

[systemcam128]

Festplatten behalten ihre Informationen auch ohne Strom wenn es nur ums archivieren geht. Auf Magnetbändern lassen sich außerdem die Daten davon mit hohen Transferraten auslagern. Und nichts ist authentischer als eine digitale 1:1 Kopie zumal die meisten Daten heute sowieso in digitaler Form anfallen. Ein analog kopierter Film wird niemals exakt gleich aussehen auch wenn man die Unterschiede vielleicht vernachlässigen kann.