Hallo Kollegen,

hat jemand Erfahrungen mit dem CMYK Optimizer von Alwan.

Gruss
dabe

Hallo,

Antwort auf:

jemand

mit Sicherheit.



Ich übrigens auch.

Oder hast du eine konkrete Frage? ;-)


Viele Grüße

Loethelm

------------------
Helfen Sie mit, damit HilfDirSelbst.ch weiterhin helfen kann.
http://www.hilfdirselbst.ch/info/
------------------

Hallo,

ich hatte für unseren Geschäftsführer die Software getestet. Habt ihr schon Einsparungen eurer Druckfarbe und Reaktionen von Euren KD erhalten?

Gruss Dabe

hallo Dabe


Wir arbeiten seit gut zwei Jahren mit Alwan-Software, mittlerweile mit CMYK Optimizer Edition: ECO (AlwanColorHub 3.5.3), also bereits ein (kostenpflichtiges) Update...

Kurz: Wir möchten die software nicht mehr missen!

Von unserem "Einkauf" weiß ich, daß wir Farbe sparen, seitdem wir damit arbeiten. Ich kann Dir keine konkreten Zahlen nennen in EURO bezüglich der Farbeinsparung. Das läßt sich aber auch bei der Testversion sicher ermitteln unter:

AlwanColorHub->Menü->Manager->Statistics, wenn in der entsprechenden Queue dort in den Task-Einstellungen->Action->Ink Consumption Statistics aktiviert ist. Nach oder vor Rendering das Fenster: Statistic Manager öffnen. Dort findest Du unter Gain die in prozentuale Farbeinsparung, der Rest ist ein Rechenspiel...
Ich hab eben mal einen x-beliebigen Testjob eingeworfen und bekam die Meldung: Einsparung 15.7%. Selbst, wenn das jetzt nur zur Hälfte "stimmt" ist das wohl echtes Potential.

Wir haben die Software (damals auch als Testversion) mit einer eigens angelegten Druckform getestet, also einen direkten Vorher-/Nachher-Vergleich angedruckt. Seitdem reduzieren wir standardmäßig auf 280% TAC (Total Amount of Color = Gesamtfarbauftrag), manchmal sogar auf 250% oder weniger (dünnes Papier, hohe Stapel...).

Die Kommunikation mit dem Kunden bezüglich der Verwendung ist NICHT standardmäßig. Nur wenn wir müssen (z.B. bereits reduzierte Eingangsdaten in Uncoated), bzw gefragt werden, kommunizieren wir mit der Kundschaft detaillierter. Nicht, weil wir etwas verheimlichen, sondern weil der Kommunikationsaufwand mitunter zu viel zu hoch ist, der notwendige Kenntnisstand bezüglich der Materie oft zu ungleich. Da es eine Einstellung gibt die da lautet: Preserve Original Seperations brutzeln wir also auch in "korrektem" ISOCoatedv2 (TAC330%) vorliegende Dateien noch einmal runter ohne uns zu fürchten. Wir hatten noch nie eine Reklamation, die auf die (vielleicht heftig anmutende) Farbeinsparung durch TAC-Einstellung 280% zurückzuführen war.

Zweimal allerdings ging etwas schief: Einmal hatte ich den falschen RI gesetzt. In dem Fall wäre perzeptiv glücklicher gewesen als relativ colorimetrisch. Es gab tatsächlich eine 85%ige Abstufung einer CMYK_Farbe, die bei der Transformation von Coated in Uncoated "dunkler" gerechnet wurde, und zwar nur die 85%-Abstufung, der 100%ige Ursprungsfarbton wurde erwartungsgemäß behandelt (heller). Das war aber kein Fehler von Alwan, der Gegencheck einer Umrechnung in Photoshop jedenfalls verhielt sich nahezu identisch. Ein weiterer Fallstrick, war "Vektor like Bitmap", was wir bei Erstinstallation in einem Task vergessen hatten zu aktivieren, womit dann zwei verschiedene Farben gerechnet wurden, die eigentlich identisch hätten sein sollen (Bedienungsfehler). Nicht nur in diesem Zusammenhang empfiehlt es sich unter Umständen auch vorhandene Transparenzen vor Alwanisierung zu reduzieren (ist aber widerum nicht in jedem Fall ein Muß)...

