Hallo miteinander,

ich hätt' da auch mal gern ein Problem...

Bei dem Versuch einen ganzen Schwung CMYK EPSe per

foldername%305jr

in RGB JPEGs in Originalauflösung zu wandeln, bin ich auf folgende Probleme gestossen:

1. Ob der Einstellung in PS 120Pixel/cm entsprechen die originale ja 304,8dpi.
Kann ich irgendwie sagen das sie bleiben sollen wie sie sind um da nicht wegen knapp 5 oder gar 0,2 Pixeln alles uminterpolieren zu müssen?


2. Was macht der da mit meinen Farben?

Die Originale haben ISOcoated angehängt, das Ergebnis hat kein Profil.

Ich habe nun versucht das Ergebnis erstmal nachzuvollziehen um überhaupt mal dahinterzukommen, was layout da eigentlich macht.

Das scheitert aber schon daran das ich das RGB Profil das im Ethershare Admin eingestellt war (CCIR-EBU-RGB) nirgends zu Gesicht bekomme.

Also in Ethershare Admin auf das umgänglichere EURO 2.6 UCR 370 umgestellt.

die JPEGs sehen jetzt gleich bescheiden aus, und auch sie enthalten kein Profil.

Und was bewirken in den OPI Server Vorgaben die Einstellungen?

CMYK Standard Profil soll wohl nur Verwendung finden wenn das Feinbild kein Profil hat. Trotzdem dürftig, 2 zur auswahl und was steckt wirklich hinter "euro" und "swop"?

Dann kann ich auch irgendwie nicht glauben, das das erzeugte Bild ein JPEG ist, es ist obwohl 3 Farbig und ohne Profil, ist es größer als das 4-farbige CMYK EPS aus dem es erzeugt wurde.

Nehme ich als Feinbild mal ein RGB-TIFF her, so wird das Profil beibehalten, und das entstehende JPEG ist auch tatsächlich etwas kleiner als das original TIFF (5,3->3,9MB)

...

Ach so, die eigentlichen datien sind das garnicht, die sind nur etwa 200K, die Ressourcen in .rsrc sind so gewaltig :-(

Habe ich eigentlich durch eine !iccinfo.oic Datei einfluss auf die Layouterstellung?

Fragen über Fragen.

Werde mich jetzt mal mit der direkten Konvertierung per layout beschäftigen...
MfG

Thomas

Moin Thomas,

> Bei dem Versuch einen ganzen Schwung CMYK EPSe per
>
> foldername%305jr
>
> in RGB JPEGs in Originalauflösung zu wandeln

Das ist schon ein grundfalscher Ansatz, da bei der so parametrisierten Layout-Erzeugung die Auflösung fix vorgegeben werden muß. Der Schlüssel liegt darin, "layout" so für sich arbeiten zu lassen, daß man die Original-Auflösung beibehält als auch gezielt den Farbraum wechselt und dabei Einfluß auf die Art der Konvertierung und Einbettung der Profile nimmt.

"layout" kannst Du entweder per scriptsrv an Deine Daten lassen. Ich meine mich aber zu erinnern, daß ich letztes Jahr auf der Helios-Schulung noch einen viel simpleren Trick verraten habe?

Jedenfalls willst Du wohl sowas in der Art hier starten:

    layout -oForceRasterLayout=TRUE -o RasterImageType=JPEG -o RasterImageSuffix=.jpg -o RenderingQuality=2 -o PrintColor=RGB -o Attributes="Baseline=TRUE","DctMethod=2","Quality=80" -o
ProfilePaths=RGB='/pfad/zum/rgb.profil',CMYK='/pfad/zum/cmyk.profil'
-l "${Quelle}" '{unix,native,8BIM,JPEG}${Ziel}'

Bzgl. den Profil-Einbettungseinstellungen mußt Du Dich wohl oder übel mit dem ImageServer Handbuch auseinandersetzen: UseProfile und IncludeProfile Preferences sind das, was Dich interessieren dürfte... (die OmitProfile Preference ärgert Dich jedenfalls schon jetzt ;-)

> Und was bewirken in den OPI Server Vorgaben die Einstellungen?

Meinst Du die Profile? Das sind die Standardprofile für Ausgabe, wenn den Queues kein eindeutiges Profil zugewiesen wurde, und für Screen/Printable Preview bei Layout-Generierung.

> CMYK Standard Profil soll wohl nur Verwendung finden wenn das
> Feinbild kein Profil hat. Trotzdem dürftig, 2 zur auswahl und was
> steckt wirklich hinter "euro" und "swop"?

Abschnitt 8.1.2 im ImageServer Handbuch...

> Dann kann ich auch irgendwie nicht glauben, das das erzeugte Bild
> ein JPEG ist, es ist obwohl 3 Farbig und ohne Profil, ist es
> größer als das 4-farbige CMYK EPS aus dem es erzeugt wurde.

Naja, Du steckst da auch noch eine gigantische Bildschirmpreview mit 305 dpi mit rein. Und dann wunderst Du Dich? ;-)

