Hello all !

Im Rahmen einer Neustrukturierung unseres PDF-Workflows teste ich gerade die Performance der pdfToolbox 5 bei der X3-Konvertierung. Als Testdatei sollte ein PDF 1.6 dienen, ca. 250x370 cm (ja, Zentimeter!) mit einigen Bildchen und einem großen, 2fach platzierten Hintergrundmotiv (660 MB), so dass die PDF-Endgröße mit ZIP-Kompression bei ca. 600 MB lag.

Um die Tests zu beschleunigen, habe ich die beiden Hintergrundmotive erstmal entfernt ( => PDF 1.6 mit ca. 120 MB) und damit folgende Verarbeitungszeiten erreicht:

– Das Acrobat 9-Standard Korrekturprofil "Nach PDF/X-3 konvertieren (Coated FOGRA 39)" in Acrobat 9 ausgeführt -> ca. 3 Min.
Um gleiche Verhältnisse zu schaffen, habe ich dieses Setting aus Acrobat exportiert und in die pdfToolbox importiert:
– Das Acrobat 9-Standard Korrekturprofil "Nach PDF/X-3 konvertieren (Coated FOGRA 39)" in Acrobat 9 ausgeführt -> ca. 6 Min.

Dies ist grob gesagt eine Verdoppelung der Verarbeitungszeit, wofür sicherlich vor allem die in der pdfToolbox hinterlegten Bildoptimierungen verantwortlich sind (welche z.B. 300 dpi-ZIP zu 600dpi-JPG-Kompression wandeln). Teste ich die Verarbeitungszeiten des Original-PDFs (mit 2x Hintergrundmotiv), so erhalte ich folgende Zeiten:
– Acrobat: ca. 35 Min.
– pdfToolbox: > 90 Min.

Mit derart langen Verarbeitungszeiten kann und möchte ich mich nicht widerstandslos abfinden, zumal diese PDF-Größen bei Großformaten keine Seltenheit sind.

Hierzu sei noch ergänzt, dass hierbei absichtlich der Weg "INDD -> PDF 1.6 -> Konvertierung zu X3 via pdfToolbox" gewählt wurde und ein Direktexport aus INDD als X3 ausscheidet. Ferner ist die Transparenzreduzierungs-Einstellung des besagten Settings mit "schnellste Verarbeitung" definiert und soll – als beste Wahl zwischen Qualität und Quantität – auch so stehen bleiben. Sämtliche Bilder wurden bereits beim Export auf Bildrahmen beschnitten.

Welche anderen Möglichkeiten gibt es, die Verarbeitungszeiten der pdfToolbox bei der PDF/X3-Konvertierung zu beschleunigen?


MfG
Thomas Kittel

Hallo,

ich selbst habe mich auch schon öfter darüber geärgert, dass sowohl Acrobat als auch Toolbox jeweils nur einen Prozessorkern nutzen. In Zeiten von 8-Kern-Maschinen und mehr ist das ein Witz und zeigt mal wieder sehr schön den Unterschied zwischen Marketing-bla-bla und der Praxis. Auf einem aktuellen Mac und PC habe ich ständig 88% Prozessorleistung ungenutzt weil 7 Kerne einfach brach liegen und das regt mich tierisch auf.

In dem Fall wäre wahrscheinlich der Toolbox-Server eine Alternative mit einer intelligenten Hardware-Wahl. Müsste man mal bei Callas fragen, ob der in der CLI-Version die Hardware besser nutzt.

Gruß

Hallo "rohrfrei",

die "reine" Serverversion ohne CLI (heißt das so?) kann das nach meinem jetzigen Kenntnisstand ebenfalls nicht, denn auch dort erhält jeder Vorgang max. 1 Kern. Ein einziges Mal sah ich zwar kurz die Prozentzahl 100,2% aufblinken, was ich mir aber nicht wirklich erklären kann. Ansonsten lässt meine "große" Testdatei auch die Serverversion gute 94 Min. (auf 2x 2,3 GHz QuadCore mit 12 GB RAM und SSD-Platten) rund um die 100% Auslastungsmarke tanzen.

