das 'touch' programm fuehrt zu einer automatischen herstellung einer neuen layout datei, so als waere die highres datei auf dem volume neu abgespeichert worden. wo finde ich eine dokumentation zu fragen wie: welche parameter werden bei der automatischen layout herstellung verwendet? wie werden diese parameter grundsaetzlich veraendert? wie werden diese parameter situations bedingt veraendert?
waere die scriptserver/ hotfolder kombination die einzige moeglichkeit zur situations bedingten einstellung?
oder, wie liesse sich die erstellung einer layout datei eines vector .eps grundsaetzlich vermeiden? denn original datei <= layout datei ! ein auf command line ausgefuehrter 'layout' command wuerde wohl die parameter: -o EpsKeepSize <double:10.0> oder -n <boolean:TRUE> (opposite to -N) benutzen.
Falls Du das Mac-Programm "Touch" meinst... das macht genau das. Es liest das erste Byte der Datei und schreibt es anschl. wieder. Dadurch entsteht auf dem Server ein sog. "close"-Event und damit wird die Grobbild-Generierung erneut automatisch getriggert.
Bei den Helios-Kommandozeilenwerkzeugen gibt es dann noch "opitouch", das solche "close"-Events direkt erzeugen kann (dabei wird dann auch nicht das Modifikationsdatum der Datei geändert). Seit Update u0526 (http://www.helios.de/...ebrowser.phtml?u0526 geht alternativ bei den DT-Utilities auch ein "-E", um diese File-Events zu erzeugen. Ein "dt touch -E" entspräche damit dem "Touch" vom Mac aus, weil auch das Modifikationsdatum angepaßt wird)
Es gibt globale und Volume-spezifische Parameter (letztere "eigentlich nur" Grobbild-Generierung ein/aus), siehe Kapitel 4 im IS-Manual.
Die Settings, die man im HELIOS Admin vornimmt, spiegeln sich in Preferences des Helios-Systems wider, siehe Kapitel
Dann gibt es Ordnernamenskonventionen, die die Layout-Generierung steuern, siehe Kapitel 5.3 im IS-Manual.
Achtung: Man kann diese Ordnernamenskonventionen auch für ganze Volumes einsetzen, indem man den Pfad zum Volume bereits passend präpariert (d.h. wenn ich /data/bilder freigeben will aber dort JPEG-Grobbilder in RGB mit 144 dpi haben will, dann benenne ich den Pfad unter Unix um in /data/bilder%144rj und gebe den dann als "Bilder" frei. Achtung: Sowas niemals mit einem bereits existierenden Volume machen, weil anschl. alle Grobbilder auf dem Volume auf nicht mehr existente Feinbilder zeigen)
Was verstehst Du unter "situationsbedingt"? Du willst individuelle Parameter für die automatische Grobbildgenerierung verwenden? Mehr als die Ordnernamenskonventionen gibt es meines Wissens nach nicht.
Naja, vektor-basierte EPS-Dateien (bzw. ganz generell keine "Photoshop-EPS") können beliebigen PostScript-Code enthalten (PostScript kennt ja auch Programmkonstrukte, siehe bspw. dieses EPS, das beliebig komplexe Fraktale zeichnen kann: http://users.phg-online.de/...ages/fraktal.eps.sit), von daher kann der ImageServer eigentlich nichts weiter machen, als diese 1:1 ins Grobbild einzubetten und noch zusätzlich eben die OPI-Kommentare hinzuzufügen. Solche EPS-Grobbilder können naturgemäß nicht kleiner sein als die dazu passenden Feinbilder.
Wünschenswert wäre ein Schalter, um deren Erzeugung ggf. zu unterdrücken.
Ein manuelles layout-Kommando hat nur bedingt was mit den Settings für die Automatismen zu tun, die man wie weiter oben beschrieben, konfigurieren kann. Die default-Settings von layout erhältst Du per
bzw.
Aber auch hier besteht dasselbe "Problem", wie mit einem vektorisierten Feinbild-EPS zu verfahren ist. Idealerweise skriptest Du Dir eine Erkennung und läßt diese Grobbilder dann gar nicht erst erzeugen bzw. löscht sie automatisiert wieder.
kann mir wer eine idee geben, wie die erzeugung einer layout datei von einer high-res datei < 5 mb generell vermieden werden koennte?
ein zweites problem bekomme ich nicht geloest:
es soll auf einem HELIOS volume, auf dem die erstellung von .lay dateien aktiviert ist, zwischen dateitypen unterschieden werden, sodass z.b. eine .jpg mit einem anderen [layout] befehl bearbeitet werden kann als eine .psd datei. macht es sinn mit hotfoldern auf den entsprechend aktivierten volumes zu arbeiten?
Helios bietet dazu die Präferenz "MinLayoutSize". Damit kann man einstellen, wie groß eine Layoutdatei sein muss, damit sie erzeugt wird. Es stellt sich aber die Frage, ob eine solche Steuerung sinnvoll ist, da die Anwender dann unter Umständen in verschiedenen Ordnern nach Bildern suchen oder zwischen Bildern mit ".lay" und solchen ohne unterscheiden müssen.
Entweder so oder das automatische layout für ein ganzes Volume durch ein eigenes Script ersetzen.
entschuldigung ich hatte meine frage unverstaendlich formuliert. nochmal :-) also, es macht ja keinen sinn von einem 400k .jpeg eine 2,3,4 od. 5mb grosse .lay tiff datei zuerstellen. wohl mach es sinn von einer 12, 20, 30 mb .tiff datei ein .2,3,4 od 5mb grosses .lay tiff zu generieren. somit versuche ich die erstellung eines .lay von einer datei < x mb generell auszuschalten, bzw. die bearbeitung der verschiedenen dateitypen zu trennen. wie beurteilt das forum die generierung von .lay dateien eines .jpeg's?
leider ist ein support bei HELIOS nicht verfuegbar.
über den Sinn lässt sich trefflich streiten. Wenn die Anwender gewohnt sind immer nur .lay Dateien zu platzieren, dann ist die Erstellung von Layout Dateien sinnvoll. Andersherum gefragt, weshalb sind größere Layoutdateien störend?
Wenn sie wirklich differentiert Layouts generieren wollen, dann sehe ich nur die Möglichkeit das automatische Layout durch ein eigenes Skript zu ersetzen. Da stehen Ihnen dann alle Freiheiten der Filterung nach Dateiformat und -größe offen.
Distributoren bekommen bei Helios Support, Händler sollten bei ihrem Distributor Support bekommen. So funktioniert das meines Wissens in Europa ganz erfolgreich.
ich hatte gehofft, dass der HELIOS fileserver nach wie vor im "create automatic layouts" modus laufen koennte, und das entsprechende volume nicht als hotfolder deklariert und mit einem script, welches den automatic modus komplett nachbauen muss, versehen werden muss. mir scheint der "automatic modus" ein deutliches schneller, als der script based hotfolder, da keine zeit fuers polling aufgewendet werden muss. ungluecklicher weise hat es der anwender mit einer grossen anzahl dateien in einem ordner zu tun.
ic hatte angenommen, dass es in der OPI/ HELIOS gemeinde grundsaetzlich unfug sei eine .lay (low-res) datei >= original/ high-res datei zu erzeugen.
Das ist ja gerade das Schöne am Helios Scriptserver, es wird nicht gepollt. Der gesamte Helios Server arbeitet seit eh und je mit Datei Events. Die werden immer erzeugt, wenn ein Client (Mac über EtherShare, Windows über PCShare, Webbrowser über WebShare) eine Datei auf einem Server Volume speichert oder verändert.
Das automatische Helios Layout nutzt diese Events um für alle unterstützten Bildformate eine Layoutkopie zu berechnen. Der ScriptServer ist die nutzbare Schnittstelle zu dem automatischen Layout Mechanismus. Ein per Scriptserver aufgerufenes Script zur individuellen Layoutberechnung ist genauso schnell wie ein automatisches layout. Und es belastet die Maschine nicht durch eine zusätzliche Last.
Das tut in diesem Fall nichts zur Sache, da kein Pollen erforderlcih ist. Jedes Datei-Event enthält den Dateityp, also TIFF, EPSF, JPEG, PDF , usw. Danach kann ein Skript filtern und analog dem automatischen layout einen layout-Aufruf absetzen. Dabei kann man dann für verschiedene Dateitypen unterschiedliche Parameter mitgeben.
Ich bin im Rahmen meiner Supporttätigkeit häufig mit der Aussage konfrontiert, dass eine Änderung in der Arbeitsweise der Anwender auf jeden Fall zu vermeiden ist. Dafür ist an bereit, technische Mechanismen zu implementieren, die auf den ersten Blick nicht optimal erscheinen mögen. Als produzierendes Unternehmen muss man jedoch immer den tatsächlichen Durchsatz betrachten und der hängt viel von den Anwender ab. Insofern sollten sich die technischen Prozesse möglichst immer den menschlichen Angewohnheiten unterordnen.
Aber sie können mit dem Scriptserver und einem kleinen Script das von Ihnen favorisierte Verhalten wie oben erläutert bei ihrem Kunden implementieren.
Außerdem sollte man noch berücksichtigen, dass Layoutbilder nicht nur niedrigaufgelöste "Kopien" sind, sondern auch immer ein Format haben, was von "allen" Programmen verstanden wird. So sind diese (bei Standardeinstellungen) z.B. immer CMYK (bei bunten Hires Bildern) und unkomprimiert.
GreatOm -- Five exclamation marks, the sure sign of an insane mind. -- (Terry Pratchett, Reaper Man)
(Dieser Beitrag wurde von GreatOm am 23. Feb 2007, 13:41 geändert)
verstehe. vielen dank fuer die sehr hilfreichen antworten.
somit habe ich im script server perl script die zeile: open ( INFO,"| /usr/local/helios/bin/oiimginfo $ARGV[0] | grep 'File\ type'" ) || die "can't read from pipe: $!";
allerdings geingt es mir nicht die netsprechende abfrage, um dateitypen unteschiedlich behandeln zu koennen, durchzufuehren. while (<INFO>) { if ($info =~ /JPEG/) { layout .......................... ; } } hatte eine alternative ueber variable versucht: @info=<INFO>; $info=<INFO>;
es gelingt mir nicht das resultat des oimginfo an das script zur weiteren bearbeitung zu uebergeben.
kann mir ein HELIOS script-server erfahrener benutzer einen tip geben?
das musst Du doch gar nicht fix codieren sondern kannst es über die Parameter im Scriptserver mitgeben wann er überhaupt anspringt. oder soll er für mehrere typen anspringen und dann erst unterscheiden und verschiedene Sachen machen? Dann ists ja kein ScriptServer sondern ein Perl-Problem wenn ich das richtig sehe :-/
die anforderung basierend auf den filetype das 'layout' kommando automatisch mit veraenderten parametern aufzurufen, ist ein HELIOS problem, welches wohlr nur mit dem scriptserver, der perl interpretiert, zu loesen ist.
mir fehlt der mechanismus, ein resultat aus 'oiimginfo file' an das script zur weiteren verabeitung zu uebergeben.
trifft es zu, dass das 'layout' kommando unter der verwendung der option '-D' oder '-oUseLayoutDir' keine implementierte funktion zur automatischen ordner herstellung hat, so dass dieser automatismus ebenfalls im perl script erstellt werden muss?
sind perl scripte, die die automatische layout generierung auf einem HELIOS Volume ersetzten, verfuegbar? ist dem forum bekannt welche weiteren faktoren bei einer solchen ersetzung zu beruecksichtigen waere?
Mich würde interessieren warum so gearbeitet werden soll. Der Hintergrund ist mir völlig unklar...
Der oiimginfo-Aufruf dient dazu eine Datei zu identifizieren. Das macht doch aber der ScriptServer automatisch. Also braucht man doch nur ein Script welches auf "JPEG" lauscht um dann entsprechend zu agieren.
Wenn eine Datei an ein anderes Script "weitergereicht" werden soll kann dieses z.B. via 'dt mv -E" erfolgen oder man kann 'opitouch -e sendclose MYFILE' nutzen.
GreatOm -- Five exclamation marks, the sure sign of an insane mind. -- (Terry Pratchett, Reaper Man)
Die Anforderung von Herrn Jäger ist, dass er für einen seiner Kunden die automatische Layoutgenerierung durch eigene Mechanismen ersetzen möchte, die Hi-res Daten je nach Speicherformat unterschiedlich behandelt. Also beispielsweise für JEPG kein Layout oder einfach das Hi-res kopieren.
Der SkriptServer hat die Einschränkung, das man für ein Event nur ein Skript aufrufen kann. Es wird aber eine case Struktur benötigt. Wenn ein Bild gespeichert wird und es hat den Typ JPEG, dann kopiere Feinbild. Wenn hi-res ist TIFF, dann ... usw.
Das könnte man natürlich sequentiell abarbeiten. Eleganter ist es aber das Speicherformat zu ermitteln und dann in dem Skript selbst zu entscheiden, wie das Event verarbeitet werden soll.
Und genau das möchte Herr Jäger mit möglichst wenig Aufwand realisieren.
Dann könnte man doch einfach den ScriptServer so konfigurieren, dass verschiedene Dateitypen im gleichen Verzeichnis und auch mit dem gleichen Skript arbeiten.
Ich habe gerade einen kleinen Test gemacht und das Ergebnis war dementsprechend.
In diesem Fall könnte man jeder Skriptkonfiguration im Environment mitgeben wie das entprechende layouthandling sein soll und das Skript wäre viel einfacher, da nur bereits "gefilterte" Eingaben via SkripServer-Event erfolgen.
Gruß,
GreatOm -- Five exclamation marks, the sure sign of an insane mind. -- (Terry Pratchett, Reaper Man)
Hm, ich kann da nicht so ganz folgen. Natürlich würde man das Ersatz-layout Skript für alle relevanten Dateiformate aktivieren, also JPEG, TIFF, etc. Trotzdem bleibt es doch die Aufgabe des Skripts den jeweiligen Dateityp selbständig zu ermitteln. Das Event sagt doch nur "close" oder "rename".
...wie GreatOm ja schon -- allerdings ohne Beispiel -- so beschrieb...
Kleines Problem allerdings: Der Dateityp, den der scriptsrv mitbekommt, ist aus Metadaten wie FileType/Suffix abgeleitet, was manchmal nichts mit dem Inhalt der Datei zu tun hat.
Passiert zwar selten (zumal ja auch Photoshop/Mac seit Version 6 (?) sich erblödet, im Zweifelsfall eher auf das Suffix einer Mac-Datei zu schielen anstatt auf die ersten paar Bytes des Inhalts) kann aber bei so einer Lösung zu einem echten Show-Stopper mutieren.
Gruss,
Thomas, der eine grobe Dateiart-Analyse vermutlich in Analogie zu file/magic (http://de.wikipedia.org/...hnung_von_Dateitypen) erledigen lassen und das Ganze einem Profi anvertrauen würde anstatt die Lösung in öffentlichen Foren zusammenstöpseln zu wollen ;-) -- http://kaiser-edv.de/
(Dieser Beitrag wurde von Thomas Kaiser am 2. Mär 2007, 13:59 geändert)
Ich kann doch beispielsweise ein Skript für TIFF konfigurieren. Der opisrv/notifysrv kümmert sich dann darum, dass der ScriptServer dieses Skript auf dem eingestellten Pfad nur für TIFF Bilder aufruft. Ob es dann den richtigen TYP, Suffix oder was auch immer nutzt ist egal, die Serverprozesse richten das schon. Dann muss ich nur noch im environment für das Skript eine eindeutige Variable setzen, die dann im Skript abgefragt werden muss (z.B. BILDTYP=TIFF). Analog definierte ich mir den SkriptServeraufruf für alle anderen benötigten Formate und setze jeweils "BILDTYP" entsprechend.
Dann muss ich im Skript letztendlich nur noch BILDTYP aus dem Environment holen und kann dann entsprechend agieren.
Das ist viel einfacher und weniger fehlerträchtig als selber die oiimginfo-Ausgabe zu parsen.
Ich hoffe das war jetzt klar genug ;)
GreatOm -- Five exclamation marks, the sure sign of an insane mind. -- (Terry Pratchett, Reaper Man)
benutzt den oimginfo nicht die "magische zahl"? wie weit kommt eine anpassung, wenn sie die von HELIOS zur verfuegung gestellten mittel und wege benutzt. was stellt HELIOS zur verfuegung, ein SDK?
Herr Kaiser,
wer sind den die profis? raten sie das perl package 'File-MMagic-1.27' anstatt von oimginfo zu benutzen?
Moment... soll das heißen, die Differenzierung seitens des scriptsrv basiert auf einmal auf einer inhaltlichen Analyse des (Bild-)Dateityps? Wäre mir neu...
Überspitzt gefragt: Ich habe ein JPEG-Bild, das als "Bild 1.pdf" abgespeichert wurde und -- warum auch immer -- den FileType "EPSF" hat. Bernds Konfiguration zugrundegelegt gehe ich davon aus, daß
a) im Environment "EXT=eps" auftaucht, wenn das Bild von einem Mac auf den Helios-Server kopiert wird
b) im Environment "EXT=pdf" auftaucht, wenn das Bild von Windows aus auf den Helios-Server kopiert wird
c) das Bild nichtsdestoweniger weiterhin ein JPEG ist (also "EXT=jpg" richtig wäre, wenn man dem Beispiel folgt) und jegliche Skript-Logik, die sich auf externe Metadaten wie Suffix/Mac-FileType verläßt, satt gegen die Wand fährt.
Falsch?
Gruss,
Thomas, mit genau solchen Problemstellungen immer wieder in automatisierten Workflows bei Kunden konfrontiert seiend... -- http://kaiser-edv.de/
Das macht ggf. viel, viel, viel mehr, weil es Universalschnittstelle zu Helios' OpenImage Architecture ist. Oiimginfo schaut ggf. so tief ins Bild, daß es dafür sowohl Zeit als auch CPU-Zyklen braucht, die im Rahmen einer groben Vorsortierung (bspw. ob man das Bild an sich überhaupt anfassen soll) vielleicht schon reine Verschwendung sind. Der Unterschied, ob eine Prüfroutine für eine Datei eine halbe Sekunde 25% CPU-Last auf einem Server verbraucht oder nur eine Millisekunde besagte 25%, mag marginal erscheinen -- ist es aber nicht, wenn man reale Produktionsbedingungen betrachtet.
Auch. Nicht falsch verstehen: oiimginfo ist sicherlich das passende Werkzeug für inhaltliche Analyse von Bilddateien (und im Repro-/Litho-Bereich das mit Abstand mächtigste weit und breit). Nur ist sein Einsatz ggf. Resourcen-intensiv und das kann nach hinten losgehen (been there, done that)
Naja, die, die sowas professionell (für Geld) anbieten. Stehen Sie denn nicht schon mit einem "von denen" in Verbindung? ;-)
Nichts für ungut... Öffentliche Foren leben vom Geben und Nehmen bzw. dem Austausch bei dem sich alle Seiten einbringen. Eine sehr spezialisierte Aufgabenstellung ist eher was für Spezialisten, die schon eine Menge Lebenszeit und Hirnschmalz in die Aufgabenstellung investiert haben und -- nicht zu unterschätzen -- entsprechende Erfahrungen gesammelt haben, was an welcher Stelle mit welchen Konsequenzen wie schiefgehen kann.
Ich rate gar nichts, weil die Schilderung der Aufgabenstellung genauere Differenzierungen nicht zuläßt ;-)
Oiimginfo ist deutlich mächtiger als identify bzw. die Diagnose-Module von ImageMagick aus obigem Paket. Die (kleine Detail-)Frage, die ich vorhin anschnitt, hat aber eher was damit zu tun, ob besagte Universal-Werkzeuge nicht schon überdimensioniert sind bzw. einfach zu viel Resourcen ziehen für den angedachten Einsatzzweck einer reinen inhaltlichen Dateiformat-Erkennung.
Der Skript Server reagiert auf TYPE oder Extension. Hat ein Bild weder einen (Mac OS 9) TYPE noch eine Datei Extension, dann gibt es kein auswertbares Event.
Wie Thomas schon gesagt hat, das anspruchsvolle beim Ersetzen des automatische Helios layouts ist es, die in eigener Regie generierten Layoutbilder genauso schnell und treffsicher zu Erstellen wie Helios das von Hause aus tut.
kann das layout kommando im unterordner "layouts" layoutdateien mit einerm "suffix" erzeugen? scheinbar ist die option "UseLayoutDir" auf "true" voreingestellt, so dass die option "UseLayoutDir" oder "-D layouts" nicht notwendig sind. trotzdem gelingt es mir nicht im layout ordner layout dateien mit einem "suffix" zu versehen. dazu habe ich auf der kommandozeile das kommando "layout" mit allen erdenklichen moeglichkeiten ausprobiert, z.b. layout -o RasterImageType=JPEG -UseLayoutDir=true -o LayoutSuffix=.layJPEG -r 72 datei.tif
wird kein "suffix" verwendet so werden JPEG layoutdateien mit der endung .tif des originals im layout ordner erzeugt. das ist ja nicht richtig.
Verstehe ich nicht. Ich lege drei Ordner "%j", "%t", "%e" an. Dort hinen kopiere ich jeweils "Bild.jpg". Dann bekomme ich %j:layouts:Bild.jpg %t:layouts:Bild.tif %e:layouts:Bild.eps
Wenn ich allerdings beim Hires-Bild keinen Suffix verwende hat auch das Layoutbild keinen. Ich habe allerdings nicht den Effekt ein Bild mit einem falschen Suffix zu bekommen.
Kann es sein, dass die Option "ReplaceSuffix" gesetzt wurde?
Gruß,
GreatOm -- Five exclamation marks, the sure sign of an insane mind. -- (Terry Pratchett, Reaper Man)
the DAM solution my client is working with does not allow further separation into "%j" folder for example. I have to stick with what is possible on the command line.
das DAM system, welche HELIOS benutzt, erlaubt keine weitere unterteilung in "%j", "%t" ordner. das DAM system arbeitet mit einem fuer den benutzer reservierten bereich auf dem fileserver, in dem sich ein ordner fuer layouts befinden kann.
wozu dienen -oUseLayoutDir und -oLayoutSuffix auf der kommandozeile? schliessen sich diese beiden optionen aus?
hi ich würde ja mal vermuten das -oLayoutSuffix nur dafü da ist wenn kein Layout-Verzeichnis verwendet wird. Probier doch mal -o RasterImageSuffix <string:".tif">