Hallo zusammen.

Ein Kunde hat eine Bilddatenbank mit zigtausend Produktbildern in CMYK.
Das hat auch seinen Grund. Die Produkte haben einen Schatten, der nur im Schwarz angelegt ist, um etwaige Farbschwankungen im Druck zu vermeiden.

Nun besteht die Überlegung, neue Bilder ausschließlich in RGB in die Datenbank zu stellen. Da haben wir dann nur unweigerlich die Problematik, wie man den neutralen RGB-Schatten in „nur-Schwarz“ hinbekommt, wenn die Daten nach CMYK konvertiert werden.
Auch bei einer Konvertierung mit DeviceLink-Profilen wird der CMYK-Schatten mit Buntfarben aufgebaut, wenn auch nicht so stark.

Was die Beschaffenheit der Bilder anbelangt, sind wir noch ziemlich flexibel. Das heißt, es dürfen auch RGB-Bilder mit Photoshop-Ebenen sein. Eine automatisierte Farbkonvertierung vor dem CMYK-Download könnte man auch noch mit einbauen.
Folgendes Szenario wäre so dann z.B. möglich:
- Produkt und Schatten auf 2 Ebenen verteilen
- Daten werden nach CMYK konvertiert
- Schatten-Ebene wird anschließend in „nur-Schwarz“ korrigiert
- das fertige CMYK-Bild wird zum Download zur Verfügung gestellt

Gibt es für solche Anforderungen noch einfachere Wege? Hat jemand Erfahrungen damit?
Bin für jeden Hinweis dankbar. :-)

Viele Grüße.
André Lahode

Antwort auf:

Gibt es für solche Anforderungen noch einfachere Wege?

Natürlich.

Ein Bild mit zwei grundlegend unterschiedlichen Separationscharakteristika innerhalb des Bildes geht nur als CMYK, also die Idee mit RGB Bildern in der Datenbank einfach ad acta legen.

Ansonsten: Ein langes, breites Schwarz zur Separation verwenden und den ganzen Pipifax sein lassen. Hat vor allem den Vorteil, dass nicht jeder Schwarzfehlpasser zu Abrissen des Schattens zum Objekt hin führt.

Hallo Zusammen,

wäre das nicht mal ein Einsatzgebiet für das neue "ECI-CMYK ?

Viele Grüße Peter

Guten Morgen.

Danke erstmal für die Beteiligung.

Antwort auf:

Ein Bild mit zwei grundlegend unterschiedlichen Separationscharakteristika innerhalb des Bildes geht nur als CMYK, also die Idee mit RGB Bildern in der Datenbank einfach ad acta legen.

Ansonsten: Ein langes, breites Schwarz zur Separation verwenden und den ganzen Pipifax sein lassen. Hat vor allem den Vorteil, dass nicht jeder Schwarzfehlpasser zu Abrissen des Schattens zum Objekt hin führt.

Das mit dem langen, breitem Schwarz wäre noch eine Möglichkeit, die werde ich mal mit aufnehmen.

Antwort auf:

wäre das nicht mal ein Einsatzgebiet für das neue "ECI-CMYK ?

Habe ich auch schon drüber nachgedacht. Bis dato wurde allerdings RGB als Farbraum vorgegeben, um andere Anwendungen außerhalb des Drucks zu bedienen, ohne vorher die Farben beschnitten zu haben.

Viele Grüße.
André Lahode

Antwort auf:

wäre das nicht mal ein Einsatzgebiet für das neue "ECI-CMYK ?

Grundsätzlich: Nein.

Es bringt nur eine weitere CMYK-> CMYK Transformation mit den bestehenden Problemen.

@ André: Bis zu welchen Tonwertstufen reichen die Schatten denn?

Antwort auf:

Bis dato wurde allerdings RGB als Farbraum vorgegeben, um andere Anwendungen außerhalb des Drucks zu bedienen, ohne vorher die Farben beschnitten zu haben.