Neulich hatte ich einen 5c-Job der auf Naturpapier (längere Trocknungszeiten vor dem Wenden) gedruckt werden sollte. Teilweise lagen dort CMYK-Bilder mit 316% TAC (=ISO Uncoated erlaubt 320%!) auf einem Vollflächen-Sonderfarben Hintergrund, somit waren da 416% in der Datei und das auf Naturpapier... In Absprache mit dem Kunden habe ich die CMYK-Bilder sogar auf 220 TAC% reduziert, sicherheitshalber dann noch einmal geprooft: Wir haben farblich keinen Unterschied festgestellt. Druckergebnis mit Kundenzufriedenheit (war beim Andruck zugegen).

Mit obigem Beispiel wollte ich veranschaulichen, daß sich auch die Gefahr des Ablegens seit Einführung der Software in unserem Workflow nahezu auf Null reduziert hat, an ein klassisches "Brikett" kann ich mich jedenfalls nur aus der Zeit vor Alwan in unserem Hause erinnern.
... Allein diese "Rechnung" finde ich überzeugend: Eine einzige 5000er Auflage inklusive Bubi-Fremdfertigung wegen Ablegens berechtigterweise reklamiert contra Anschaffungskosten Alwan...

Nein, ich stehe nicht auf der Alwan-Lohnliste! Bin aber aus Eigennutz am "Fortbestehen" und Weiterentwickeln der Software interessiert...

Gruß,

Ulrich

Hallo,

danke für die umfangreiche Zusammenfassung. Wenn gestattet, klinke ich mich mal hier ein.

Seit einiger Zeit beschäftigt mich die Frage, wo an welcher Stelle im Workflow man den Color-Server platziert. Vor dem Dateneingang in das Workflowsystem (welches ja die PDFs auf die Platte belichtet)? Was bedeuten würde, dass unkontrollierte Daten auf den Color-Server kommen, die noch nicht vom Workflow glatt gebügelt wurden.
Schickt man hingegen die Druckjobs erst in das WFM-System, um sie glatt zu bügeln, müssen sie anschließend wieder raus. Das hätte dann zwar den Vorteil, dass geprüfte und standardisierte Daten auf den Color-Server treffen, aber gleichzeitig den Nachteil, dass die Daten dann nochmal in den Workflow müssen. Also doppelter Aufwand. Eine temporäre Verschiebung/Verrechnung kann ja auch nicht sinnvoll sein.

Wie wird das gehandhabt, wenn ich fragen darf?

Gruß

Antwort auf [ rohrfrei ]

Hallo,

danke für die umfangreiche Zusammenfassung. Wenn gestattet, klinke ich mich mal hier ein.

Seit einiger Zeit beschäftigt mich die Frage, wo an welcher Stelle im Workflow man den Color-Server platziert. Vor dem Dateneingang in das Workflowsystem (welches ja die PDFs auf die Platte belichtet)? Was bedeuten würde, dass unkontrollierte Daten auf den Color-Server kommen, die noch nicht vom Workflow glatt gebügelt wurden.
Schickt man hingegen die Druckjobs erst in das WFM-System, um sie glatt zu bügeln, müssen sie anschließend wieder raus. Das hätte dann zwar den Vorteil, dass geprüfte und standardisierte Daten auf den Color-Server treffen, aber gleichzeitig den Nachteil, dass die Daten dann nochmal in den Workflow müssen. Also doppelter Aufwand. Eine temporäre Verschiebung/Verrechnung kann ja auch nicht sinnvoll sein.

Wie wird das gehandhabt, wenn ich fragen darf?

Gruß

Da wir uns derzeit mit derselben Problematik befassen, würde mich das auch interessieren :=)

hallo nochmal