> Habe ich eigentlich durch eine !iccinfo.oic Datei einfluss auf die
> Layouterstellung?

Ja. Aber nicht unbedingt so, wie Du das willst. Lies am besten nochmal die Kapitel 3.5 und 5.4 an: http://www.helios.de/...tput/OPIBuchTOC.html

Gruss,

Thomas

Hallo Thomas,

> as ist schon ein grundfalscher Ansatz, ...

Das ist mir zwischenzeitlich auch gedämmert.


>     layout -oForceRasterLayout=TRUE -o RasterImageType=JPEG -o
> RasterImageSuffix=.jpg -o RenderingQuality=2 -o PrintColor=RGB -o
> Attributes="Baseline=TRUE","DctMethod=2","Quality=80" -o
> ProfilePaths=RGB='/pfad/zum/rgb.profil',CMYK='/pfad/zum/
> cmyk.profil'
> -l "${Quelle}" '{unix,native,8BIM,JPEG}${Ziel}'

Du schreibst mir die Worte quasi aus dem Stift... an dem Bandwurm hab ich gestern ne halbe Stunde gefrickelt und dann tat er immer noch nicht was er sollte...

>(die OmitProfile Preference ärgert Dich jedenfalls schon jetzt ;-)

Als ich die gesehen hab, ist mir auch gedämmert das ich mit der Layoutfolder Geschichte wohl nicht weiter komme, nebst der nicht vorhandenen Möglichkeit, Profile und RIs zu wählen.

> Abschnitt 8.1.2 im ImageServer Handbuch...

ein RTFM hät's auch getan, die glauben hier ja sonst noch, ich währ zu dumm zum suchen. Trotzdem Danke bzw. hab ich es zwischenzeitlich auch selber schon gefunden ;-)

> Ja. Aber nicht unbedingt so, wie Du das willst. Lies am besten
> nochmal die Kapitel 3.5 und 5.4 an:
> http://www.helios.de/...tput/OPIBuchTOC.html

Dascha deutsch! Seit wann ist denn das fertig...

Ich merke schon, ich geh da zu selten dran.

Danke für die Tips, Bestätigungen und Zurechtweisungen.

MfG

Thomas

Hallo Thomas,

> Profile und RIs zu wählen.

Apropos Rendering Intents und layout. "layout -h" ist gesprächig, "layout -h -vv" sogar direkt geschwätzig ;-)

>> Abschnitt 8.1.2 im ImageServer Handbuch...

> ein RTFM hät's auch getan, die glauben hier ja sonst noch, ich
> währ zu dumm zum suchen.

Naja, sollte ja auch ein Hinweis an andere Helios-Anwender sein, daß sie mal ein wenig drüber nachdenken, ob es sinnvoll ist, immer nur 2% der Möglichkeiten ihres Servers auszunutzen :-)

Gruss,

Thomas

Hallo,

> "layout -h" ist gesprächig, "layout -h -vv" sogar direkt
> geschwätzig ;-)

Die Helios'sche Variante des Plapperkäfers von Traal.
Soweit, den thread mit Michael nochmal nachzulesen, war ich auch schon ;-)

Naja, sollte ja auch ein Hinweis an andere Helios-Anwender sein, daß sie mal ein wenig drüber nachdenken, ob es sinnvoll ist, immer nur 2% der Möglichkeiten ihres Servers auszunutzen :-)

Löblich! Wobei man immer abwägen muss, was sinnvoll ist. Die 400 Bilder wären inzwischen per PS-Batch auch lang erledigt.

Oder SIPS oder sogar im CM-Dienstprogramm, oder, oder...

MfG

Thomas

Hallo Thomas,