Und welche Anwendungen respektive Anwender meinen denn da von unbeschnittenen Farben zu profitieren?

Wenn jetzt Web und/oder Mobile Devices kommt, muss ich mal kurz lachen. Dort ist das vorwiegende Problem nicht der beschnittene Farbraum von Print-CMYK-Datenbeständen, sondern grundsätzlich die verbindliche Farbzuordnung. Und solange die nicht klappt, ist man mit sRGB aus CMYK deutlich besser bedient als mit irgendwelchen üppigen RGB Farbräumen.


Für Print Anwendungen hätte ich noch ne Option: automatische Generierung von CMYK (freigestelltes Produkt) und Graustufenversion (mit Schattenebene). Im Layout werden dann die beiden Bilder deckungsgleich platziert, vorne die freigestellte Farbversion, hinten die SW Version die nur in den Schattenpartien hinter dem Farbbild hervorlugt.

Hallo Thomas.

Antwort auf:

@ André: Bis zu welchen Tonwertstufen reichen die Schatten denn?

Das geht bis 90%.

Antwort auf:

Und welche Anwendungen respektive Anwender meinen denn da von unbeschnittenen Farben zu profitieren?

Wenn jetzt Web und/oder Mobile Devices kommt, muss ich mal kurz lachen. Dort ist das vorwiegende Problem nicht der beschnittene Farbraum von Print-CMYK-Datenbeständen, sondern grundsätzlich die verbindliche Farbzuordnung. Und solange die nicht klappt, ist man mit sRGB aus CMYK deutlich besser bedient als mit irgendwelchen üppigen RGB Farbräumen.

Genau das ist damit gemeint. Aber ich gebe dir mit deinen Einwänden recht.
Wobei aus dem "üppigen RGB-Farbraum" auch ein sRGB für solche Fälle generiert werden würde.

Antwort auf:

Für Print Anwendungen hätte ich noch ne Option: automatische Generierung von CMYK (freigestelltes Produkt) und Graustufenversion (mit Schattenebene). Im Layout werden dann die beiden Bilder deckungsgleich platziert, vorne die freigestellte Farbversion, hinten die SW Version die nur in den Schattenpartien hinter dem Farbbild hervorlugt.

Auch eine Möglichkeit, aber mit dem Nachteil zweier Bildbestandteile.

Viele Grüße.
André Lahode

Antwort auf:

Antwort auf:

@ André: Bis zu welchen Tonwertstufen reichen die Schatten denn?

Das geht bis 90%.

Ok, dann fällt ein Buntunterstützung im Neutralgrau, die erst sehr spät einsetzt, auch keine Abhilfe. Erspart aber auch die altbekannten Probleme der Abrisse in den Tertiärfarben.

Antwort auf:

Genau das ist damit gemeint. Aber ich gebe dir mit deinen Einwänden recht.
Wobei aus dem "üppigen RGB-Farbraum" auch ein sRGB für solche Fälle generiert werden würde.

Führt aber zum alten Problem der medienneutralen Farbvorhaltung: Es gibt keinen verbindlichen, im Sinne von Medienübergreifenden Farbeindruck. Jeder macht so gut er kann ... das ist aber oft nicht die Erwartungshaltung.

Antwort auf:

Auch eine Möglichkeit, aber mit dem Nachteil zweier Bildbestandteile.

Liefert aber farbtechnisch gesehen 'normgerechtes' Material in den DruckPDFs. Das was du vorhast, geht nur solange gut, wie niemand mehr dranpackt. Wehe, da greift noch ein Inksaver ein, oder jemand meint die Druckdaten von FOGRA39 auf 51 heben zu müssen, ...


Hat der Kunde einen einzelnen Buchstaben in einem Kreis als Logo?

Hallo,

Zitat

Auch bei einer Konvertierung mit DeviceLink-Profilen wird der CMYK-Schatten mit Buntfarben aufgebaut, wenn auch nicht so stark.