Also in unserer Strecke ist die Device-Link-Konvertierung vor dem "Workflow" (ORIS-WORKS) platziert. Nicht unbedingt weil es die klügste aller denkbaren Lösungen ist, sondern sich das schlicht und ergreifend so entwickelt hat.

Der bei uns immer noch eingesetzte Hotfolderbasierte ORIS-Workflow (CGS), dessen Weiter-Entwicklung mittlerweile auf (tauendem?!) EPS-Eis liegt, war bei uns vor gut 10 Jahren - also vor der rasanten Druckvorstufen-PDF-Entwicklung - alles in Einem: Preflight auf fehlende Schriften und mickrig aufgelöste Bilder, RGB-CMYK-, bzw 1c-SW-Umwandler, Trappingstation, "smoothshader" und so weiter. Bis auf RGB-CMYK-Umwandlung (das macht ALWAN jetzt!) erfüllt er die meisten dieser Aufgaben auch immer noch. In der Hauptsache jedoch erzeugt er nach wie vor niedrig aufgelöste EPSe fürs Ausschiessen in Preps, und managet deren Austausch mit High-EPSen mittels Dateibezeichnungskonventionen auf die ausgeschossenen Bögen angewendet recht "bequem" in diverseste Ausgabe-Queues (Raster-Palette: 60er, 70er, 80er, SPEKTA-FM, diese zum Teil noch unterschiedlich gewinkelt und sogar noch getrennt mit entsprechenden Tonwertkorrekturkurven für Papiertypen 1/2 und 4 versehen, bis vor anderthalb Jahren sogar auch noch für CTF-Fremdbelichtungen...)
In Kombination mit dem dazugehörigen PDF-Tuner (CGS) mitunter immer noch eine schnellere Möglichkeit für "Korrekturen in letzter Minute" gemessen an so mancher PitSTOP-Performance.

Unter dem Strich polemisch-Rehagelsch-dialektisch: Modern ist, was Erfolg hat und nicht: Erfolg hat, was modern ist...

Angesichts selbstangestellter Überlegungen, ob wir uns für ein APE- ( AdobePrintEngine? mit "live"-Transparenz-Bezwingungskeule) bestücktes Update von Harlekin-RIP 5.3irgendwas auf Version 8 kostenträchtig interessieren sollten, um dann auch endlich in PREPS mittels PDF-PDF arbeiten zu wollen - (das hängt bei uns derzeit eher von der Sorge ab, ob wohl in vier Jahren noch ein Rechner-Hardware aufzutreiben ist, auf dem Win2000 als Betriebsystem installiert werden kann, weil möglicherweise nur dann der ORIS-Workflow noch genutzt werden kann...) - möchte ich mich Deiner (mehr als berechtigten!) Frage nach "Position" der Device-Link-Transformation in einem "modernem" Workflow im Prinzip einfach anschließen, denn was nützt mir das Transparenz-verarbeitende RIP, wenn ich mich möglicherweise zuvor doch wegen des Einsatzes von Device-Link-Technologie zumindest in bestimmten Situationen gezwungen sehe, diese zuvor zu reduzieren...

Kurz noch als Denkansatz (auch für mich selbst jetzt): Es ist schon abhängig von welchem "Workflow" Du sprichst.

"Glattbügeln" geht ja wohl heute bereits mittels Acrobat und PitSTOP (PitSTOP-Server...?). Somit am Anfang einer Strecke. Andererseits: Anhand heute möglicher Rechnerkapazitäten und damit Tempo wäre das für mich möglicherweise noch im Zusammenhang mit Hotfolder-Einsatz oder Skripts (wenn man jemanden findet, der einem das verfasst...) eigentlich kein Hinderungsgrund etwas "zweimal" zu rechnen, soweit keine potentielle Fehlerquelle eingebaut wird dadurch.

Wie bereits erwähnt: ALWAN verarbeitet auch PDF, die Transparenzen enthalten und wir haben das auch genutzt. Nicht einmal, daß wir darüber fehlerverhaftet gestolpert sind, jedoch allein in Erwägung ziehend, welche komplexen, theoretisch möglichen Komplikationen jetzt nicht vorbedacht werden, im Zusammenhang mit SWOP, ECI und sonstwas-coated versehenden Sonderfarb-Transparenz-Überdrucken-Situationen bei miteinander verwobenen Bildern und Vektoren in aus zuvor aus einzelnen Seiten bestehenden nun zusammengefügten PDF-Files mit mehreren Untergruppen ein und derselben Schrift...