Und wenn, wie in meinem Fall, hierbei auch noch ein PowerSwitch-Workflow zum Zuge kommen soll, der exakt an dieser Stelle mit weiteren "Abformaten" darauf warten muss, ob die X3-Konvertierung erfolgreich sein wird oder nicht, so sehe ich mich in genau diesem Punkt vor einem gaaanz großen Problem! :o(

Zur Not würde ich von meinen verlustfrei ZIP-komprimierten Bildern im PDF1.6 Abstand nehmen, fürchte jedoch, dass beim Wechsel auf JPG max. die Qualität leiden wird!? Da die Bildoptimierung der pdfToolbox auf jeden Fall eingreifen wird, können bei der Konvertierung von PDF1.6 JPGmax nach PDF/X3 JPGmax die Bilder ja auch nicht einfach "durchgereicht" werden, was vielleicht den ersehnten Geschwindigkeitsschub bringen würde!?

Dass verlustfreies JPG2000 (welches ja auch erst dekomprimiert werden müsste, um anschl. im X3 zu JPGmax. zu werden) einen Geschwindigkeitsvorteil bieten könnte, halte ich eher für unwahrscheinlich – habe es aber noch nicht ausprobiert.

Irgendwelche Ideen oder weitere "Kritik" hierzu?

Gruß Thomas

Hallo Ihr zwei,

auf unserem Server mit Switch und callas ToolBox Server wird bei mehreren Aktivitäten die ToolBox mehrfach gestartet.

Während die ToolBox also noch mit Deinem X3 beschäftigt ist, wird auf dem zweiten Kern eine zweite ToolBox gestartet, welche dann mal eben eine Optimeirung für eine Visitenkarte macht und auf dem dritten Kern eine Vorschau erzeugt.

Oder interpretiere ich das falsch, wenn ich bei Switch im Fortschritt mehrere ToolBox-Aktionen sehe und in der Aktivitätsanzeige von OS-X-Server auch mehrfach die ToolBox auftaucht.

Grüße aus Berlin

Nein, das siehst du richtig. Wenn die Aktivitätsanzeige mehrere Prozesse gleichen Namens mit unterschiedlichen PIDs siehst, laufen da auch mehrere Prozesse parallel.

@ T-Kittel:

Was die Frage nach JPEG angeht: Das wird sicherlich schneller, da das reine File I/O abnimmt, und die JPEG Kompression/Dekompression nicht so viel Last erzeugt. Bei JPEG2000 sieht das wieder ganz anders aus, das erzeugt hier immer Unmengen an Last (Lässt sich schon beim Sichern und Öffnen in Photoshop beobachten.)

Warum glaubst du, dass die JPEG Komprimierung von Toolbox bei gleicher Qualitätsstufe erneut absolviert wird?

Wie groß ist denn die 'große'?

@Polylux,
nein, ich denke Du interpretierst das schon richtig. Auch bei mir werden mehrere Prozesse gleichzeitig gestartet, je nach Switch-Voreinstellung (0 = "Alle verfügbaren") . Des Users Wunschtraum wäre wohl, dass selbst eine einzelne Aufgabe auf mehrere Prozessoren gleichzeitig verteilt werden könnte – Wunschtraum eben ;o)

In meinem Falle (auf Dein Beispiel übertragen) verhält es sich so, dass die Optimierung der Visitenkarte (2. Kern) und die Vorschau (3. Kern) wirklich erst dann gestartet werden soll, wenn die X3-Konvertierung (1. Kern) auch wirklich erfolgreich war (Stichwort "Syncronisationspunkte"). Denn wofür die Kerne 2+3 schon (umsonst) arbeiten lassen, wenn Kern 1 kurze Zeit später feststellt, dass die X3-Kriterien nicht erfüllt werden? Klar könnte man die unnötig-erzeugten "Abformate" vor Übergabe an den Ausgabeordner wieder einsammeln und vernichten - fände ich aber suboptimal.

Mich stört ja in der Hauptsache die – in Relation zum X3-Direktexport aus Indesign – bedeutend längere Verarbeitungszeit (PDF 1.6 -> X3 via pdfToolbox = ca. 90 Min. vs. X3-Direktexport aus INDD = 7 Min.)! Im Grunde erledigen doch beide (rein technisch gesehen) die gleichen Aufgaben und Prozesse (Farbkonvertierung, Downsampling, Transparenzreduzierung, etc.) und in beiden Fällen mit Original-Adobe-Technologie. Dass Callas on-the-fly auch noch eine Bildoptimierung vornimmt finde ich zwar sehr lobenswert, aber der Preis (in Form einer solch verlängerten Bearbeitungszeit) empfinde ich persönlich als zu hoch.

Und genau hier suche ich einen Ansatzpunkt:
Am liebsten würde ich der pdfToolbox gerne die Daten schon "mundgerecht" vorbereiten, indem ich Auflösung und Kompression bereits im Vorfeld auf die Ausgabe der Toolbox anpasse.
Aber dies wird sicher nicht möglich sein, da die Toolbox mit ihrer (nicht deaktivierbaren?) Bildoptimierung die JPGs sowieso dekomprimieren, transparenzreduzieren, hochrechnen und optimieren und neu-komprimieren muss.

Antwort auf [ Thomas Richard ]

Warum glaubst du, dass die JPEG Komprimierung von Toolbox bei gleicher Qualitätsstufe erneut absolviert wird?

Weil ja hier noch die Transparenzreduzierung durchgeführt werden muss und somit das (bereits im Quell-PDF) verlustbehaftete Bild dekomprimiert und erneut mit Verlusten neu-komprimiert werden muss, oder?