> Soweit, den thread mit Michael nochmal nachzulesen, war ich auch
> schon ;-)

Hmm... steht grad auf der Leitung... *welchen* Thread?

> Wobei man immer abwägen muss, was sinnvoll ist. Die 400 Bilder
> wären inzwischen per PS-Batch auch lang erledigt.

Schon klar. Für einmalige Anwendung ist das Kämpfen mit den layout-Syntax-Bandwürmern wahrlich nicht geeignet. Sowas steckt man sich normalerweise ja einfach in Skripte, die man dann -- ggf. simpelst parametrisiert -- auf dem Server scharfschaltet.

Und ab da ist es dann in der Tat ein Unterschied, ob Sachen einfach durch bloßes Ablegen im richtigen Ordner "geschehen" oder man irgendwelche Batches aufruft.

Gerade die Möglichkeit, Konvertierungen quasi völlig transparent in normale Arbeitsabläufe einzubauen, finde ich ich so elegant an der serverseitigen Lösung.

Gruss,

Thomas

Hallo Thomas,

>> Soweit, den thread mit Michael nochmal nachzulesen, war ich auch
>> schon ;-)

> Hmm... steht grad auf der Leitung... *welchen* Thread?

Michael G. 06.11.2003, 15:58 Uhr image-server: jpg nach tiff mit groessenaenderung usw. usw.
seminar_07_2003 Liste.

MfG

Thomas

hallo,

ist zwar schon eine weile her, jedoch passt meine frage weiterfuehrend auf dieses thread.

ich moechte das layout-programm ebenfalls zum umrechnen von datei-format, aufloesung, farbraum etc. verwenden.
klappt soweit auch ganz gut... auch mit profileinbettung usw.

nach einem feature suche ich verzweifelt und komme auch trotz handbuch nicht weiter:
groesse und breite des bildes aendern. also mal aus der luft gegriffen ein bild (10x13cm, 350dpi, cmyk...) umrechnen in bild2 (3x4cm, 350dpi, cmyk...). wie geht das? oder geht es ueberhaupt? oder stehe ich um dieser fruehe uhrzeit nur auf den schlauch? zumindest gibt es einige drittanbieter die sogar mit bildausschnittsberechnungen etc. werben...

vielen dank fuer jeden tipp!


gruesse, ray

Hallo Ray,

wie soll denn das vor sich gehen?

Per Ordneranhängsel in der Form %... ?

Da ist wohl nichts dabei.

Das Programm layout hat aber sehr wohl einen Skalierungsparameter:


aus http://www.helios.de/...ap6_doc.html#1075691 :

xPix/yPix <uint32:None>


Dieser Parameter erlaubt es dem Anwender, die Größe des Layoutbilds in Pixeln in x- oder y-Richtung festzulegen. Dabei bleibt das Seitenverhältnis im Layoutbild erhalten. Das Programm layout stellt sicher, dass das erzeugte Layoutbild immer kleiner als oder gleich den angegebenen Größen ist. Wenn die Verwendung von xPix dazu führt, dass ein gegebener yPix-Wert nicht eingehalten werden kann, dann bestimmt yPix die Dimensionen des Layoutbilds und umgekehrt.


Beispiel: layout -o xPix=150 -o yPix=150 image.tif


Dieser Aufruf erzeugt ein Layoutbild, dessen Ausmaße gleich oder kleiner als 150 mal 150 Pixel sind.

Das läuft dann über eine shell oder eben als Script.

Hast du dir auch mal Quickimage und sips angeschaut in Verbindung mit Ordneraktionen?


MfG

Thomas

hallo thomas,

mmm... genau das ist der punkt: dabei bleibt das bild immer gleich gross und wird nicht neu berechnet. es geht nicht um "layout-bilder", sondern um bildumrechnungen. sprich kunde schickt alles in A3 und ich moechte fuer die produktion alles in 10x13 (gleiche aufloesung) umgerechnet haben. layout macht mir in deinem beispiel ein bild mit 150 pixel, weiterhin A3 gross und einer aufloesung mit 20 dpi oder so. fuer layout-bilder ok, aber ich will ja eigentlich keine layoutbilder sondern "neue produktionsbilder" und eine groessenveraenderung wie ich sie beispielsweise mit ner photoshop-aktion sonst "manuell" mache.