Entschuldigung fürs Ausufern, falsche Kommasetzung und anderer orthografischer Schwächen...

Gruß,

Ulrich

Zitat

Wie wird das gehandhabt, wenn ich fragen darf?

bei uns im großformatigen digital- und siebdruck ist die positionierung des optimizers wie in dem workflow vom pdf standardizer. dort macht er sich ganz gut ;-)
http://impressed.de/...tandardizer_Flow.gif

natürlich geht die eingangs- und ausgangsverzweigung noch weiter … kommt ganz auf die firmeninterne datenstruktur an.

hallo Meister Propper,

Probleme mit komplexen Transparenzsituationen habt ihr demnach bei gleichzeitiger Verwendung von ALWAN also nicht?

Ulrich

Zitat

Probleme mit komplexen Transparenzsituationen habt ihr demnach bei gleichzeitiger Verwendung von ALWAN also nicht?

;-) nicht vom alwan. er rechnet bis jetzt ohne probleme alles flach. das problem liegt bei teilweise komplexen transparenzsituation eher an unserem lfp rip, das er die "überdrucken" information fehlinterpretiert. ich hoffe aber mit dem nächsten lfp update diese baustelle zu beenden.

Hallo Meister Propper

Überducken Probleme auf RIP?: Bestimmt habt ihr auch schon probiert mit "Überdrucken simulieren"-Einstellung zur Lösung zu kommen.

Falls wider Erwarten nicht: Ich bewerte den Button "Überdrucken simulieren" bei den verschiedensten Ausgabesituationen mittlerweile (Im PDF-Zeitalter Acrobat 9) nicht mehr als ehemaligen Kardinalfehler wie noch bei Postscript (da war so etwas auf PS-fähigen Ausgabegeräten mitunter fatal), sondern eigentlich als Problemlöser in fiesen, wenn nicht sogar in allen Fällen...

Mittlerweile - so scheints - wird nämlich nicht mehr auf nicht-postscriptfähigen Ausgabegeräten (Bürodruckern) mit dem "Überdrucken simulieren"-Button die fehlende PS-Interpretation der "Überdrucken"-Funktion schlecht oder recht ausgeglichen, sondern die fehlende Transparenz (=quasi Überdrucken-Situation) auf nicht APE-fähigen (AdobePrintEngine = Transparenzauswertend/rippenden) Ausgabegeräten wie mir scheint...

Auf eine hoffentlich nicht zu vernichtend ausfallende Korrektur diesbezüglich des sehr von mir verehrten Herr Zacherl, falls er dies liest, wäre ich gespannt.

Ulrich

Hallo,

Zitat von Meister Propper

bei uns im großformatigen digital- und siebdruck ist die positionierung des optimizers wie in dem workflow vom pdf standardizer. dort macht er sich ganz gut ;-)
http://impressed.de/...tandardizer_Flow.gif

Die Grafik ist ja ganz aufschlußreich und der Standardizer sicherlich ein gutes Produkt, aber der kann halt keine Druckplatten belichten und da ist auch noch nix ausgeschossen worden. Zumal die Kosten in einer wie im screenshot abgebildeten config evtl. noch mit den Callas-Addons schon höher liegen als ein vergleichbares WFM (was zugegeben keinen Color-Server beinhaltet wenn man mal die grundsätzliche Verwendbarkeit von DL-Profilen außer acht lässt).

Habt Ihr den Standardizer im Praxiseinsatz? Kannst du dazu etwas mehr berichten? Ist vom Konzept her hochinteressant und mich würde mal interessieren wie der sich so an echten, lebenden Wald-und-Wiesen-PDFs aus der Praxis anstellt. Auch im Hinblick auf die vielen Fogra39-Profile mit Ihren zahlreichen Abwandlungen (evtl. runtergebrochen bis auf Fogra27).