im basICColor Devil kann man eine Ausnahme für R=G=B für RGB->CMYK Devicelinks machen, die dafür sorgt, dass so ein RGB-Grau nur im Schwarzkanal landet.

Und wehe im restlichen Motiv hat dann jemand mehr oder weniger präzise drauf geachtet, dass die Grauachse perfekt ist ...

Hallo Loethelm,

hm… Aber wehe R=G=B taucht auch im Motiv auf.
Was dann?

Ich habe nur die Aussage kommentiert, dass per DVL CMY ins Schwarz kommt.
Ich habe nicht behauptet, dass das eine Universallösung ist ;-)
Aber mal ehrlich: Kommt das in realen Motiven vor?

Antwort auf:

Ich habe nur die Aussage kommentiert, dass per DVL CMY ins Schwarz kommt.
Ich habe nicht behauptet, dass das eine Universallösung ist ;-)
Aber mal ehrlich: Kommt das in realen Motiven vor?

Ich hab Kunden mit Industrietechnik in Stahl und grau lackierten Oberflächen: Ja da kommt das in machen Motiven bis auf Schalter, Anzeigen und Lämpchen in 95% der Motivfläche vor.

Gut, da wär’s auch nicht so das gravierende Problem. Was problematisch wird, sind eben tertiärfarbige Motive, die um das neutralgrau herumspielen. Z.B. Besteck oder Silberschmuck (in Verbindung mit Gold, und dann die Stellen wo Gold einspiegelt und aus dem Silber was nicht mehr so neutrales macht, werden schon bei starkem GCR idR katastrophal.

André kanns ja gern mit dem dort besprochenen DVL probieren:
Farbwandlung RGB nach CMYK mit PitStop

Da wäre dann die Königslösung wohl wirklich das Trennen von Bild und Schatten.

Hallo,

und warum nicht doch ECI-CMYK?

In der Vergangenheit haben wir hier auf HDS immer viele Gegenargumente gefunden, um Bilder nicht medienneutral als RGB zu archivieren. So wie auch hier wieder einige Beispiele aus der Praxis genannt wurden. Bisher haben wir dann aber oft auch auf verfahrensangepasste CMYK-Farbräume geschielt, das aber mangels allgemeingültigem Standard verworfen oder nicht empfohlen.

Nun gibt es mit Fogra53 einen ebensolchen und es ist auch nicht korrekt? Genau für so einen Anwendungsfall wie hier ist das doch prädestiniert. Ein kostenloses DeviceLink für Konvertierung in Bogenoffset wird sogar mitgeliefert. Klar, jetzt gibt es x-fach andere Druckbedingungen, für die es eben kein fertiges DeviveLink gibt, aber ist es deshalb sofort zum Scheitern verurteilt?

Zitat

Zitat

Antwort auf:
wäre das nicht mal ein Einsatzgebiet für das neue "ECI-CMYK ?

Grundsätzlich: Nein.

Es bringt nur eine weitere CMYK-> CMYK Transformation mit den bestehenden Problemen.

welche bestehende Probleme sollen das denn sein?
CMYK-zu-CMYK-Transformation mittels guter DeviceLinks ist doch etablierter Standard. Und wenn ich mir die zusätzlichen Möglichkeiten der Rendering-Intents bei ColorLogic und Basiccolor ansehe, dann steckt da doch viel mehr Potenzial drin als die Möglichkeiten reiner ICC-Konvertierung.

Das "gut" oben ist fett, weil ich die GMG-Profile als nicht solche einschätze. Schon aufgrund der verändernden Überdrucken-Problematik. Da hätte ich von der Fogra/ECI mehr Sorgfalt erwartet. Diese zur Konvertierung eines Austauschfarbraums anzubieten ist ja fast fahrlässig für Kundendaten.

Gruß

Moin,

Antwort auf:

Ich habe nur die Aussage kommentiert, dass per DVL CMY ins Schwarz kommt.
Ich habe nicht behauptet, dass das eine Universallösung ist ;-)
Aber mal ehrlich: Kommt das in realen Motiven vor?