quickimage und sips... mmm... muss ich mal nach infos suchen. ich bin gerade am testen an einem duo-system, sprich helios macht alles bis auf die groessenanpassung und mit imagemagick mach ich die groessenveraenderung. fuer mich als programmierer und setzer sieht das ergebnis gut aus. ich muss dazu aber noch einen unserer reproiden am montag interviewen.

ueber photoshop und action-script habe ich bereits nachgedacht, waere aber noch ein weiterer rechner noetig und ein erhoehtes ausfallrisiko etc. schoen waere eine komplettloesung auf der linux-kiste, die ich direkt von php ggf. mit shell-scripten dazwischen und db loesen kann.


gruesse, ray

hallo nochmal,

habe mir eben das quickimage angeschaut. nettes tool fuer den privatanwender... :-)

ich glaube ich muss an dieser stelle doch etwas genauer erlaeutern was ich eigentlich machen will.

das ganze ist eine erweiterung des schon bestehenden job-archivs der vorstufe einer firma. sprich von der auftragsverwaltung soll wie bisher automatisch ein job im jobarchiv angelegt werden (jobarchiv mit php und mysql, benutzerverwaltung... kunde hat darauf zugriff und kann sich alle versionen als low-pdfs oder jpeg-thumbs anschaun). dazu kann nun die option fuer den bildupload und die entsprechenden berechtigungen gesetzt werden.

sprich der projektmanager kann sagen:
es kommen bilder von einer agentur oder fotografen. schalte dazu einen "ordner" fuer diesen job frei in den die agentur alle bilder speichern kann (per web-upload, ftp oder isdn). dazu gibt er ein neues oder hinterlegtes profil (ordnerstruktur, aufloesung, breite/hoehe, format, cmm-profil...) an. das passiert alles automatisch und funktioniert soweit auch.

wenn nun z.b. ein upload in einen freigeschalteten ordner erfolgt soll das bild automatisch von helios oder was auch immer umgerechnet werden. kommt also ein jpeg, rgb, 300x300mm, 72dpi mit profil von der digitalkamera und fuer den job ist hinterlegt dass alle einkommenden bilder in tiff ohne komprimierung, cmyk, 100x150mm, 350dpi und dem "hausprofil" umgerechnet werden sollen, geschieht dies automatisch. wenn die mindestmaße erreicht wurden und keine sonstigen fehler aufgetreten sind, wird das bild freigegeben im job-archiv als version 1 archiviert und z.b. dem bearbeitenden grafiker online zur verfuegung gestellt. (der kann aber auch sagen er will das bild in einem anderen format, weils z.b. fuer die titel-seite ist und sich das ganze so wie er es braucht online umrechnenen lassen).

Auf dem produktionserver im entsprechenden job-ordner in der vorgegebenen ordnerstruktur(!) wird es ebenfalls als version 1 gespeichert incl. layout-bild damit schon "gesetzt" werden kann.

erst ganz zum schluss sitzt ein repro-mann daran und macht seine arbeit am letzten stand der bilder (bilder koennen waehrend der produktion mehrmals direkt vom kunden ausgetauscht werden und muessen im layout-programm nur aktualisiert werden). das kann z.b. auch live geschehen waehrend der kunde via web-conference direkt den desktop des layouters sieht oder sich den letzten stand auf aus dem jobarchiv als pdf herunterlaedt usw.

das handling funzt wunderbar, es gibt auch ne fehlermeldung per email falls das bild nicht im produktionsordner gespeichert werden konnte (wegen unerreichbarkeit, ordner verschoben usw.).

helios produziert eigentlich einwandfreie ergebnisse, macht mir halt nur nicht die umrechnung und nochmal nen mac, applescript, ordneraktion... da wird das system wohl kaum mehr zuverlaessig handlebar und schnell genug. in der firma sind bisher taeglich 2-3 personen nur damit beschaeftigt photoshop-aktionen fuer irgendwelche bilder anzuwerfen in der mengenordnung von 200-5000 an 4 versch. doppelprozessorigen maschinen.... :-))

weiter gibt es andere tools mit denen man personalisierte serienbriefe oder auch nur visitenkarten produzieren kann bei denen direkt nach der online-bestellung nur noch ein praktikant die fertigen druck-pdfs (oder excel-liste fuer jourstruli) abgreifen muss. hier kann der besteller ebenfalls passbilder und signaturen uploaden die durch das neue system auch nicht mehr handisch geprueft werden sollen. uvm.


gruesse, ray