Die Qualität bzw. Auflösung hatte ich übrigens hier ( http://www.hilfdirselbst.ch/...medium__P473433.html ) schon bemängelt, wobei mir neben den Schärfeverlusten auch die Logik (300 dpi ZIP wird zu 300-1200 dpi JPG) nicht ganz einleuchtete und einleuchtet.

Antwort auf [ Thomas Richard ]

Wie groß ist denn die 'große'?

Wie oben erwähnt: ca. 600 MB (bei ZIP-Kompression)

Antwort auf [ Thomas Richard ]

Was die Frage nach JPEG angeht: Das wird sicherlich schneller, da das reine File I/O abnimmt, und die JPEG Kompression/Dekompression nicht so viel Last erzeugt.

Wenn Du mir so viel Mut machst, werde ich möglichst bald mal einen JPG-Test fahren und sowohl auf die Zeiten als auch auf die Qualität ein besonderes Augenmerk werfen.

MfG

Nachtrag:
Die pdfToolbox lässt mir ja auch nicht wirklich die Wahl bzgl. meiner Wunsch-Kompressionsmethode im Ziel-PDF/X3. Durch die Bildoptimierungen – im Zusammenspiel mit den 4 möglichen Einstellungen (ebenfalls hier http://www.hilfdirselbst.ch/...medium__P473433.html behandelt) – wird offenbar von Kachel zu Kachel entschieden, ob eine bestehende ZIP-Kompression beibehalten oder in JPG umkomprimiert wird. Das resultiert z.T. in hunderten, wild zwischen ZIP- und JPG-Kompression wechselnden Bildkacheln - zum Glück ohne optische Auswirkungen.

Antwort auf [ t-kittel ]

Hierzu sei noch ergänzt, dass hierbei absichtlich der Weg "INDD -> PDF 1.6 -> Konvertierung zu X3 via pdfToolbox" gewählt wurde und ein Direktexport aus INDD als X3 ausscheidet.

Willst Du uns vielleicht verraten, wieso das so ist?
Ich persönlich erstelle am Liebsten einmal ein PDF und mache daran so wenig wie nötig.
• Warum nicht gleich aus InDesign ein PDF/X3?
• Warum nicht vielleicht sogar ein PDF/X-4?

Habe heute erst wieder so eine Murks-Datei aus Pages mit Quartz bekommen, wo die Transparenzreduzierung die Schriften in Hieroglyphen gewandelt hat.
Beim Parallel-Flow ohne Reduzierung ist alles schön.

Tja, hier kommt die (alles andere als einfach zu verwirklichende) Philosophie der Dienstleistung ins Spiel, die versucht es allen recht zu machen:
In den meisten Fällen besteht leider keinerlei Kontakt zu den PDF-Empfängern (große und kleine Druckereien rund um den Globus) und somit herrscht totale Unkenntnis über das gewünschte PDF-Format. Gefühlt halten sich wohl momentan PDF/X3 und PDF 1.6 die Waage. Bis es soweit ist, dass alle Empfänger mit 1.6 und Transparenz umgehen können, sollen beide Formate stets vorrätig gehalten werden. Schicke ich 1.6 ins Land und bekomme es moniert, greife ich auf das bereitliegende X3 zurück – und umgekehrt. Das nachgelieferte X3 entstand definitiv aus dem zuvor versandten PDF 1.6 (quasi seiner "Mutter"), wodurch maximale Sicherheit gewährleistet werden soll. Ein manueller oder nochmaliger autom. Abgleich (zwischen 1.6 und X3) soll ebenso vermieden werden, wie ein zweiter Exportvorgang (und die hierdurch ebenfalls erforderliche, erneute Prüfung).
Exportiere ich zuerst nur X3, komme ich natürlich nie mehr zu meinem 1.6 oder X4. Hinzu kommen noch die gewaltigen Unterschiede der techn. Ausstattung; sowohl der Druckereien untereinander, als auch auf Seiten des Kunden, der z.T. noch in Acrobat Reader 5-ähnlichen Tools ohne Überdruckenvorschau unterwegs ist.

Sicherlich: ein hochgestecktes Ziel, wie die Tücke im Detail hier anhand meiner vielen Foreneinträge beweist.

Gruß Th.

Ich bin mir nicht sicher ob ich alles in diesem Diskussionstrang richtig verstand habe und frage daher einfach mal drauf los:

- wieso ist man mit der pdfToolbox dazu verdonnert, die Bilddaten zu rekomprimieren?

- wieso will man von 300ppi ZIP auf 600ppi JPEG hoch-sampeln / komprimieren?

Zur Performance: ich habe hier ein wenig den Eindruck, dass der pdfToolbox etwas "angelastet" wird, was die anderen Werkzeuge gar nicht "können", nämlich das Hochsampeln - das allerdings in der Tat ein kleiner Zeitfresser ist, schließlich wird die (ausgepackte) Datenmenge vervierfacht, und muss dann anschließend wieder mit JPEG eingepackt werden.

- zu JPEG2000: JPEG2000-Kompression ist auf dem HIntergrund der verwendeten Algorithmen recht aufwändig, mit PDF/X-3 ist sie obendrein eh' nicht erlaubt.

Grundsätzlich glaube ich, dass man in der Tat ein möglichst gutes und möglichst gut passendes Ausgangsmaterial erstellen sollte, um mit der pdfToolbox dann gezielt das anzupassen/zu konvertieren, was man evtl. nur mit einem nachgelagerten pdfToolbox-Prozess erreichen kann.


Olaf

Guten Morgen Olaf,

auch wenn ich nicht der Original-Poster bin, möchte ich trotzdem einmal antworten, so wie ich es verstanden habe und nachvollziehen konnte:

Antwort auf [ olaflist ]

- wieso ist man mit der pdfToolbox dazu verdonnert, die Bilddaten zu rekomprimieren?

Weil diese mit Transparenzen in Verbindung kommen und beim Verflachen macht die ToolBox sowas halt.

Antwort auf [ olaflist ]

- wieso will man von 300ppi ZIP auf 600ppi JPEG hoch-sampeln / komprimieren?

Das wollen wir ja gar nicht unbedingt, dass macht die ToolBox von sich aus ganz alleine (Bildoptimierung).
siehe auch hier: http://www.hilfdirselbst.ch/..._P474168.html#474168

Mich stört das schon etwas. Wo ich eben noch einen Fehler hatte mit 83 ppi bei ZIP sind nach der Transparenzreduzierung plötzlich 3200 ppi bei JPEG mit Kachelung des Bildes.

Viele Grüße

 
@Polylux
Da warst Du mal wieder schneller als ich ;o)
Trotzdem: Vielen Dank für das Vorwegnehmen der Antworten auf Olaf's Fragen. Betonen möchte ich allerdings, dass Deine Antworten und der Querverweis zu meinem "JPGmedium"-Thread allesamt auf meinen Aussagen beruhen, welche ich auf Grund meiner Praxistests gesammelt und hier publiziert habe. Möglicherweise befinde ich mich auch total auf dem Holzweg ... hatte es aber bisher immer so verstanden, dass zur Transparenzreduzierung mit Kachelung die Bilddaten zwangsläufig ent- und neukomprimiert werden müssen. Sollte dies nicht der Fall sein, bitte ich um Aufklärung.

Auch interessiert mich weiterhin die Frage, ob sich die autom. Bildoptimierung – wichtiger aber noch das daraus resultierende Hochrechnen durch die pdfToolbox – nicht doch durch bestimmte Einstellungen oder Einstellungskombinationen deaktivieren lässt?
...was nicht unbedingt heißen muss, dass ich dies im Wokflow auch tun würde ;o)
Denn wie Du mir unterstützend beigepflichtet hast, ist ein Sprung von 83 ppi auf 3200 ppi für den "normalen" Anwender so erstmal nicht nachzuvollziehen. Meine Befürchtungen hierbei gehen vor allem in Richtung beliebter, mehrfach freihändig-skalierter Transparenzeffekte, welche meiner Praxiserfahrung nach bei unglücklicher Konstellation bzw. Verzerrung beim Reduzieren zu fälschlicherweise zu niedrigen Auflösungen führen können. Hier bringt es ja nichts, die zuvor fälschlicherweise auf 83 ppi downgesampelten und somit "kaputtgerechneten" Bilder nur in der Auflösung wieder "aufzupumpen", denn die eigentlich vorhandene Qualität ging ja bereits zuvor verloren.