Gruß

Hallo,

eine kleine Anmerkung zum CMYK Optimizer von Alwan, der ja auch im Standardizer enthalten ist.

Der CMYK Optimizer arbeitet etwas anders, als die anderen am Markt erhältlichen Colorserver. Der CMYK Optimizer analysiert zuerst die PDF-Datei in Hinblick auf ICC-Profile auf Objektebene und den in einer PDF- oder PDF/X-Datei enthaltenen Output Intent. Je nach Konfiguration hat dann der OI Vorrang vor dem definierten CMYK-Default Profil oder auch nicht.

Als Beispiel nehme ich mal die Verarbeitung von PDF-Dateien mit Honorierung des OI:
Der CMYK Optimizer erzeugt auf Basis der PDF-Analyse dynamisch die DeviceLink-Profile, die dann auf die PDF-Datei angewendet werden. Wenn also auf Objektebene vom OI abweichende CMYK-ICC-Profile gefunden werden, wird im ersten Schritt ein DeviceLink-Profil von z.B. Euroscale Coated nach ISO Coated v2 erstellt und angewendet, alle RGB-Bilder werden unter Berücksichtigung der Quellprofil ebenfalls in ISO Coated v2 konvertiert.
Ich kann hier zusätzlich frei definierbare Profile (z.B. ISO Coated v2 (eci),ISO Coated v2 300% (eci),ISO Coated v2 (basiccolor), usw. für eine Druckbedingung zusammenfassen, um unnötige Transformationen zu vermeiden. Es findet dann keine DeviceLink-Erzeugung von z.B. ISO Coated v2 nach ISO Coated v2 (300) statt. Wäre ja auch in dem Fall sinnlos.

Im zweiten Schritt wird nun ein DeviceLink-Profil auf Basis der in der Software hinterlegten Einstellungen berechnet (Farbauftragsreduzierung, Druckfarbeinsparung, usw). Der CMYK-Optimizer ist zusätzlich in der Lage, überdruckende Elemente zu erkennen. Das ist in bestimmten Überdrucken-Situationen hilfreich, um eine ungewünschte Farbverschiebung zu verhindern. Transparente Objekte werden ebenfalls erkannt und es ist frei wählbar, ob diese Dateien dann verarbeitet werden sollen oder nicht.

Ein Flattening von Transparenzen ist im CMYK Optimizer ab Version 3.6 enthalten, die auch im pdfStandardizer integriert ist; genau so wie PitStop Server und ein Full Switch.


Gruß,
Karsten Schwarze

--------------------------
www.impressed.de

Hallo rohrfrei,

abhängig vom eingesetzten Workflow gibt es mittlerweile schon Erfahrungen mit z.B. Prinergy und RBA (rule based automation), die es ermöglichen, im z.B. CMYK Optimizer verarbeitete Dateien wieder in den Workflow zu integrieren.


Gruß,
Karsten Schwarze

--------------------------
www.impressed.de

Zitat

Die Grafik ist ja ganz aufschlußreich und der Standardizer sicherlich ein gutes Produkt, aber der kann halt keine Druckplatten belichten und da ist auch noch nix ausgeschossen worden.

du kannst den pdf standardizer mit deinen gewünschten funktionen bereichern. denn der pdf standardizer ist "nur" ein workflow mit den produkten fullswitch + pitstop server + cymk optimizer. wenn du dann z.b. noch den powerswitch nehmen würdest hättest du die möglichkeit mit dem konfigurator preps für das ausschießen anzusteuern … siehe http://impressed.de/...p;fid=32961%2E000000

für uns als digital- und siebdrucker haben wir den stress mit dem ausschießen und belichten ja nicht ;-) … dafür haben wir andere schwierigkeiten. schön ist es dann, wenn man automatisiert sich das leben etwas leichter machen kann ;-)

also mit profilen etc. hatten wir noch nie probleme. eher mit zu gering aufgelösten bildern, fälschlicherweise angelegten sonderfarben, formatabweichungen, usw.