Picture processing auf Mango

Bilder von Objekten werden für interne Verwendung aber auch webpräsenz gröber gerechnet und mit einem SMNS Copyright versehen. Die Bilder kommen auf einem Linux Rechner innerhalb des Museums an und sind stehen der Verarbeitung unter Erhalt der vorgebenen Verzeichnisstruktur in einem Windows share im Museums Intranet zum Lesen bereit. Dabei gibt es zwei Betriebsweisen, bei der älteren Methode wird eine Live Dateistruktur als input verwendet und prozessiert. Bei der verallgemeinerten neueren Methods wird ein differentieller Update zu einer internen Liveversion kopiert (sync-ähnlich) wobei geänderte Pfadnamen oder Fileinhalte nicht gelöscht, sondern als `shelved` content erhalten bleiben und dann die Bildverarbeitung durchgeführt. Man kann aber das Archivieren/Updaten einerseits und die Bildverarbeitung andererseits unabhängig verwenden. Im folgenden konzentrieren wir uns auf den differentiellen Update mit Bildverarbeitung.

Ein Verzeichnis (z.B. `house`) mit neuen Bilder eines Projekts in einem namentlichen können mit winscp, filezilla oder sscp wird auf das Verzeichnis /home/robot/difdes Linux servers kopiert. Dieses darf noch kein Unterverzeichnis `house`, andernfalls deutet seine Existenz [ in der dif-Struktur] NICHT-prozessierte Bilder eines früheren `house`-updates enthalten. Das dif Verzeichnis kann aber andere Unterverzeichnisse enthalten. Die bisherigen Bilder des house Projekts sind in /home/robot/merge/house enthalten.Die Daten von dif/house dürfen neue Bilder sein, Bilder mit geändertem Inhalt aber gleichem Pfad und Namen wie die alten oder Bilder identischem Inhalt aber geändertem Pfad oder Namen, also auch eine komplette Umstrukturierung des house Verzeichnisses ist damit möglich und wird vom update Prozess erkannt und zugeordnet.

Man startet das script difmerge.pl in dem Projektverzeichnis (oder auch house)cd /home/robot/dif/house difmerge.plDas Script ergänzt dann das Verzeichnis /home/robot/merge/house mit den differentiellen Daten, wobei alle Umbenennungen und Inhaltliche Änderungen im merge Zweig ausgeführt werden, wobei allerdings die geänderten Files nicht gelöscht werdensondern in das shelve directory, das mit dem Prozess Zeitpunkt benannt wird.Ähnliches passiert mit umbenannten Files, diese sind dann in dem del directory gespeichert, hier ebenfalls mit Datum gekennzeichnet. Es ist sinnvoll das del verzeichnis eher als das shelve directory zu löschen, man kann aber auch beide sofort löschen.

Die Bildverarbeitung t1.pl wird im Houseverzeichmis des Projekts ohne weitere Arguments auf der Kommandozeile gestartetcd /home/robot/merge/house t1.pl Darin gibt die Zahl 1 das Transformationsprogramm `1` an.Die transformierten Bilder entstehen dann in dem Verzeichnis/home/robot/out/1/house.Das Prgramm imageMagick verarbeitet die inputdaten unter zu Hilfenahme eines Direktories /home/robot/tmp/house

Der linux user robot ist Besitzer von Programmen und Datenstrukturen beider Methoden und aller Häuser. Ein Haus ist eine logische Datenstruktur auf die bei Eingaben, Transformation und Ausgaben zugegriffen wird. Ohne Beschränkung bezeichnen wir ein solches mit dem string house. Verschieden Datenprojekte oder Versionen können so auseinandergehalten werden. Die Wurzeln für Häuser des differentiellen Updates sind /home/robot/dif /house/home/robot/merge/house und die Prozessergebnisse von umbenannten oder veränderten Files /home/robot/shelve2018-12-31/house /home/robot/del2018-12-31/house.

Im Verzeichnis /home/robot/bakListings finden sich zu jedem Haus und jedem Prozesslauf ein Menge an Files, die die erkannten Veränderungen in den live/merge Verzeichnissen festhalten, sowie ein SQL Strom der Datenbankeinträge beginnend mit `fsql…`.Diese Files sind zum incrementellen update der log table gedacht, falls man in der log table nach Dateiveränderungen recherchieren will. Man kann die fsql files auch zunäachst ignorieren und falls benötigt erst dann sämtlich in einem Aufruf in eine leere log table einlesen mysql –u tuet –p arcan <fsql*.sqlBei mit Datum versehenen Benennungen der fsql Dateien, geschieht die Ausführung der SQL Streams in korrekter Weise.

CREATE DATABASE arcan 
CHARACTER SET utf8 
COLLATE utf8_unicode_ci; 
CREATE USER `tuet`@`localhost` identified by <password>; 
GRANT ALL PRIVILEGES ON arcan.* TO 'tuet';

USE arcan;

--
-- mainly for differential updates (difmerge.pl)
-- 
CREATE TABLE `procs` (
   `id` int(11) NOT NULL AUTO_INCREMENT,
   `date` datetime DEFAULT NULL,
   `status` char(1) DEFAULT NULL,   
   `house` text,   
   `path` text,   
   `name` text,  
   `size` bigint(20) DEFAULT NULL,   
   `modify` datetime DEFAULT NULL,   
   `version` int(11) DEFAULT NULL,   
   `sha256` char(64) DEFAULT NULL,   
   `identifier` text,   
   PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=74 DEFAULT CHARSET=utf8; 

-- 
-- pic tranformations processing (for executing t<num>.pl, eg, t1.pl) 
-- 
CREATE TABLE `picproc` (
   `id` int(11) NOT NULL AUTO_INCREMENT,   
   `house` text NOT NULL,   `protocol` text NOT NULL,   
   `date` datetime DEFAULT NULL,   
   PRIMARY KEY (`id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 
   
-- 
-- optional log database 
-- 

CREATE TABLE `logs` (
   `id` int(11) NOT NULL AUTO_INCREMENT,   
   `date` datetime DEFAULT NULL,   
   `fsql` text, 
  `comment` text,   
  PRIMARY KEY (`id`) 
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8; 

-- 
-- older processing for script arci.pl 
-- 
CREATE TABLE `tree` (
   `id` int(11) NOT NULL AUTO_INCREMENT,   
   `date` datetime DEFAULT NULL,   
   `sha256` char(64) NOT NULL,   
   `version` int(11) NOT NULL,   
   `status` char(1) DEFAULT NULL,   
   `house` text NOT NULL,   
   `path` text,   
   `name` text,   
   `size` bigint(20) DEFAULT NULL,   
   PRIMARY KEY (`id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8;