@Olaf
Ich möchte hier keinesfalls der pdfToolbox etwas "anlasten", vor allem nicht zu Unrecht! ...doch leider gibt es noch so ettliche Dinge, welche ich – sowohl in Sachen PDF als auch in der Funktionsweise der pdfToolbox – noch nicht verstehe. Die pdfToolbox selbst, hat mich persönlich in Sachen Funktionsumfang und Benutzerfreundlichkeit, vor allem aber auf Grund ihrer immensen Möglichkeiten mit dynamischen Prüfungen UND im Zusammenspiel mit PowerSwitch längst überzeugt! Ich denke momentan sogar daran, sämtliche im Workflow platzierten PitStop-Profile mit der pdfToolbox nachzubauen, weil mir der installierte PitStop 10-Server bisher alles andere als gierig nach verfügbarer Performance greift. Über weite Strecken nutzt er nichtmal 1 Prozent der CPU, obwohl reichlich Leistung frei ist und die zu erledigenden Aufgaben oftmals Sache von wenigen Sekunden wären, aber minutenlang ohne Fortschritt bleiben.

Auch deshalb bin ich mir heute morgen nicht mehr sicher, ob entweder mein Testrechner (bzw. seine derzeitige Installation) oder das bisher verwendete Test-PDF Ursache für die vielen Ungereimtheiten und überdurchschnittlich langen Verarbeitungszeiten sein könnten!?

Während gestern abend meine Vergleichstests zwischen JPG und ZIP noch immense Unterschiede (94 min. bei ZIP vs. 2 min. bei JPG) bei den Konvertierungszeiten zu X3 aufwiesen, scheint sich in allen heutigen Tests die Differenz eher im Rahmen zu halten (59 min. ZIP vs. 41 min. JPG).

Auch eine zweite, 64seitige Testdatei (mit knapp 285 MB als PDF 1.6 bei ZIP-Kompression) verhält sich bei der X3-Konvertierung eher analog den heutigen Ergebnissen: (6:10 min. ZIP vs. 6:00 ZIP).

Hiernach scheint es also doch nicht soo eine große Rolle zu spielen, ob die Bilddaten im Ausgangs-PDF als ZIP oder JPG vorliegen!?

Ich fürchte fast erst dann weitere Auskünfte geben zu können, wenn der Testrechner komplett neu aufgesetzt wurde.

Soweit für den Moment von mir...
Gruß Thomas

Hallo Thomas,

versuchen Sie doch einmal, bei der Korrektur "Transparenz reduzieren" die Optimierung auf "Keine" zu setzen. Dies müsste die Verarbeitungszeit deutlich reduzieren. Allerdings kann es je nach Inhalt der Dateien unter Umständen zu leichen Fragmentbildungen in den Grafiken und Bildern kommen.

