Just another 5 pence:
Daneben sollte man vielleicht auch noch eines sagen zu dem Thema 'Ich habe ZU VIELE Daten': (also der Plattenplatz, der gebackupt werden muss, explodiert)
Punkt 1:
Man sollte - wenn irgend möglich - nur (1) die Originaldaten aufheben, und evtl. (2) die Zwischen-Daten/Bilder, die SEHR LANGWIERIGES + KOMPLEXES Processing in sich tragen (nenn ich mal: 'aufwendige Zwischendaten'). Und natürlich (3) die (near-)Final-Daten, also Endresultate. PLUS noch etwas in Punkt 2 beschriebene, s.u. ...
(OK, das dürfte den meisten klar gewesen sein, aber s.u. ... )
Das blinde Abspeichern von ALLEM, was man jemals beim Processing erzeugt hat (blind, das komplettes Work-Dir mit allem 'Mist') , führt natürlich zu extremer Datenflut.
(Ich weiss ihr macht z.T. Videos, das ist übel, ja !)
Punkt 2:
Wenn man eine Bildverarbeitungs-Software verwendet, die SKRIPTING-fähig ist, dann kann man alle Zwischendaten immer wieder relativ schnell re-erzeugen (aus den Originaldaten, oder den oben erwähnten aufwendigen Zwischendaten), falls nötig. Bzw. alle Schritte sind damit maschinell (!) reproduzierbar. Skripting heisst also: ich mache (praktisch) NICHTS (keinen Befehl) mit der Hand, sondern alles nur durch Aufrufen eines Skripts, in dem die Befehle die ich ausführe (sozusagen) aufnotiert sind. Die bereits verarbeiteten Schritte werden dann immer auskommentiert, und nur die neu anstehenden Schritte werden beim erneuten Aufruf des Skripts exekutiert. Das finale GesamtSkript ist also wie eine Art 'Log' der exekutierten Befehle, der aber also solcher insgesamt (blind) ausführbar ist.
ESO-MIDAS ist z.B. so eine Software, die das kann (sie ist allerdings nur für CCD-Daten ausgelegt, NICHT für Bayer-Matrix-Daten und Videos, jedenfalls Stand Jahr 2000). (Was sonst hier verwendet wird, weiss/kenn ich nicht, sorry.) Ich schätze aber, dass vernünftige Software normalerweise skripten kann (führt keine grosse Komplexität ein in die Architektur der Software, wenn sie schlau gebaut ist - da ein Interpreter sowieso einen eingegebenen Befehl parsen muss, also kann er auch den Skript-Content parsen + exekutieren).
UND NATÜRLICH:
hebt man DANN (4) das finale Skript auch auf - ist ja 'wertvoll wie Gold', wegen der vielen Arbeit, die da drin steckt.
So kann man insgesamt zumindest versuchen, die Datenflut besser zu MANAGEN.
Klar: man muss immer noch (device-redundante & orts-redundante) Backups haben. Daran ändern meine Punkte gar nichts ! (Nur die Menge wird vielleicht handhabbarer)
Natürlich: die Datenflut (Videos, kurze Belichtungszeiten, Stacking) ist ohnehin sehr gross, gar keine Frage. Das ist definitiv ein Thema für jeden, der Bildverarbeitung macht.
Gruss,
Peter