Wir hatten so etwas vor ca. 15 Jahren mehrfach. Verläufe aus Freehand, welche in einzelne Streifen aufgebaut waren. Bei R=G=B konnte man noch eine Toleranz eingeben von meinetwegen 2%.
Sah ziemlich beknackt aus, wenn der buntgraue Verlauf in der Mitte nur Graustufen beinhaltete. Die Funktion haben wir dann wieder deaktiviert.

Wir hatten ein Farbmanagement-Plugin über die PDFs laufen lassen, weiß nicht mehr wie das hieß. Sollte eigentlich aus Office-schwarz, richtiges machen.

Viel Grüße

Moin Thomas,

nur aus Neugier:

Wenn mich jemand nach einem Farbmanagement-Plugin fragen würde, wären Profile das einzige was mir dazu einfällt...

Kriegst Du das noch hin - zugegeben schon lange her, ich glaube vor 15 Jahren habe ich Farbmanagement immer noch weitgehenst ignoriert ;-) - in Deiner Erinnerung, um was "ungefähr" es sich dabei gehandelt haben könnte?

Gruß von der anderen Seite des Hohenschönhauser Parkplatz,

Ulrich

Guten Morgen zusammen.

Eine spannende Diskussion, die viel Input für unsere Überlegungen bietet. :-)

Antwort auf:

Liefert aber farbtechnisch gesehen 'normgerechtes' Material in den DruckPDFs. Das was du vorhast, geht nur solange gut, wie niemand mehr dranpackt. Wehe, da greift noch ein Inksaver ein, oder jemand meint die Druckdaten von FOGRA39 auf 51 heben zu müssen, ...

Das ist eine Problematik, die theoretisch in den letzten Jahren auch schon vorhanden war. Seit Ewigkeiten wurden schon CMYK-Daten mit "nur Schwarz-Schatten" ausgeliefert und führte zu keinen Problemen. Die involvierten Druckereien wissen, was sie da tun.
Von daher wäre eciCMYK sicher auch machbar. Allerdings: Die bisherigen FOGRA 39-Daten wurden für 99% aller Druckaufträge verwendet. Da sehe ich nicht den Mehrwert für einen leicht größeren Farbraum. Wenn man bei CMYK bleibt, kann man auch gleich bei FOGRA 39 bleiben.

Antwort auf:

Hat der Kunde einen einzelnen Buchstaben in einem Kreis als Logo?

Nein. :-)

Antwort auf:

André kanns ja gern mit dem dort besprochenen DVL probieren:
Farbwandlung RGB nach CMYK mit PitStop

Das hab ich jetzt mal gemacht. Für den Schatten ist das super, aber im Bild selbst gibt es doch einige Problemstellen. Schattenbereiche, die im RGB neutral sind und deswegen dort im CMY wegbrechen.
Sollte der Schatten wirklich nur schwarz sein, ist das keine Lösung. Zu unsicher.

Antwort auf:

Da wäre dann die Königslösung wohl wirklich das Trennen von Bild und Schatten.

Das wäre bisher auch mein Favorit. Wir prüfen das mal, ob die Datenbanklösung damit umgehen kann.

Viele Grüße.
André Lahode

Antwort auf:

nur aus Neugier:

Wenn mich jemand nach einem Farbmanagement-Plugin fragen würde, wären Profile das einzige was mir dazu einfällt...

Kriegst Du das noch hin - zugegeben schon lange her, ich glaube vor 15 Jahren habe ich Farbmanagement immer noch weitgehenst ignoriert ;-) - in Deiner Erinnerung, um was "ungefähr" es sich dabei gehandelt haben könnte?

Guten Morgen,
zu dieser Zeit gab es doch von Agfa was, ColorTune oder so ähnlich; soweit ich mich erinnere war diese Software bei einem Desktopscanner im Paket enthalten.
Gruss, Eric