Gerne würden wir Ihre 600MB-Datei auch selber einmal durchtesten, sollten Sie uns diese auf einem FTP-Server zur Verfügung stellen können wäre dies toll (wir können Ihnen auf Wunsch natürlich auch einen FTP-Zugang mailen).

Mit besten Grüßen,
Marc Heusmann.

Ich mal wieder ;o)

Zu fortgeschrittener Stunde und von zuhause aus, will ich mal versuchen die Ergebnisse meiner weiteren Performance-Tests im Telegrammstil zusammenzufassen:
Max. Verhältnis der Verarbeitungszeiten von JPG- vs. ZIP-Kompression im Ausgangs-PDF lag in meinen Tests nun bei 2:3 +++STOP+++ X3 aus PDF1.6/JPG = 60 Min., X3 aus PDF1.6/JPGmax = 40 Min. +++STOP+++ bei kleineren Ausgangs-PDFs 1.6 (ca. 285 MB) sind die Unterschiede eher marginal +++ STOP+++ X3 aus PDF1.6/JPG = 6:10 Min., X3 aus PDF1.6/JPGmax = 6:00 Min. (siehe auch Beitrag #7) +++STOP+++ Größte Zeitersparnis erziele ich momentan mit der fixen Idee, im Ausgangs-PDF keinerlei Kompression für Bilder anzuwenden +++STOP+++ d.h. Exportdauer aus ID zeitlich genau zwischen ZIP- und JPG-Kompression +++STOP+++ PDF1.6-Größe mit 1,9 GB (anstelle von 591 MB/ZIP oder 76 MB/JPGmax) jenseits von gut und böse +++STOP+++ aber die pdfToolbox freut sich, dass für die X3-Konvertierung vorab keinerlei Bilder dekomprimiert werden müssen +++STOP+++ und dankt es mir mit 600% Leistungssteigerung (10 min. anstatt 60 min. Verarbeitungszeit) bei der X3-Erstellung +++STOP+++ Der Schritt zurück (vom 1,9 GB-PDF) zum "kompakten" PDF1.6 mit gezippten Bildern, erledigt die Toolbox in nur 6 Minuten +++STOP+++ wobei die PDF1.6-Endgröße mit 716 MB unerwartet deutlich über den 519 MB liegt, welche beim Export aus ID mit gleicher Einstellung entstehen. +++STOP+++ und ich dachte bisher immer ZIP ist gleich ZIP +++STOP und ENDE des Telegramms+++

Aufgrund der letztgenannten PDF-Größenunterschiede (716 vs. 519 MB) müsste ich fast mutmaßen, dass die pdfToolbox selbst bei Durchführung eines eigens angefertigten Korrekturprofils, welches nichts anderes tun soll, als unkomprimierte Farb- und Graustufenbildern mit ZIP-Kompression zu versehen, ebenfalls Bildoptimierungen durchführt? Doch dies kann ich mir 1. nicht vorstellen und 2. kann ich im resultierenden PDF auch keinerlei Spuren in Form von veränderten Auflösungen oder Kompressionsmethoden davon finden. Auch die Bildrahmen muten in der PitStop-Konturenansicht identisch an. Doch wie lassen sich die Unterschiede in der Endgröße sonst erklären? Nutzt Indesign beim Export ein anderes ZIP-Verfahren als die pdfToolbox???
Für genauere Analysen dieser beiden PDFs reichte mir heute abend weder Zeit noch Nerven, aber ich werde morgen früh wieder am Ball sein.

Zu guter Letzt möchte ich auch Ihnen Herr Heusmann heute keinerlei Antworten schuldig bleiben:

Antwort auf [ hmh ]

versuchen Sie doch einmal, bei der Korrektur "Transparenz reduzieren" die Optimierung auf "Keine" zu setzen. Dies müsste die Verarbeitungszeit deutlich reduzieren. Allerdings kann es je nach Inhalt der Dateien unter Umständen zu leichen Fragmentbildungen in den Grafiken und Bildern kommen.

Wenn ich mich recht erinnere, hatte ich dies vor einigen Wochen schon einmal getan, bin aber aufgrund sehr augenscheinlicher Fragmentbildungen gleich wieder davon abgekommen. Müsste aber nochmal gezielt nach diesen Ergebnissen fahnden, sofern ich sie überhaupt noch auf dem Rechner habe.

Antwort auf [ hmh ]

Gerne würden wir Ihre 600MB-Datei auch selber einmal durchtesten, sollten Sie uns diese auf einem FTP-Server zur Verfügung stellen können wäre dies toll

Gerne würde ich dies tun, fürchte aber die Genehmigung seitens des Kunden nicht zu erhalten. Falls ich morgen doch etwas erreichen sollte, erhalten Sie eine Mail mit Downloadlink von mir.

Doch nun mache ich erstmal die Augen zu und wünsche allen, die dieses "Telegramm mit Überlange" noch heute lesen eine "Gute Nacht"!

Gruß Thomas

Hallo,

sind doch ein paar interessante Erkenntnisse dabei.

Zitat

Doch wie lassen sich die Unterschiede in der Endgröße sonst erklären? Nutzt Indesign beim Export ein anderes ZIP-Verfahren als die pdfToolbox???

Kennst du die Speicherprüfung in Acrobat? Da könnte man mal schauen, wie sich der Speicherbedarf der PDFs aufteilt. Zu finden im Menü Erweitert/PDF-Optimierung und dann oben rechts der Button "Speicherprüfung".

Ich weiß gar nicht, ob man die ZIP-Komprimierung unterschiedlich ausführen kann. Im Prinzip ist das doch immer ein Balanceakt zwischen max. Komprimierung und min. Rechenaufwand. Kann mich momentan beim besten Willen nicht erinnern, ob das spezielle ZIP-Packer einstellen können seit dem ich nur noch die OS-eigenen Mittel dafür verwende.

Gruß

Hallo rohrfrei.

Die Speicherprüfung kenne ich, zeigt aber mit Ausnahme der Byteanzahl für Bilder nur marginale Unterschiede (siehe Screenshot), was meiner Meinung nach wiederum bedeuten würde, dass doch in den Auflösungen Unterschiede zu finden sein müssten, da es bei ZIP ja keine unterschiedlichen Kompressionsfaktoren (im Verhältnis zur Originalgröße wie bei JPG) geben dürfte.

Leider muss ich an dieser Stelle vorerst abbrechen und mich der eiligen Produktion widmen. :o/
Ich melde mich wieder, wenn es weitere Neuigkeiten gibt.

Gruß Thomas

Zitat

da es bei ZIP ja keine unterschiedlichen Kompressionsfaktoren (im Verhältnis zur Originalgröße wie bei JPG) geben dürfte.

darauf zielte meine Überlegung ab und ein schneller Blick hier http://de.wikipedia.org/wiki/ZIP-Dateiformat bestätigt mich in meiner Vermutung
könnte ich mir schon vorstellen, dass die Programme doch unterschiedliche Packalgorithmen verwenden. Das darf man jetzt aber nicht mit den JPEG-Qualitätsstufen bei Bildern verwechseln, da ZIP ja immer verlustfrei ist. Es geht halt um ein ausgewogenes Verhältnis aus Kompressionsstufe und notwendiger Reichenleistung. Da kann es doch durchaus sein, das zwei unterschiedliche Hersteller auch unterschiedliche Strategien verfolgen.

Gruß

Antwort auf [ rohrfrei ]

Ich weiß gar nicht, ob man die ZIP-Komprimierung unterschiedlich ausführen kann. Im Prinzip ist das doch immer ein Balanceakt zwischen max. Komprimierung und min. Rechenaufwand. Kann mich momentan beim besten Willen nicht erinnern, ob das spezielle ZIP-Packer einstellen können seit dem ich nur noch die OS-eigenen Mittel dafür verwende.

Grade mal mit 7zip an einer kleinen EPS-Datei von 7,14 MB getestet,
• Kompressionsstärke "schnellste" - Dateigröße 4,60 MB - ca. 1-2 Sekunden
• Kompressionsstärke "ultra" - Dateigröße 4,45 MB - ca. 10 Sekunden

Grüße aus dem grauen Berlin

genau so war mir das im Gedächtnis, danke für die Bestätigung

Gruß

Könnte es sein, dass eine der beiden Methoden die Option implementiert hat, unbenutzte Bildteile (die also durch eine Maske verbogen werden) zu tilgen?

Hallo Thomas,

gute Idee - kann ich aber ausschließen, da im Ausgangs-PDF bereits alle Bilder auf Bildrahmen gecuttet wurden. Diejenigen Bilder, welche z.B. in wellenförmigen Bildrahmen maskiert waren, sind nach Auflösen der Masken weiterhin rechteckig, eben exakt max. Ausmaße der Welle.
Gibt es denn auch Software, welche Bilder "wellenförmig" beschneiden kann?
Selbst wenn, in meinen beiden PDFs ist dies nicht der Fall.

Gruß Thomas

Nachtrag

Nachdem mir noch eingefallen ist, dass die Acrobat-Preflightfunktion über einen tollen "Inventar-Report" verfügt, habe ich die Werte eines jeden Bildes mit einander verglichen. Ergebnis: absolut identisch.
Da verwundert es auch nicht, dass per "Alle Bilder exportieren" exakt gleich viele und gleich große TIFFs entstehen.

Ich weiß momentan wirklich nicht, wo noch noch nach Differenzen suchen soll?

Soweit mal schnell und zwischendurch...

Noch so ein Gedanke:
Vielleicht ist ja dies Funktion "Für Webanzeige optimieren" so ein Fall.
InDesign schreibt ein sauberes, optimiertes PDF und die Toolbox schreibt vielelciht nur nachträgliche Änderungen hintendran.

Grüße

Merci für diesen neuen Gedanken – aber Fehlanzeige:
Beide PDFs sind MIT schneller Webanzeige und OHNE Tags!
Auch sind keinerlei "Certified Infos" eingebettet.

Die pdfToolbox-Korrektur war NUR angewiesen alle Bilder zu zippen und wird hiervon wohl keine unkomprimierte Version als "Snapshot" aufheben ;o)

