12:04 p.m.
Hallo Arbeitskreis,
ich bin die Themensammlung gerade nochmal durchgegangen und vermisse, Angesichts der
Aufgabenstellung in nächster Zeit Bildarchive von etlichen zig-tausend Bildern zu
profilieren, vor der Frage ob es bei Profilen (insbesondre Kandidaten wie den 1,4MB
schweren ISO Profilen) wirklich Sinn macht sie komplett in die Bilder einzubetten, oder
ähnlich wie bei Schriften in Layouts auch, sie einfach zu referenzieren.
Das würde uns auf lange Sicht ähnliche Probleme mit inkonsistenten Profilnamen/-Versionen
bereiten, wie wir sie von den Schriften gewohnt sind, aber GB an redundanten Profildaten
ersparen.
Dinge wie OPI mit Laydaten, die profilierte CMYK Versionen für Farbausdrucke enthalten,
gehören in dem Zusammenhang wohl der Vergangenheit an, wenn ich dazu in Relation setze,
was man mit 1,4MB in RGB-Laydaten mit ECI-RGB Profil an Bildinformation unterbringen
kann.
Ist das relevant oder sollte man solche Ansinnen im Keim ersticken?
MfG
Thomas Richard
12:43 p.m.
Hallo Herr Richard,
die Antwort auf Ihre Frage ist letztenendes das Abwägen zwischen zwei
Werten: Plattenplatz (und damit verbundene Kosten) versus
Prozessicherheit, bzw. Farbsicherheit.
Ich nehme mal an, sie haben in Ihrem bildarchiv nicht nur Bilddateien
mit jeweils zig MB Dateigröße. Dann wäre der zusätzliche Speicherbedarf
von jeweils gut einem MB wohl ohen weiteres Nachdenken zu verkraften.
Ausreichend groß diemensionierter Speicherplatz ist sowohl technisch
als auch finanziell heutzutage nicht mehr wirklich ein Problem.
Dass der Speicherbedarf für ein kleines bild von einem MB Dateigröße
mal eben verdoppelt wird ist auf den ersten Blick natürlich fragwürdig.
Vorteil dieser Aktion ist allerdings, dass bei einer zukünftigen
*farbsicheren* Verwendung die Farbcharakterierung gleich an der Datei
hängt.
Wenn sie dieselbe Farbsicherheit über Ihr Archivsystem erreichen,
könnten Sie natürlich auch Plattenplatz dank Referenzieren in der
Datenbank sparen.
Dann sollte idealerweise beim Reaktivieren der bilddaten das
betreffende Profil wieder eingebettet werden.
Herzlichst,
Florian Süßl
Am Dienstag, 25.11.03 um 12:04 Uhr schrieb Thomas Richard:
Hallo Arbeitskreis,
ich bin die Themensammlung gerade nochmal durchgegangen und vermisse,
Angesichts der Aufgabenstellung in nächster Zeit Bildarchive von
etlichen zig-tausend Bildern zu profilieren, vor der Frage ob es bei
Profilen (insbesondre Kandidaten wie den 1,4MB schweren ISO Profilen)
wirklich Sinn macht sie komplett in die Bilder einzubetten, oder
ähnlich wie bei Schriften in Layouts auch, sie einfach zu
referenzieren.
Das würde uns auf lange Sicht ähnliche Probleme mit inkonsistenten
Profilnamen/-Versionen bereiten, wie wir sie von den Schriften gewohnt
sind, aber GB an redundanten Profildaten ersparen.
Dinge wie OPI mit Laydaten, die profilierte CMYK Versionen für
Farbausdrucke enthalten, gehören in dem Zusammenhang wohl der
Vergangenheit an, wenn ich dazu in Relation setze, was man mit 1,4MB
in RGB-Laydaten mit ECI-RGB Profil an Bildinformation unterbringen
kann.
Ist das relevant oder sollte man solche Ansinnen im Keim ersticken?
MfG
Thomas Richard
_______________________________________________
AK-Workflow mailing list
AK-Workflow(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/ak-workflow
--
Florian Suessl | Director Technology
MetaDesign AG | Leibnizstrasse 65 | 10629 Berlin
+49 30 590 054 246 | fax +49 30 590 054 114 | fsuessl(a)metadesign.de
A Lost Boys company | http://www.metadesign.de
1:47 p.m.
Hallo
Falls man Profile refernziert wäre eine Modifikation des Dateinamens
eventuell von Vorteil, damit später nicht fälschlicherweise neuere
Farbprofile mit dem selben Namen zur Anwendung kommen. Sonst haben wir
den gleichen Salat wie heute mit Schriften: "Welche meiner Helveticas
wurde zum damaligen Zeitpunkt verwendet". Ein Zeitstempel im Dateinamen
wäre mein Vorschlag.
Am 25.11.2003 um 12:43 schrieb Florian Süßl:
Wenn sie dieselbe Farbsicherheit über Ihr Archivsystem
erreichen,
könnten Sie natürlich auch Plattenplatz dank Referenzieren in der
Datenbank sparen.
Mit freundlichen Gru:ssen aus der Wachau
Peter Kleinheider
Leiter Digitaldruck und Druckvorstufe
Gugler print & media GmbH
A-3390 Melk, Pielach 101
Tel (43)(0)2752/500 50-39
Fax (43)(0)2752/500 50-7239
ISDN (43)(0)2752/500 12
Mobil (43)(0)650 /260 00 99
E-Mail: kleinheider(a)gugler.at
ftp://ftp.gugler.at
http://www.gugler.at
9:32 p.m.
Am Dienstag, 25.11.03, um 12:04 Uhr (Europe/Berlin) schrieb Thomas
Richard:
Dinge wie OPI mit Laydaten, die profilierte CMYK
Versionen für
Farbausdrucke enthalten, gehören in dem Zusammenhang wohl der
Vergangenheit an, wenn ich dazu in Relation setze, was man mit 1,4MB
in RGB-Laydaten mit ECI-RGB Profil an Bildinformation unterbringen
kann.
Am Dienstag, 25.11.03, um 12:43 Uhr (Europe/Berlin) schrieb Florian
Süßl:
Dass der Speicherbedarf für ein kleines bild von einem
MB Dateigröße
mal eben verdoppelt wird ist auf den ersten Blick natürlich
fragwürdig. Vorteil dieser Aktion ist allerdings, dass bei einer
zukünftigen *farbsicheren* Verwendung die Farbcharakterierung gleich
an der Datei hängt.
Am Dienstag, 25.11.03, um 14:27 Uhr (Europe/Berlin) schrieb Axel Faber:
Das hat den Vorteil das Sie Ihre Datenbank nicht
unnötig "aufblähen"
da die Profile nur einmal im System vorkommen und lediglich über die
Datenbanksteuerung bei Bestellung der Daten zugewiesen, gemappt oder
getagged werden.
Am Dienstag, 25.11.03, um 14:20 Uhr (Europe/Berlin) schrieb Bestmann,
Guenter 3887 S-PN-RD11:
Bei ICC-Profilen nach der aktuellen Version 4 sind im
Header bereits
Informationen zum Zeitpunkt der Erzeugung und eine Art "Stempel" in
Form einer Checksum enthalten. Diese könnte man bei Referenzierung
auslesen und mit dem Namen des Profils speichern.
-----------------------------------------------------------------
Hallo!
Zu überlegen ist, ob wir die Problematik zuerst in "kleinerem" Maße
angehen sollten, also "PDF/X-intern". Eine möglicher Lösungsvorschlag
sollte so angelegt sein, dass er auf Bild- und Objekt-Datenbanken
übertragbar ist.
Sobald es auch ohne Umwege möglich ist, Bild- und Grafikdaten korrekt
mit eingebetteten Profilen in PDF/X zu integrieren, stellt sich hier
tatsächlich die akute Frage, ob dann jedes Bild auch das entsprechende
(mit anderen übereinstimmende) Profil eingebettet haben muss. Das
Dateigrößenproblem spielt bei PDF ja eine viel größere Rolle. Man
bedenke Vektorgrafiken/Logos, die oftmals selber nur wenige KB groß
sind.***
Der Vorschlag von Herr Bestmann (Referenzierung auf die Checksum) hört
sich vielversprechend an. Es könnten innerhalb der PDF-Datei von
sämtlichen Objekten mit eingebetteten Profilen alle mindestens doppelt
vorkommenden Profile entfernt und durch Referenzierung ersetzt werden,
das Profil bekommt dann wie der Output Intent eine bestimmte Stelle
zugewiesen und wird dort gespeichert.
Zusätzlich könnte man auch Objekte leichter und platzsparender mit
Farbinformationen "taggen".
(Weiterführend könnte man das Profil / die Profile auch ausserhalb von
PDF ablegen. Die PDF bekommt dann sämtliche innerhalb vorkommenden
Referenzierungen zugewiesen, da es ausserhalb von PDF genügt, zu
wissen, welche Profile innerhalb vorkommen. Die Information über die
Zuordnung innerhalb PDF liegt dann in der PDF.)
Auftauchende Fragen: Für wie sicher schätzen wir eine solche oder
ähnliche Lösung ein? In Bezug auf PDF-intern habe ich zunächst keine
Bedenken. Eine Prüfroutine dauert oft nur wenige Sekunden (wenn
überhaupt), dann hat man alle Informationen über die vorkommenden
eingebetteten Profile. Ein dank Supercolor mögliches Entfernen von
eingebetteten Profilen geht ebenfalls sehr zügig, genauso zügig stelle
ich mir auch eine Ersetzung dieser Profile mit einer Referenzierung
vor. OPI-ähnliche Probleme könnten (theoretisch) auftreten, wenn man
Referenzierungen und die entsprechenden Profile auch "lokal"
voneinander trennt (Datenbank). Oder gibt es hier nur eine scheinbare
Parallele?
Gruß, Andre Schützenhofer
*** (Es wäre vielleicht gar nicht so abwegig, zu prüfen, ob Vektor- und
Schmuckfarbendefinitionen generell im LAB-Modus am besten aufgehoben
sind (was teilweise ja schon so gehandhabt wird). Eine "intelligente"
Umwandlung, wie auch schon in Supercolor im Ansatz sehr gut integriert,
könnte tatsächlich auch heute schon die Ideallösung sein.)
Received: from sec-mail-out02.broadnet-mediascape.de
(sec-mail-out02.broadnet-mediascape.de [62.206.1.27])
by lists.transmedia.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA12265
for <ak-workflow(a)lists.transmedia.de>de>; Thu, 27 Nov 2003 22:28:03 +0100
Received: from [192.168.1.10] (pD9E801E2.dip0.t-ipconnect.de [217.232.1.226])
by sec-mail-out02.broadnet-mediascape.de (Postfix) with ESMTP
id 1132D188014; Thu, 27 Nov 2003 23:07:48 +0100 (CET)
From: =?ISO-8859-1?Q?Olaf=20Dr=FCmmer?= <o.druemmer(a)callassoftware.com>
To: <ak-workflow(a)lists.transmedia.de>de>,
=?ISO-8859-1?Q?Andre=20Sch=FCtzenhofer?=
<a.schuetzenhofer(a)pro-con-cept.com>
Subject: Re(2): [AK-Workflow] Einbettung oder Tagging von Profilen
Date: Thu, 27 Nov 2003 22:27:59 +0100
Message-Id: <20031127212759.13601(a)sec-mail-out.broadnet-mediascape.de>
In-Reply-To: <CD738498-2118-11D8-8C2F-0003930174C4(a)pro-con-cept.com>
References: <CD738498-2118-11D8-8C2F-0003930174C4(a)pro-con-cept.com>
X-Mailer: CTM PowerMail 4.2.1 us Carbon <http://www.ctmdev.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: ak-workflow-admin(a)lists.transmedia.de
Errors-To: ak-workflow-admin(a)lists.transmedia.de
X-BeenThere: ak-workflow(a)lists.transmedia.de
X-Mailman-Version: 2.0beta2
Precedence: bulk
Reply-To: ak-workflow(a)lists.transmedia.de
List-Id: Arbeitskreis der ECI zu praktikablen Workflows auf der Basis von
ICC-Colormanagement <ak-workflow.lists.transmedia.de>
Einige Anmerkung zum Einbetten von ICC-Profile in PDF:
- ECI-RGB (gilt auch fuer andere Arbeitsraumprofile) ist ca. 500 Byte gross
- die meisten PDF-Erzeugungsapplikationen betten dasselbe ICC-Profil
selten mehr als einmal ein
- ein CMYK-Printer-Profil neigt dazu sehr gross zu sein (bis zu 1.5 MB);
da es im PDF nur als Quellprofil verwendet wird, koennte man es zu einem
Scanner-Profil umkodieren, so dass nur das je nach rendering intent
benoetigte Device-to-PCS tag enthalten ist, damit duerfte der Platzbedarf
auf wenige hundert KB schrumpfen.
- in Grafikdateien, die Schriften benoetigen, ist ungetruebtes
Produktionsgeschehen nur sichergetsellt, wenn die Schriften eingebettet
sind (je Schrift einige zig KB, bei mehreren Schriften ist man da auch
schnell bei 100 oder 200 KB).
Das Referenzieren von externen Profilen sehe ich als problematisch an,
vor allem wenn man bedenkt, dass die Daten evtl. viele Jahre lang
'halten' muessen. Nicht immer kann sichergestellt werden, dass Jahre
spaeter die noetigen Profile noch im Zugriff sind. Und wenn man Daten mit
anderen austauschen muss, muessen die Profile im Zweifelsfall eh'
eingebettet sein.
Als allgemeine Strategie scheint mir da am sinnvollsten zu sein,
bevorzugt in einem Arbeitsfarbraum Daten vorzuhalten.
Zu PDF/X:
Hier muss ein ICC-Printer-Profil (eine als Scanner-Profil abgespeckte
Variante wuerde hier nicht zulaessig sein) immer dann eingebettet sein,
wenn das PDF/X-Dokument geraeteneutrale Daten enthaelt. Fuer den Fall,
dass lediglich CMYK-Daten enthalten sind, kann man theoretisch auf das
Einbetten verzichten und lediglich auf einen Eintrag in der ICC registry
www.color.org verweisen. Bestimmte Automatismen (Proof- und
Ausgabesystem, Color-Konverter wie SuperColor oder iQueue) laufen aber
nur dann sicher, wenn das Profil enthalten ist.
Olaf Druemmer
PS: Zur Terminologie 'tagging vs. einbetten vs. ich weiss nicht was':
genau genommen gibt es z.Z. in den ueblichen Dateiformaten (TIFF, JPEG,
PDF) nur zwei Optionen
- Rohdaten ohne farbmetrische Charakterisierung; welche Charakterisierung
zutrifft, kann man sich 'merken', produktionssicher ist das allenfalls in
geschlossenen Ablaeufen
- das ICC-Profil ist eingebettet, die farbmetrische Charakterisierung ist
eindeutig zugeordnet und erreichbar.
Eine kleine Ausnahme: wie oben beschrieben, kann man in PDF/X CMYK-Daten
(und theoretisch auch RGB-Drucker-Daten) mit einem Verweis auf die ICC-
Registry charakterisieren.
11:22 p.m.
N'abend Herr Schützenhofer,
beim Lesen ihrer Anführungen stellt sich mir gerade die Frage:
Ist die Handhabung in PDFs nicht schon ein Schritt in die von mir vorgeschlagene
'Container-Lösung'?
Ist es im PDF (unabhängig von /X) so, das Profile genau wie Schriften und mehrfach
verwendete Bilder, referenziert werden?
Dann wäre das von Herrn Faber und mir angedachte Szenario im Prinzip mit der
automatisierten Erstellung eines PDFs zu erledigen, das ein Bild Pro Seite enthält, dem
der Empfänger sie entweder per 'Alle Bilder Exportieren' aus Acrobat heraus
entnimmt (wobei das bei mir immer zu RGB-Bildern mit Monitorprofil führt?) oder in
Photoshop per
Importierern - PDF Bilder (das allerdings weist CMYK Bildern, egal ob mit Profil im PDF
oder x-3 PDF immer das Arbeitsfarbraum-Profil von Photoshop zu?) einlädt.
MfG
Thomas Richard
Am Dienstag, 25.11.03, um 12:04 Uhr (Europe/Berlin)
schrieb Thomas Richard:
Dinge wie OPI mit Laydaten, die profilierte CMYK
Versionen für Farbausdrucke enthalten, gehören in dem Zusammenhang wohl der Vergangenheit
an, wenn ich dazu in Relation setze, was man mit 1,4MB in RGB-Laydaten mit ECI-RGB Profil
an Bildinformation unterbringen kann.
Am Dienstag, 25.11.03, um 12:43 Uhr (Europe/Berlin) schrieb Florian Süßl:
Dass der Speicherbedarf für ein kleines bild von
einem MB Dateigröße mal eben verdoppelt wird ist auf den ersten Blick natürlich
fragwürdig. Vorteil dieser Aktion ist allerdings, dass bei einer zukünftigen
*farbsicheren* Verwendung die Farbcharakterierung gleich an der Datei hängt.
Am Dienstag, 25.11.03, um 14:27 Uhr (Europe/Berlin) schrieb Axel Faber:
Das hat den Vorteil das Sie Ihre Datenbank nicht
unnötig "aufblähen" da die Profile nur einmal im System vorkommen und lediglich
über die Datenbanksteuerung bei Bestellung der Daten zugewiesen, gemappt oder getagged
werden.
Am Dienstag, 25.11.03, um 14:20 Uhr (Europe/Berlin) schrieb Bestmann, Guenter 3887
S-PN-RD11:
Bei ICC-Profilen nach der aktuellen Version 4 sind
im Header bereits Informationen zum Zeitpunkt der Erzeugung und eine Art
"Stempel" in Form einer Checksum enthalten. Diese könnte man bei Referenzierung
auslesen und mit dem Namen des Profils speichern.
-----------------------------------------------------------------
Hallo!
Zu überlegen ist, ob wir die Problematik zuerst in "kleinerem" Maße angehen
sollten, also "PDF/X-intern". Eine möglicher Lösungsvorschlag sollte so angelegt
sein, dass er auf Bild- und Objekt-Datenbanken übertragbar ist.
Sobald es auch ohne Umwege möglich ist, Bild- und Grafikdaten korrekt mit eingebetteten
Profilen in PDF/X zu integrieren, stellt sich hier tatsächlich die akute Frage, ob dann
jedes Bild auch das entsprechende (mit anderen übereinstimmende) Profil eingebettet haben
muss. Das Dateigrößenproblem spielt bei PDF ja eine viel größere Rolle. Man bedenke
Vektorgrafiken/Logos, die oftmals selber nur wenige KB groß sind.***
Der Vorschlag von Herr Bestmann (Referenzierung auf die Checksum) hört sich
vielversprechend an. Es könnten innerhalb der PDF-Datei von sämtlichen Objekten mit
eingebetteten Profilen alle mindestens doppelt vorkommenden Profile entfernt und durch
Referenzierung ersetzt werden, das Profil bekommt dann wie der Output Intent eine
bestimmte Stelle zugewiesen und wird dort gespeichert.
Zusätzlich könnte man auch Objekte leichter und platzsparender mit Farbinformationen
"taggen".
(Weiterführend könnte man das Profil / die Profile auch ausserhalb von PDF ablegen. Die
PDF bekommt dann sämtliche innerhalb vorkommenden Referenzierungen zugewiesen, da es
ausserhalb von PDF genügt, zu wissen, welche Profile innerhalb vorkommen. Die Information
über die Zuordnung innerhalb PDF liegt dann in der PDF.)
Auftauchende Fragen: Für wie sicher schätzen wir eine solche oder ähnliche Lösung ein? In
Bezug auf PDF-intern habe ich zunächst keine Bedenken. Eine Prüfroutine dauert oft nur
wenige Sekunden (wenn überhaupt), dann hat man alle Informationen über die vorkommenden
eingebetteten Profile. Ein dank Supercolor mögliches Entfernen von eingebetteten Profilen
geht ebenfalls sehr zügig, genauso zügig stelle ich mir auch eine Ersetzung dieser Profile
mit einer Referenzierung vor. OPI-ähnliche Probleme könnten (theoretisch) auftreten, wenn
man Referenzierungen und die entsprechenden Profile auch "lokal" voneinander
trennt (Datenbank). Oder gibt es hier nur eine scheinbare Parallele?
Gruß, Andre Schützenhofer
*** (Es wäre vielleicht gar nicht so abwegig, zu prüfen, ob Vektor- und
Schmuckfarbendefinitionen generell im LAB-Modus am besten aufgehoben sind (was teilweise
ja schon so gehandhabt wird). Eine "intelligente" Umwandlung, wie auch schon in
Supercolor im Ansatz sehr gut integriert, könnte tatsächlich auch heute schon die
Ideallösung sein.)
_______________________________________________
AK-Workflow mailing list
AK-Workflow(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/ak-workflow 
11:52 a.m.
Hallo Liste,
im Moment werden bei uns von den "PDF-Kunden" meist Einzelseiten
abgefordert, was bei einer Katalog-Produktion auch durchaus Sinn
macht. Da kommt man um eine externe Referenz wohl nicht herum. Da
wäre ein Checksum-Stempel schon deutlich besser als nur ein
Profilname.
Peter Röhl
Dunz-Wolff GmbH
---------------------------------
Feldstrasse 66 * 20359 Hamburg
Telefon: ++49 40 432 43-218
Telefax: ++49 40 432 43-100
---------------------------------
N'abend Herr Schützenhofer,
beim Lesen ihrer Anführungen stellt sich mir gerade die Frage:
Ist die Handhabung in PDFs nicht schon ein Schritt in die von mir
vorgeschlagene 'Container-Lösung'?
Ist es im PDF (unabhängig von /X) so, das Profile genau wie
Schriften und mehrfach verwendete Bilder, referenziert werden?
Dann wäre das von Herrn Faber und mir angedachte Szenario im Prinzip
mit der automatisierten Erstellung eines PDFs zu erledigen, das ein
Bild Pro Seite enthält, dem der Empfänger sie entweder per 'Alle
Bilder Exportieren' aus Acrobat heraus entnimmt (wobei das bei mir
immer zu RGB-Bildern mit Monitorprofil führt?) oder in Photoshop per
Importierern - PDF Bilder (das allerdings weist CMYK Bildern, egal
ob mit Profil im PDF oder x-3 PDF immer das Arbeitsfarbraum-Profil
von Photoshop zu?) einlädt.
MfG
Thomas Richard
--
Am Dienstag, 25.11.03, um 12:04 Uhr
(Europe/Berlin) schrieb Thomas Richard:
_______________________________________________
AK-Workflow mailing list
AK-Workflow(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/ak-workflow Dinge wie OPI mit Laydaten, die profilierte CMYK
Versionen für
Farbausdrucke enthalten, gehören in dem Zusammenhang wohl der
Vergangenheit an, wenn ich dazu in Relation setze, was man mit
1,4MB in RGB-Laydaten mit ECI-RGB Profil an Bildinformation
unterbringen kann.
Am Dienstag, 25.11.03, um 12:43 Uhr (Europe/Berlin) schrieb Florian Süßl:
Dass der Speicherbedarf für ein kleines bild von
einem MB
Dateigröße mal eben verdoppelt wird ist auf den ersten Blick
natürlich fragwürdig. Vorteil dieser Aktion ist allerdings, dass
bei einer zukünftigen *farbsicheren* Verwendung die
Farbcharakterierung gleich an der Datei hängt.
Am Dienstag, 25.11.03, um 14:27 Uhr (Europe/Berlin) schrieb Axel Faber:
Das hat den Vorteil das Sie Ihre Datenbank nicht
unnötig
"aufblähen" da die Profile nur einmal im System vorkommen und
lediglich über die Datenbanksteuerung bei Bestellung der Daten
zugewiesen, gemappt oder getagged werden.
Am Dienstag, 25.11.03, um 14:20 Uhr (Europe/Berlin) schrieb
Bestmann, Guenter 3887 S-PN-RD11:
Bei ICC-Profilen nach der aktuellen Version 4 sind
im Header
bereits Informationen zum Zeitpunkt der Erzeugung und eine Art
"Stempel" in Form einer Checksum enthalten. Diese könnte man bei
Referenzierung auslesen und mit dem Namen des Profils speichern.
-----------------------------------------------------------------
Hallo!
Zu überlegen ist, ob wir die Problematik zuerst in "kleinerem" Maße
angehen sollten, also "PDF/X-intern". Eine möglicher
Lösungsvorschlag sollte so angelegt sein, dass er auf Bild- und
Objekt-Datenbanken übertragbar ist.
Sobald es auch ohne Umwege möglich ist, Bild- und Grafikdaten
korrekt mit eingebetteten Profilen in PDF/X zu integrieren, stellt
sich hier tatsächlich die akute Frage, ob dann jedes Bild auch das
entsprechende (mit anderen übereinstimmende) Profil eingebettet
haben muss. Das Dateigrößenproblem spielt bei PDF ja eine viel
größere Rolle. Man bedenke Vektorgrafiken/Logos, die oftmals selber
nur wenige KB groß sind.***
Der Vorschlag von Herr Bestmann (Referenzierung auf die Checksum)
hört sich vielversprechend an. Es könnten innerhalb der PDF-Datei
von sämtlichen Objekten mit eingebetteten Profilen alle mindestens
doppelt vorkommenden Profile entfernt und durch Referenzierung
ersetzt werden, das Profil bekommt dann wie der Output Intent eine
bestimmte Stelle zugewiesen und wird dort gespeichert.
Zusätzlich könnte man auch Objekte leichter und platzsparender mit
Farbinformationen "taggen".
(Weiterführend könnte man das Profil / die Profile auch ausserhalb
von PDF ablegen. Die PDF bekommt dann sämtliche innerhalb
vorkommenden Referenzierungen zugewiesen, da es ausserhalb von PDF
genügt, zu wissen, welche Profile innerhalb vorkommen. Die
Information über die Zuordnung innerhalb PDF liegt dann in der PDF.)
Auftauchende Fragen: Für wie sicher schätzen wir eine solche oder
ähnliche Lösung ein? In Bezug auf PDF-intern habe ich zunächst
keine Bedenken. Eine Prüfroutine dauert oft nur wenige Sekunden
(wenn überhaupt), dann hat man alle Informationen über die
vorkommenden eingebetteten Profile. Ein dank Supercolor mögliches
Entfernen von eingebetteten Profilen geht ebenfalls sehr zügig,
genauso zügig stelle ich mir auch eine Ersetzung dieser Profile mit
einer Referenzierung vor. OPI-ähnliche Probleme könnten
(theoretisch) auftreten, wenn man Referenzierungen und die
entsprechenden Profile auch "lokal" voneinander trennt (Datenbank).
Oder gibt es hier nur eine scheinbare Parallele?
Gruß, Andre Schützenhofer
*** (Es wäre vielleicht gar nicht so abwegig, zu prüfen, ob Vektor-
und Schmuckfarbendefinitionen generell im LAB-Modus am besten
aufgehoben sind (was teilweise ja schon so gehandhabt wird). Eine
"intelligente" Umwandlung, wie auch schon in Supercolor im Ansatz
sehr gut integriert, könnte tatsächlich auch heute schon die
Ideallösung sein.)
_______________________________________________
AK-Workflow mailing list
AK-Workflow(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/ak-workflow
12:31 a.m.
Am Donnerstag, 27.11.03, um 23:22 Uhr (Europe/Berlin) schrieb Thomas
Richard:
N'abend Herr Schützenhofer,
beim Lesen ihrer Anführungen stellt sich mir gerade die Frage:
Ist die Handhabung in PDFs nicht schon ein Schritt in die von mir
vorgeschlagene 'Container-Lösung'?
Die Prinzipien sind ähnlich. Diese und auch Ihre Container-Lösung
gleichen einer Kompression-Routine mit Sammlung in einem "Archiv" oder
"Container". Mehrfach vorkommende Elemente werden durch kurze Verweise
ersetzt, bei der Extraktion wird das ganze wieder rückgängig gemacht.
Ist es im PDF (unabhängig von /X) so, das Profile
genau wie Schriften
und mehrfach verwendete Bilder, referenziert werden?
Dann wäre das von Herrn Faber und mir angedachte Szenario im Prinzip
mit der automatisierten Erstellung eines PDFs zu erledigen, das ein
Bild Pro Seite enthält, dem der Empfänger sie entweder per 'Alle
Bilder Exportieren' aus Acrobat heraus entnimmt (wobei das bei mir
immer zu RGB-Bildern mit Monitorprofil führt?) oder in Photoshop per
Importierern - PDF Bilder (das allerdings weist CMYK Bildern, egal ob
mit Profil im PDF oder x-3 PDF immer das Arbeitsfarbraum-Profil von
Photoshop zu?) einlädt.
Yes. Allerdings müsste dazu Acrobat die Bilddaten 1:1 exportieren
können und zusätzlich mit dem entsprechenden Profil versehen (ohne
Änderung des Erstellungsdatums) sowie Photoshop müsste in der Lage
sein, den Output Intent bzw. das entsprechende Profil zu erkennen.
Gruß, Andre Schützenhofer
MfG
Thomas Richard
PRO·CON·CEPT GmbH - production and consulting by concept
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Standort Köln: Ehrenstraße 88 · 50672 Köln
phone|fax: +49 (0) 221 - 255 254 | cell +49 (0) 172 - 21 28 104
j.erpenbach(a)pro-con-cept.com
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Standort Langenfeld: Kronprinzstraße 54 · 40764 Langenfeld
tele +49 (0) 2173-3993 phone +363 fax +308 | cell +49 (0) 172-208 32 73
a.schuetzenhofer(a)pro-con-cept.com
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
http://www.pro-con-cept.com · info(a)pro-con-cept.com
Am Dienstag, 25.11.03, um 12:04 Uhr
(Europe/Berlin) schrieb Thomas
Richard:
_______________________________________________
AK-Workflow mailing list
AK-Workflow(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/ak-workflow
Dinge wie OPI mit Laydaten, die profilierte CMYK
Versionen für
Farbausdrucke enthalten, gehören in dem Zusammenhang wohl der
Vergangenheit an, wenn ich dazu in Relation setze, was man mit 1,4MB
in RGB-Laydaten mit ECI-RGB Profil an Bildinformation unterbringen
kann.
Am Dienstag, 25.11.03, um 12:43 Uhr (Europe/Berlin) schrieb Florian
Süßl:
Dass der Speicherbedarf für ein kleines bild von
einem MB Dateigröße
mal eben verdoppelt wird ist auf den ersten Blick natürlich
fragwürdig. Vorteil dieser Aktion ist allerdings, dass bei einer
zukünftigen *farbsicheren* Verwendung die Farbcharakterierung gleich
an der Datei hängt.
Am Dienstag, 25.11.03, um 14:27 Uhr (Europe/Berlin) schrieb Axel
Faber:
Das hat den Vorteil das Sie Ihre Datenbank nicht
unnötig "aufblähen"
da die Profile nur einmal im System vorkommen und lediglich über die
Datenbanksteuerung bei Bestellung der Daten zugewiesen, gemappt oder
getagged werden.
Am Dienstag, 25.11.03, um 14:20 Uhr (Europe/Berlin) schrieb Bestmann,
Guenter 3887 S-PN-RD11:
Bei ICC-Profilen nach der aktuellen Version 4
sind im Header bereits
Informationen zum Zeitpunkt der Erzeugung und eine Art "Stempel" in
Form einer Checksum enthalten. Diese könnte man bei Referenzierung
auslesen und mit dem Namen des Profils speichern.
-----------------------------------------------------------------
Hallo!
Zu überlegen ist, ob wir die Problematik zuerst in "kleinerem" Maße
angehen sollten, also "PDF/X-intern". Eine möglicher Lösungsvorschlag
sollte so angelegt sein, dass er auf Bild- und Objekt-Datenbanken
übertragbar ist.
Sobald es auch ohne Umwege möglich ist, Bild- und Grafikdaten korrekt
mit eingebetteten Profilen in PDF/X zu integrieren, stellt sich hier
tatsächlich die akute Frage, ob dann jedes Bild auch das
entsprechende (mit anderen übereinstimmende) Profil eingebettet haben
muss. Das Dateigrößenproblem spielt bei PDF ja eine viel größere
Rolle. Man bedenke Vektorgrafiken/Logos, die oftmals selber nur
wenige KB groß sind.***
Der Vorschlag von Herr Bestmann (Referenzierung auf die Checksum)
hört sich vielversprechend an. Es könnten innerhalb der PDF-Datei von
sämtlichen Objekten mit eingebetteten Profilen alle mindestens
doppelt vorkommenden Profile entfernt und durch Referenzierung
ersetzt werden, das Profil bekommt dann wie der Output Intent eine
bestimmte Stelle zugewiesen und wird dort gespeichert.
Zusätzlich könnte man auch Objekte leichter und platzsparender mit
Farbinformationen "taggen".
(Weiterführend könnte man das Profil / die Profile auch ausserhalb
von PDF ablegen. Die PDF bekommt dann sämtliche innerhalb
vorkommenden Referenzierungen zugewiesen, da es ausserhalb von PDF
genügt, zu wissen, welche Profile innerhalb vorkommen. Die
Information über die Zuordnung innerhalb PDF liegt dann in der PDF.)
Auftauchende Fragen: Für wie sicher schätzen wir eine solche oder
ähnliche Lösung ein? In Bezug auf PDF-intern habe ich zunächst keine
Bedenken. Eine Prüfroutine dauert oft nur wenige Sekunden (wenn
überhaupt), dann hat man alle Informationen über die vorkommenden
eingebetteten Profile. Ein dank Supercolor mögliches Entfernen von
eingebetteten Profilen geht ebenfalls sehr zügig, genauso zügig
stelle ich mir auch eine Ersetzung dieser Profile mit einer
Referenzierung vor. OPI-ähnliche Probleme könnten (theoretisch)
auftreten, wenn man Referenzierungen und die entsprechenden Profile
auch "lokal" voneinander trennt (Datenbank). Oder gibt es hier nur
eine scheinbare Parallele?
Gruß, Andre Schützenhofer
*** (Es wäre vielleicht gar nicht so abwegig, zu prüfen, ob Vektor-
und Schmuckfarbendefinitionen generell im LAB-Modus am besten
aufgehoben sind (was teilweise ja schon so gehandhabt wird). Eine
"intelligente" Umwandlung, wie auch schon in Supercolor im Ansatz
sehr gut integriert, könnte tatsächlich auch heute schon die
Ideallösung sein.)
_______________________________________________
AK-Workflow mailing list
AK-Workflow(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/ak-workflow 
2:27 p.m.
Hallo Herr Richard,
Ich denke die Königslösung ist: Die Daten in der Datenbank
medienneutral vorzuhalten und dem Kunden vor der Datenbestellung
(Download) zwei Möglichkeiten, automatisiert, zur Verfügung zu stellen:
1). Farbraumtransformation in den vom Kunden gewünschten Farbraum. (Für
die Kunden die wissen was sie wollen)
2). Taggen der gewünschten Daten, entweder mit dem vom Kunden
ausgewählten Profil oder bei keiner Kunden
angabe den ISOstandard "antaggen".
Das hat den Vorteil das Sie Ihre Datenbank nicht unnötig "aufblähen" da
die Profile nur einmal im System vorkommen und lediglich über die
Datenbanksteuerung bei Bestellung der Daten zugewiesen, gemappt oder
getagged werden.
Viele Grüsse aus Hamburg
Am Dienstag, 25.11.03, um 12:04 Uhr (Europe/Berlin) schrieb Thomas
Richard:
Hallo Arbeitskreis,
ich bin die Themensammlung gerade nochmal durchgegangen und vermisse,
Angesichts der Aufgabenstellung in nächster Zeit Bildarchive von
etlichen zig-tausend Bildern zu profilieren, vor der Frage ob es bei
Profilen (insbesondre Kandidaten wie den 1,4MB schweren ISO Profilen)
wirklich Sinn macht sie komplett in die Bilder einzubetten, oder
ähnlich wie bei Schriften in Layouts auch, sie einfach zu
referenzieren.
Das würde uns auf lange Sicht ähnliche Probleme mit inkonsistenten
Profilnamen/-Versionen bereiten, wie wir sie von den Schriften gewohnt
sind, aber GB an redundanten Profildaten ersparen.
Dinge wie OPI mit Laydaten, die profilierte CMYK Versionen für
Farbausdrucke enthalten, gehören in dem Zusammenhang wohl der
Vergangenheit an, wenn ich dazu in Relation setze, was man mit 1,4MB
in RGB-Laydaten mit ECI-RGB Profil an Bildinformation unterbringen
kann.
Ist das relevant oder sollte man solche Ansinnen im Keim ersticken?
MfG
Thomas Richard
_______________________________________________
AK-Workflow mailing list
AK-Workflow(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/ak-workflow
Mit freundlichen Grüßen,
Axel Faber, Geschäftsführer
FaberPublish GmbH
Cross Media Publishing
Friedensallee 120
22763 Hamburg
Tel: 040/88 91 91 30
Fax: 040/88 91 91 40
Mobil: 0172/404 9000
e-mail: a.faber(a)faberpublish.de
3:48 p.m.
Hallo Herr Faber,
Ich darf dann mal Axel Faber zitieren, der sich
am 25.11.03, gegen 14:27 +0100, folgendermaßen
äußerte:
Hallo Herr Richard,
Ich denke die Königslösung ist: Die Daten in der
Datenbank medienneutral vorzuhalten und dem
Kunden vor der Datenbestellung (Download) zwei
Möglichkeiten, automatisiert, zur Verfügung zu
stellen:
1). Farbraumtransformation in den vom Kunden
gewünschten Farbraum. (Für die Kunden die wissen
was sie wollen)
2). Taggen der gewünschten Daten, entweder mit
dem vom Kunden ausgewählten Profil oder bei
keiner Kunden
angabe den ISOstandard "antaggen".
Das hat den Vorteil das Sie Ihre Datenbank nicht
unnötig "aufblähen" da die Profile nur einmal im
System vorkommen und lediglich über die
Datenbanksteuerung bei Bestellung der Daten
zugewiesen, gemappt oder getagged werden.
Hier wäre in dem Zusammenhang zu klären, was jetzt was genau ist.
Nach meinem Wissen/Bergriffsgebrauch:
'zugewiesen': Wie beim öffnen in Photoshop, bzw.
dem photoshop'schen Befehl 'Profil zuweisen'.
Dem Bild wird ein Profil beigelegt das für
weitere Operationen als Referenz dient.
'gemappt' gemapt, oder gemapped?
Analog dem photoshop'schen 'in Profil
konvertieren'. UND anschliessende Einbettung.
'getagged', getagt oder getaggt, oder?
Das Bild enthält kein Profil sondern nur eine
Referenz auf das verwendete Separationsprofil
bzw. zu verwendende Profil, nebst
Versionsnummer, wie sie Postscript Schriften ja
auch zur Verfügung stellen, aber nicht oder nur
völlig verwirrend eingesetzt werden, analog dazu
ein Stempel oder eine Kennung.
Getagged wird aber auch für 'zugewiesen' verwendet.
Im Zusammenhang mit der Diskussion letzte Woche
im ECI Forum wäre in dem Zusammenhang ja auch
noch eine Referenz auf einen Ursprungsfarbraum
(darum ging es glaub ich bei den Inverse
und Expansion Gamut Mappings) um evtl. in kleine
Farbräume gestauchte Daten wieder aufzupumpen.
Im Vergleich zu völlig sinnfreiem heraufsetzen
des Qualitätsfaktors, sehe ich da in Bezug auf
die Farbkonsistenz (bei perzetiven RI)
theoretisch einen Sinn drin.
MfG
Thomas Richard
4:27 p.m.
Hallo Herr Richard,
Da haben Sie sicherlich recht. Der klare und sichere Umgang mit diesen
"Fachbegriffen" ist unbedingt Voraussetzung für eine perfekte
Kommunikation. Dennoch denke ich ist doch relativ klar zu verstehen was
ich mit meinem Vorschlag gemeint habe, oder? ;0)
Was halten Sie denn von meinem Vorschlag?
Gruss Axel Faber
Am Dienstag, 25.11.03, um 15:48 Uhr (Europe/Berlin) schrieb Thomas
Richard:
Hallo Herr Faber,
Ich darf dann mal Axel Faber zitieren, der sich am 25.11.03, gegen
14:27 +0100, folgendermaßen äußerte:
Hallo Herr Richard,
Ich denke die Königslösung ist: Die Daten in der Datenbank
medienneutral vorzuhalten und dem Kunden vor der Datenbestellung
(Download) zwei Möglichkeiten, automatisiert, zur Verfügung zu > stellen:
1). Farbraumtransformation in den vom Kunden gewünschten Farbraum.
(Für die Kunden die wissen was sie wollen)
2). Taggen der gewünschten Daten, entweder mit dem vom Kunden
ausgewählten Profil oder bei keiner Kunden
angabe den ISOstandard "antaggen".
Das hat den Vorteil das Sie Ihre Datenbank nicht unnötig "aufblähen"
da die Profile nur einmal im System vorkommen und lediglich über die
Datenbanksteuerung bei Bestellung der Daten zugewiesen, gemappt oder
getagged werden.
Hier wäre in dem Zusammenhang zu klären, was jetzt was genau ist.
Nach meinem Wissen/Bergriffsgebrauch:
'zugewiesen': Wie beim öffnen in Photoshop, bzw. dem photoshop'schen
Befehl 'Profil zuweisen'.
Dem Bild wird ein Profil beigelegt das für weitere Operationen als
Referenz dient.
'gemappt' gemapt, oder gemapped?
Analog dem photoshop'schen 'in Profil konvertieren'. UND
anschliessende Einbettung.
'getagged', getagt oder getaggt, oder?
Das Bild enthält kein Profil sondern nur eine Referenz auf das
verwendete Separationsprofil bzw. zu verwendende Profil, nebst
Versionsnummer, wie sie Postscript Schriften ja auch zur Verfügung
stellen, aber nicht oder nur völlig verwirrend eingesetzt werden,
analog dazu ein Stempel oder eine Kennung.
Getagged wird aber auch für 'zugewiesen' verwendet.
Im Zusammenhang mit der Diskussion letzte Woche im ECI Forum wäre in
dem Zusammenhang ja auch noch eine Referenz auf einen
Ursprungsfarbraum (darum ging es glaub ich bei den Inverse
und Expansion Gamut Mappings) um evtl. in kleine Farbräume gestauchte
Daten wieder aufzupumpen.
Im Vergleich zu völlig sinnfreiem heraufsetzen des Qualitätsfaktors,
sehe ich da in Bezug auf die Farbkonsistenz (bei perzetiven RI)
theoretisch einen Sinn drin.
MfG
Thomas Richard
7:42 p.m.
Hallo Herr Faber,
Hallo Herr Richard,
Da haben Sie sicherlich recht. Der klare und
sichere Umgang mit diesen "Fachbegriffen" ist
unbedingt Voraussetzung für eine perfekte
Kommunikation. Dennoch denke ich ist doch
relativ klar zu verstehen was ich mit meinem
Vorschlag gemeint habe, oder? ;0)
Doch war es. Da ja alle drei Varianten vorkamen.
Was halten Sie denn von meinem Vorschlag?
Für einen konkreten Workflow durchaus eine
Lösung, aber gerade in Sachen downloads hat es
doch etwas Schildbürgerhaftes:
zu 1)Der Kunde bestellt Bilder in einem, ihm
gefälligen Farbraum (wofür er dann sicher auch
ein Profil hat), und man schickt ihm zum Dank
dafür, mit jedem Bild eben dieses Profi nochmal.
zu 2) Dito, nur das eben nicht das gewünschte,
sondern ein vorgegebenes Profil x-mal durch die
Leitung muss.
Geradewegs absurd scheint mir der Vorschlag bei
ECI RGB Bildern. Diese von 3 auf 4 Kanäle
hochzurechnen um ihnen dabei noch ein um den
Faktor 400 größeres Profil aufzubürden, BEVOR man
es verschickt.
Ich weiss ja nicht, aber Sie wollten meine Meinung ;-)
Clever fände ich in dem Zusammenhang ein
Packprogramm, das die Daten ihrer redundanten
Profile entledigt, die komplette Bestellung
nebst der benötigten Profile in einen Container
verfrachtet und beim Empfänger per Doppelklick
wieder in einen Ordner voll profilierter Bilder
wandelt.
Jetzt sagen sie nicht, dass das kompliziert wäre,
so wandert zur Zeit jede unter Mac OS X
entstandene Datei zu OS9 Empfängern durchs Netz;
Stichwort Ressourcefork.
MfG
Thomas Richard
Gruss Axel Faber
Am Dienstag, 25.11.03, um 15:48 Uhr (Europe/Berlin) schrieb Thomas Richard:
>Hallo Herr Faber,
>
>Ich darf dann mal Axel Faber zitieren, der sich
>am 25.11.03, gegen 14:27 +0100, folgendermaßen
>äußerte:
>
>Hallo Herr Richard,
>
>Ich denke die Königslösung ist: Die Daten in
>der Datenbank medienneutral vorzuhalten und dem
>Kunden vor der Datenbestellung (Download) zwei
>Möglichkeiten, automatisiert, zur Verfügung zu
>stellen:
>
>1). Farbraumtransformation in den vom Kunden
>gewünschten Farbraum. (Für die Kunden die
>wissen was sie wollen)
>
>2). Taggen der gewünschten Daten, entweder mit
>dem vom Kunden ausgewählten Profil oder bei
>keiner Kunden
>
> angabe den ISOstandard "antaggen".
>
>Das hat den Vorteil das Sie Ihre Datenbank
>nicht unnötig "aufblähen" da die Profile nur
>einmal im System vorkommen und lediglich über
>die Datenbanksteuerung bei Bestellung der Daten
>zugewiesen, gemappt oder getagged werden.
>
>
>Hier wäre in dem Zusammenhang zu klären, was jetzt was genau ist.
>Nach meinem Wissen/Bergriffsgebrauch:
>
>'zugewiesen': Wie beim öffnen in Photoshop,
>bzw. dem photoshop'schen Befehl 'Profil
>zuweisen'.
>Dem Bild wird ein Profil beigelegt das für
>weitere Operationen als Referenz dient.
>
>'gemappt' gemapt, oder gemapped?
>Analog dem photoshop'schen 'in Profil
>konvertieren'. UND anschliessende Einbettung.
>
>'getagged', getagt oder getaggt, oder?
>Das Bild enthält kein Profil sondern nur eine
>Referenz auf das verwendete Separationsprofil
>bzw. zu verwendende Profil, nebst
>Versionsnummer, wie sie Postscript Schriften ja
>auch zur Verfügung stellen, aber nicht oder nur
>völlig verwirrend eingesetzt werden, analog
>dazu ein Stempel oder eine Kennung.
>
>Getagged wird aber auch für 'zugewiesen' verwendet.
>
>Im Zusammenhang mit der Diskussion letzte Woche
>im ECI Forum wäre in dem Zusammenhang ja auch
>noch eine Referenz auf einen Ursprungsfarbraum
>(darum ging es glaub ich bei den Inverse
> und Expansion Gamut Mappings) um evtl. in
>kleine Farbräume gestauchte Daten wieder
>aufzupumpen.
>Im Vergleich zu völlig sinnfreiem heraufsetzen
>des Qualitätsfaktors, sehe ich da in Bezug auf
>die Farbkonsistenz (bei perzetiven RI)
>theoretisch einen Sinn drin.
>
>MfG
>
>Thomas Richard
7480
days inactive
7483
days old
ak-workflow@lists.callassoftware.com
10 comments
6 participants
participants (6)
-
Andre Schützenhofer -
Axel Faber -
Florian Süßl -
Peter Kleinheider -
Peter Röhl -
Thomas Richard