Hallo Ulrich,

Wir haben aus den offenen Daten PostScipt-Dateien in einen Hotfolder geschrieben.
Dieser wurde vom Acrobat Distiller überwacht und hat PDF-Dateien daraus gemacht.
Diese PDF-Dateien und auch alle angelieferten wurden von callas AutoPilot überwacht und im Adobe Acrobat geöffnet und mittels des Plugins zu CMYK konvertiert.
Die angesteuerten PlugIns war Heidelberg SuperColor und SuperTrap.
Das war schon eine starke Automation.
Die fertigen PDFs wurden dann in die SignaStation 8/9 geladen und der ganze Bogen ans DeltaRIP geschickt.

Alternativ fällt mir noch das PlugIn Quite A Box of Tricks ein. Und ich glaube von Quite gab es auch ein Tool namens RGB gone später Quite Revealing.

Früher... das war so 2003-2004.

Antwort auf:

Antwort auf:

Liefert aber farbtechnisch gesehen 'normgerechtes' Material in den DruckPDFs. Das was du vorhast, geht nur solange gut, wie niemand mehr dranpackt. Wehe, da greift noch ein Inksaver ein, oder jemand meint die Druckdaten von FOGRA39 auf 51 heben zu müssen, ...

Das ist eine Problematik, die theoretisch in den letzten Jahren auch schon vorhanden war. Seit Ewigkeiten wurden schon CMYK-Daten mit "nur Schwarz-Schatten" ausgeliefert

Du scherst jetzt nicht deine Methode mit einem Bild in dem alles bis auf den Schatten gemäß eines üblichen ISOcoated V2 Profils separiert ist, und nur der Schatten rein Schwarz aufgebaut ist, mit meinem Vorschlag, der Trennung von Schaden und Motiv in 2 Bilder über einen Kamm?

In meinem Fall würde ein Inksaver oder auch eine andere ICC basierte Wandlung keinen Schaden verursachen – ausser er wäre so krank parametriert, dass Graustufenbilder in CMYK umsepariert würden - da eben die Möglichkeit besteht, Graustufen auszuschliessen, bzw. getrennt zu transformieren (nur TWZ Anpassung).

Das eigentliche Problem ist ja, dass mir keine Lösung einfällt, innerhalb eines Bildes bestimmte Bildpartien separationstechnisch anders zu behandeln als den Rest. Ausser eben noch in PS, indem man ebenenweise separiert. Und selbst das ist ja noch frickelig (Löschen der CMY-Kanäle, oder einsetzen des RGB-Schattens nach der CMYK Wandlung exklusiv in den K-Kanal …

PS: Man sollte seine Forenmails chronologisch lesen. Mein erster Blick fiel heute morgen auf Ulrichs Beitrag und ich kam mit der Plugin-Frage nicht zurecht. Aber den Vogel hat die Parkplatzgeschichte abgeschossen, da musste ich erst mal googeln und war danach immer noch nicht schlauer.

off topic:

LOL:

Antwort auf:

PS: Man sollte seine Forenmails chronologisch lesen. Mein erster Blick fiel heute morgen auf Ulrichs Beitrag und ich kam mit der Plugin-Frage nicht zurecht. Aber den Vogel hat die Parkplatzgeschichte abgeschossen, da musste ich erst mal googeln und war danach immer noch nicht schlauer.

oh, sorry, Thomas (Richard), Du musst mich für einen noch wirreren Kopf halten, als es mir selbst hin und wieder so vorkommt ;-)

Zur Aufklärung: Der Hohenschönhauser Parkplatz liegt zwischen den derzeitigen Arbeitsstätten von Kollege Thomas Nagel und mir, es hat uns mittlerweile beide näher an den Stadtrand von Berlin (in die Grenzgrabenstrasse) verschlagen, um unsere Brötchen zu verdienen, wenn auch in zwei verschiedenen Firmen...

:-)

Gruß,

Ulrich