Gruß

Hello all.

Antwort auf [ Polylux ]

Noch so ein Gedanke:
Vielleicht ist ja dies Funktion "Für Webanzeige optimieren" so ein Fall.
InDesign schreibt ein sauberes, optimiertes PDF und die Toolbox schreibt vielelciht nur nachträgliche Änderungen hintendran.

Die schnelle Webanzeige an sich ist es wohl nicht; aber mit dem "sauberen" ID-PDF vs. Toolbox-PDF inkl. Snapshots scheint Polylux einen Treffer gelandet zu haben...
...denn der Vergleich zweier neuer Test-PDFs zeigt folgende Neuigkeiten:
1) PDF1.6/ZIP aus Indesign = 6,7 MB
2) PDF1.6/ohne Kompression aus Indesign = 36,4 MB
3) Im PDF1.6 aus 2) per pdfToolbox alle Bilder gezippt
4) -> PDF1.6/ZIP = 13,8 MB
5) PDF aus 4) manuell in Acrobat9 geöffnet und ohne Inhaltsänderung per "Speichern unter" mit neuem Namen abgelegt, resultiert in einem PDF1.6/ZIP mit 6,6 MB – also ganz nah an der ID-PDF-Größe!

Demnach spricht doch wieder alles für einen im PDF zwischengespeicherten Snapshot, der die Datei (in meinem Falle unnötig) aufbläst. Denn mit "normalem" Speichern und überscheiben bleibt die Größe bei 13,8 MB.

Es scheint also, als nutze die pdfToolbox nach dem Zippen der Bilder den normalen "Speichern und überschreiben"-Befehl – was ja auch nur logisch ist – gibt damit aber gleichzeitig einen Snapshot (und somit unnützen Ballast) weiter!? – Soweit meine jetzige Vermutung.

Natürlich wollte ich mir in der PowerSwitch-Umgebung nun gleich damit behelfen, das PDF (direkt nach dem ZIPPEN) per Acrobat-Konfigurator einmal Öffnen und wieder "Sichern unter" zu lassen. Dies funktioniert leider nicht: obwohl der Befehl im Menü "Sichern unter" lautet, ist hiermit wohl wiederum das normale "Speichern und Überschreiben" gemeint. Der Acrobat-Konfigurator von PowerSwitch verhält sich hier also offensichtlich anders, wie beim manuellen Bedienen einer Acrobat9-Version!?

Kann mir jemand anhand dieser neuen Erkenntnisse einen Ratschlag erteilen, wie ich am Ende des Workflows vielleicht doch noch zu einem gleich-großen PDF1.6/ZIP kommen könnte, so wie es Indesign direkt erzeugt?

MfG
Thomas

Antwort auf [ t-kittel ]

Kann mir jemand anhand dieser neuen Erkenntnisse einen Ratschlag erteilen, wie ich am Ende des Workflows vielleicht doch noch zu einem gleich-großen PDF1.6/ZIP kommen könnte, so wie es Indesign direkt erzeugt?

Das hier habe ich im Beitrag #9 gefunden:

Zitat

Abgleich (zwischen 1.6 und X3) soll ebenso vermieden werden, wie ein zweiter Exportvorgang (und die hierdurch ebenfalls erforderliche, erneute Prüfung).

Warum eigentlich nutzt du für die beiden gewünschten Zieldateien nicht jeweils den InDesign-Direktexport, also zwei Mal die Originaldaten als PDF exportieren (einmal als 1.6 und einmal als X3)?

Irgendwo habe ich gelesen, dass ein Switch im Einsatz ist. Hier hast du den InDesign Konfigurator (sofern es sich nicht um ein LightSwitch handelt) und kannst den diesen doch dann in zwei Zweigen zur Erzeugung der PDF's einbauen.
Was spricht also dagegen, so lange die pdfToolbox (leider) noch etwas langsamer ist und größere Dateien erzeugt, diesen Weg zu gehen?

Die Daten können nach dem aufgeteilten Konvertierungs-Flow (1.6 und X3) ja immer noch einer Prüfung durch die pdfToolbox unterzogen werden. Und ist das in Summe dann nicht allemal schneller als die bisher beschriebene und gewünschte Vorgehensweise?

Hallo Michael!

Antwort auf [ michimeier ]

Warum eigentlich nutzt du für die beiden gewünschten Zieldateien nicht jeweils den InDesign-Direktexport, also zwei Mal die Originaldaten als PDF exportieren (einmal als 1.6 und einmal als X3)?

Weil die Verkürzung der Zeitspanne, in denen Arbeitsplätze durch PDF-Exporte blockiert sind, ein weiteres Hauptziel und gar doppelter Export unbedingt vermieden werden soll. ...und der Hintergrundexport à la CS5 macht nur dann Sinn, wenn das nächste zu öffnende Dokument mit den gleichen, bereits offenen Schriften bearbeitet werden kann.

Antwort auf [ michimeier ]

Irgendwo habe ich gelesen, dass ein Switch im Einsatz ist. Hier hast du den InDesign Konfigurator (sofern es sich nicht um ein LightSwitch handelt) und kannst den diesen doch dann in zwei Zweigen zur Erzeugung der PDF's einbauen.
Was spricht also dagegen, ...

Momentan "nur", dass der neue - sich bereits in der Testphase befindende PDF-Workflow - eben eine ganz andere Philosophie verfolgt, nämlich die des PDF1.6 als Master aller Abformate. Doch tatsächlich ist bereits eine Zweigleisigkeit durch optionalen Einsatz des Indesign-Servers angedacht - allerdings nur für überdurchschnittlich große Jobs. Diesem ID-Server, zusätzlich zu seinen derzeitigen Aufgabengebieten, zukünftig auch noch den Export von mehr als drei Dutzend DTP-Arbeitsplätzen aufzubürden, möchte ich dieser Maschine (trotz 8 Kernen) nicht auch noch zumuten. ;o)

Antwort auf [ michimeier ]

...so lange die pdfToolbox (leider) noch etwas langsamer ist und größere Dateien erzeugt, diesen Weg zu gehen?

Durch den gänzlichen Verzicht auf Bildkompression im Quell-PDF erreiche ich mittlerweile durchaus ansehnliche Werte, so dass als letzte Hürde nur noch die Dateigrößenoptimierung gelöst werden müsste.

Ich bleibe weiter am Ball...
Gruß Thomas

@An alle Interessierten

Zum Jahresende kommt zu dem oben beschriebenen Teilproblem (größere HighRes-PDFs nach Konvertierung per pdfToolbox im Vergleich zu Indesign-Direktexport) eine für mich doch ein wenig unerwartete Wende:
Im Zusammenhang mit ausgiebigen Tests aufgrund übergroßer LowRes-PDFs (v1.6), welche durch Downsamplen mit der Toolbox erstellt wurden, hat mir der Support heute einen weiteren Bug in der aktuellen pdfToolbox 5.3 (150) bestätigt. Denn beim Downsampling von HighRes-PDFs werden zwar alle Bilder korrekt heruntergerechnet und komprimiert, dabei (aufgrund von Transparenzeffekten wie Schlagschatten, Schein nach außen oder platzierten PSDs mit Transparenz) erzeugte Bildmasken jedoch werden nicht (oder falsch) heruntergerechnet und stets ZIP-komprimiert (anstatt JPG).

In meinen Tests mit der Toolbox enstanden z.B. 15,6 MB große LowRes-PDFs, welche beim Direktexport aus Indesign CS5 (mit gleichen Einstellungen) nur 1,7 MB ergaben. Dieser immense Größenunterschied lag bei diesem großformatigen Layout in insgesamt acht Transparenzgruppen begründet, welche von Indesign korrekt heruntergerechnet und JPG-komprimiert wurden, während die pdfToolbox die Auflösung unverändert belassen und immer zur ZIP-Kompression gegriffen hatte.

Dies erklärt nun auch meine o.g. (im Vergleich zu Indesign) größeren HighRes-PDFs, deren Ursache ich anfänglich in den Metadaten und später mit Eurer Hilfe in vielen weiteren PDF-Eigenschaften gesucht hatte. Abhilfe in Form eines neuen Updates wurde in etwa für Januar'12 in Aussicht gestellt.

Nachträglich nochmals vielen Dank an alle, die sich tatkräftig an diesem Thread beteiligt hatten!

Mfg
Thomas Kittel

Antwort auf [ t-kittel ]

Dies erklärt nun auch meine o.g. (im Vergleich zu Indesign) größeren HighRes-PDFs, deren Ursache ich anfänglich in den Metadaten und später mit Eurer Hilfe in vielen weiteren PDF-Eigenschaften gesucht hatte. Abhilfe in Form eines neuen Updates wurde in etwa für Januar'12 in Aussicht gestellt.

Sehe ich das richtig? Dir wird also geholfen? Ich weiß nicht so genau, was du uns sagen willst?

Hallo "foxpalace",

ich wollte damit vor allem zwei Dinge zum Ausdruck bringen:

1. In per pdfToolbox verarbeiteten HighRes-PDFs kann die stetige Anwendung von ZIP-Kompression (anstatt JPG) für diese Transparenzmasken ebenfalls zu unnötig großen PDFs führen, wie mein Screenshot im Beitrag #16 zeigt: Acrobats Speichernutzung zeigte hier 750 MB Bildmaterial im per Toolbox gezippten PDF an, während das aus Indesign erzeugte nur 619 MB Bilddaten aufwies. Begründet eben entweder in falschem bzw. unterlassenem Downsampling oder durch Verwendung von ZIP-komprimierten Transparenzmasken.

2. Wer ebenfalls vor hat, mit Hilfe der aktuellen pdfToolbox-Version 5.3 (150) HighRes-PDFs (bei mir v1.6 mit Transparenzen) zu LowRes-PDFs (v1.6 mit Transp.) zu wandeln und dabei noch Wert auf handliche Dateigrößen legt, darf sich momentan nicht über z.T. immens große LowRes-PDFs (15,6 MB vs. 1,7 MB) wundern. In meinen Tests fiel der Unterschied vor allem in großformatigen und transparenz-lastigen PDFs sehr drastisch aus!
Mir gegenüber hat der Callas-Support die Beseitigung dieses Bugs für Jan. 2012 in Aussicht gestellt.

MfG Thomas

Zur Info an alle:
Das im vorherigen Beitrag erwähnte Dateigrößenproblem wurde mit der pdfToolbox 5.4.156 behoben.

MfG
Thomas Kittel