Hallo liebe Kollegen,
ohne euch unseren ganzen Farbworkflow aufbinden zu wollen, möchte ich hier eine möglichst präzise Frage stellen:

Wir werden zukünftig (endlich) komplett auf einen RGB-Workflow mit eciRGB_v2_ICCv4.icc als Arbeitsfarbraum umsteigen. In unserer Datenbank werden unzählige Produktbilder als jpgs mit eingebettetem eciRGB_v2_ICCv4.icc Profil abgelegt sein.

Bisher verwendeten wir für Webbilder immer sRGB, da der Farbraum für die ohnehin extrem unkontrollierbare Webanzeige ausreichend ist.
Welche Nachteile könnte es geben, wenn wir zukünftig jpgs mit eingebettetem eciRGB_v2_ICCv4.icc [über ein Content Management System (reddot)] online veröffentlichen?

Meine Frage bezieht sich insbesondere auf folgende Punkte:
- größere Dateigröße?
- Probleme in älteren Browsern?
- Verlust an Farbtreue bei bestimmten Benutzergruppen?
- Schlechtere Darstellung von Verläufen oder sonstigen Spezialfällen?
- Möglicher Gewinn an Farbtreue bei Benutzern mit guten (kalibrierten) Bildschirmen und Browsern die icc-Profile unterstützen (z.B. aktuelle Firefox)?


Seht ihr ein Problem?
Ich sehe jedenfalls keinen Grund, nur für Web die hochwertig profilierten eciRGB_v2_ICCv4.icc-jpgs auf sRGB zu beschneiden (Zusatzaufwand bei der Derivaterzeugung für die Website).

Ich freue mich über eure Meinungen!
Vielen Dank,
Matthias

[Ich hoffe der Post ist hier richtig? Irgendwie gehört er ja eher in Web, aber für mich als Printler gehts ja auch um CMS allgemein... ggf. bitte einfach verschieben.]

Antwort auf [ vaude_ml ]

Welche Nachteile könnte es geben, wenn wir zukünftig jpgs mit eingebettetem eciRGB_v2_ICCv4.icc [über ein Content Management System (reddot)] online veröffentlichen?

Meine Frage bezieht sich insbesondere auf folgende Punkte:
- größere Dateigröße?

Wohl kaum, das Adobe'sche sRGB ist 4KB groß, ECI RGBv2_ICCv4 ist nur 700 Bytes groß.

Antwort auf [ vaude_ml ]

- Probleme in älteren Browsern?

Nicht nur älteren. Eigentlich alles was nicht FF oder Safari ist. In eurem Konkreten Fall sogar nur Safari.

Antwort auf [ vaude_ml ]

- Verlust an Farbtreue bei bestimmten Benutzergruppen?

Verlust würde ich nicht sagen, aber auf jeden Fall kein Gewinn bei denen die entweder alle anhängenden Profile verwerfen oder den eigenen Workflow CM-mässig anderweitig nicht im Griff haben.

Antwort auf [ vaude_ml ]

- Schlechtere Darstellung von Verläufen oder sonstigen Spezialfällen?

Kann vorkommen, der große ECI RGB Gamut macht das Mapping auf kleinere CMYK oder RGB Farbräume natürlich nicht leichter. Nach dem Motto 'wehret den Anfängen wäre da die Verteilung von sRGB Bildern der eindeutig sicherere Weg, da habt ihr in der Hand was wegfliegt und könnt evtl. noch korrigierend eingreifen.

Antwort auf [ vaude_ml ]

- Möglicher Gewinn an Farbtreue bei Benutzern mit guten (kalibrierten) Bildschirmen und Browsern die icc-Profile unterstützen (z.B. aktuelle Firefox)?

Nein, wenn überhaupt nur bei älterem FF (3.0 irgendwas mit aktiviertem CM) Der aktuellen FF kann wegen des Wechsels der internen CMS Engine von littlecms auf qcms nicht mehr mit Tabellen und auch nicht mit ICC V4 Profilen umgehen.

Antwort auf [ vaude_ml ]

Seht ihr ein Problem?
Ich sehe jedenfalls keinen Grund, nur für Web die hochwertig profilierten eciRGB_v2_ICCv4.icc-jpgs auf sRGB zu beschneiden (Zusatzaufwand bei der Derivaterzeugung für die Website).

Wenn du eh wandelst, kannst du fürs web auch ins wesentlich funktionsfähigere sRGB wandeln. Zumal png oder html Farben eh, wenn überhaupt auf sRGB gematched werden.
CMS im Web funktioniert, wenn überhaupt mit sRGB. Alles andere ist was für geschlossene Gruppen, aber nicht für die Freie Wildbahn.

Hallo Thomas,
Vielen Dank für deine schnelle und sehr kompetente Antwort!

Alles klar, in diesem Fall werden wir unseren Workflow um den Ausgabefarbraum
sRGB IEC61966-2.1
für Web ergänzen.

Für mich heißt das, dass die PS-Aktionen, die derzeit zur Deriavterzeugung der Webbilder verwendet werden, entsprechend angepasst werden müssen. Danach sollte alles problemlos weiterlaufen.

Insbesondere dein letztes Argument hat mich schnell überzeugt:

Zitat

Zumal png oder html Farben eh, wenn überhaupt auf sRGB gematched werden

Hätte ich eciRGB für die Webbilder verwendet, hätte mein Weblayout an Stellen, wo Bilder auf farbige Hintergründe treffen, "Risse" bekommen; Logofarben in Text (CSS) und Bild hätten evtl. stark unterschiedlich ausgesehen, richtig?

Danke, ihr habt mir mal wieder super weitergeholfen!
Tolles Forum!
Schöne Grüße,
Matthias

Antwort auf [ vaude_ml ]

Hätte ich eciRGB für die Webbilder verwendet, hätte mein Weblayout an Stellen, wo Bilder auf farbige Hintergründe treffen, "Risse" bekommen; Logofarben in Text (CSS) und Bild hätten evtl. stark unterschiedlich ausgesehen, richtig?

Richtig!

Versuch macht kluch!
Genauso wie die Probleme mit ECI in ICC Version 4. Da merkt man in der Regel recht schnell, dass man da irgendwo auf Granit beißt.

Zitat

[..]die Probleme mit ECI in ICC Version 4. Da merkt man in der Regel recht schnell, dass man da irgendwo auf Granit beißt.

Ich hab schon mitbekommen, dass ihr im Zweifelsfall eher von Version 4 abratet und zur Verwendung von eciRGB_v2.icc tendiert.

Wir verwenden hier seit ein paar Wochen die v4 und bisher hatten wir noch keine Probleme.
Gibt es bereits eine Liste mit Problemstellen?

Wenn es in unserem Workflow keine Problemstellen gibt, würde ich aus organisatorischen Gründen gerne bei v4 bleiben. Ansonsten sollten wir wohl auch zu v2 zurückwechseln. Das müsste ich dringend irgendwie abklären. Nur wie?

Dankeschön,
Matthias

Antwort auf [ vaude_ml ]

Das müsste ich dringend irgendwie abklären. Nur wie?

Den Workflow mit einem Bild das du einmal mit ECI-RGBv2 ICCv4 speicherst und einmal mit ECI-RGBv2 ICCv2 und schaust, wo sich sichtbare Unterschiede ergeben.

Hallo,
den ganzen Workflow testweise durchspielen kann ich leider nicht, da bei uns ja viele verschiedene Stellen die Bilder in den Fingern haben:
Fotographen, Litographen, Grafiker, Setzer (indd) und schließlich die Druckerei im pdf-x-3 (Bilder werden bei der pdf-Generierung in ISOcoated_v2_300_eci.icc oder ein spezielles CMYK-Profil - je nach Druckverfahren und Papier - umgewandelt) .

Wenn ich selbst ein Bild mit v2 und v4 abspeichere sehe ich in PS keine Unterschiede!

Welche optischen Probleme / Nachteile soll es denn bei der v4 geben?
Technisch gibt es aber keine Probleme mit v4?

Denkst du die Photographen / Lithographen könnten einen triftigen Grund haben nur mit v2 arbeiten zu wollen?

(Wie gesagt, bisher hatten wir keinerlei Probleme mit v4, haben es aber auch noch nicht über dne ganzen Workflow hinweg im Einsatz.)

Das ganze Thema ist bei uns momentan sehr im Umbruch (bisher hatten wir einen CMYK-Workflow!) - wenn wir also besser auf ECI-RGBv2 ICCv2 zurückgehen sollten, wäre das jetzt die letze Chance...

Vielen Dank,
Matthias

P.S. Gibt es denn irgendwo eine ausführliche Liste, was konkret gegen die Verwendung der v4 spricht?

Antwort auf:

Welche optischen Probleme / Nachteile soll es denn bei der v4 geben?
Technisch gibt es aber keine Probleme mit v4?

Gemäss Konzept gibt es ausschliesslich Vorteile durch ICC v4.
Dumm wird's, wenn Software zum Einsatz kommt, die ICC v4 Profile nicht versteht und daher falsche Ergebnisse liefert. Dazu gibts nen Testfile auf der ICC-Website, das zeigt, ob eine Software ICC v4 grundsätzlich versteht.

Antwort auf [ loethelm ]

Antwort auf:

Welche optischen Probleme / Nachteile soll es denn bei der v4 geben?
Technisch gibt es aber keine Probleme mit v4?

Gemäss Konzept gibt es ausschliesslich Vorteile durch ICC v4.
Dumm wird's, wenn Software zum Einsatz kommt, die ICC v4 Profile nicht versteht und daher falsche Ergebnisse liefert. Dazu gibts nen Testfile auf der ICC-Website, das zeigt, ob eine Software ICC v4 grundsätzlich versteht.

Ich möchte zu diesem Thema noch anmerken, dass das ICC empfiehlt, innerhalb eines Workflows entweder ausschließlich ICC-V2 oder ICC-V4 Profile zu verwenden. Bei Verwendung beider Profilversionen für eine Umrechnung kann es je nach CMM zu unerwarteten Ergebnissen kommen.

Noch was: zu Beginn wurde gesagt, dass von ECI-RGB (egal jetzt ob v1 oder v2, ICC-V2 oder ICC-V4) nach sRGB transformiert werden soll.

Ein solcher Schritt sollte mit äußerster Vorsicht durchgeführt werden und gut überlegt sein. Der Grund ist, dass beide Profile Matrix-basiert sind und es daher bei der Transformation, auch bei Verwendung des perzeptiven Rendering Intent, stets zu Clipping kommen kann. Einige Motive werden da empfindlicher drauf reagieren als andere Motive.

Eine mögliche Lösung für dieses Problem könnte die Verwendung des sRGB_v4 Profils sein (gibt's unter http://www.color.org zum Download), da dieses Profil für den perzeptiven RI eine LUT verwendet. Nach der Umwandlung ist es theoretisch möglich, dem umgewandelten Bild das normale sRGB-Profil zuzuweisen (aber nicht nochmal transformieren!).

Ob dieser Vorschlag aber zu vernünftigen Ergebnissen führt kann ich pauschal nicht sagen. Das muss jeder für sich selbst entscheiden und am besten vorab gut testen.

Gruß

Hallo,
zunächst Vielen Dank euch allen!

Zitat

Dazu gibts nen Testfile auf der ICC-Website, das zeigt, ob eine Software ICC v4 grundsätzlich versteht.

Für alle die es suchen:
http://www.color.org/v4spec.xalter
http://www.color.org/version4ready.xalter

Ich hab es bei mir getestet und es reagiert wie erwartet:
Die CS3-Programme (ID, PS, Acrobat) können mit v4 umgehen, der Internet Explorer natürlich nicht.

In AI passiert etwas komisches:
Wenn ich das pdf mit AI öffne bringt er mir die Meldung, das Dokument enthalte CMYK und RGB Daten und ich müsse mich für einen Farbraum entscheiden. Egal ob ich CMYK oder RGB nehme: die v4-Bereiche des Testbildes werden falsch dargestellt.
Wenn ich hingegen ein neues ai-Dok mit v4 Profilen anlege und das Pdf dort hineinziehe, fragt er nach
Konvertieren (Farbaussehen beibehalten)
oder
Nicht Konvertieren (Farbnummern beibehalten).
Die Darstellung ist dann in beiden Fällen richtig!

Das soweit zur Info falls das euch Profis irgendwie zu denken gibt oder weiterhilft.

Für den Workflow hier in meinem Unternehmen steht die Entscheidung jetzt fest:
Ich werde wieder auf die v2 Profile zurückrudern.
Und zwar weniger wegen dem Test in AI (ich bin sicher für CS3-Anwendungen gibt es eine Lösung) sondern vielmehr aus folgenden Gründen:
1. Ich bin hier im Unternehmen der einzige der sich mit Farbmanagement beschäftigt und muss einen Workflow finden, der auch für Leute funktioniert, die keine Lust auf das Thema haben.
2. Es geht also nicht darum, die maximal mögliche Farbqualität rauszuholen, sondern einen möglichst einfachen, zuverlässigen, konstanten und fehlertolerierenden Workflow aufzustellen. (Ich denke es geht vielen da draußen so wie mir...)
3. Ich kann weder zu 100% kontrollieren, ob irgendjemand ein neues Programm in den Workflow mit aufnimmt noch wie derjenige im Einzelfall mit Farbprofilmeldungen etc. umgeht.
4. Außerdem sind bei uns auch noch ältere Corel-Versionen im Einsatz, deren Eignung für eciRGB v4 ich im Moment nicht testen kann.


Um das Thema umzusetzen bleibt mir hier leider nur eine kurze Schulung für die Kernbenutzer (Grafiker die leider keine Ahnung von CMS haben) und ein Info-Sheet mit dem neuen Workflow, dass hoffentlich irgendjemand liest. Danach kann ich nur hoffen, dass mir die Leute den Workflow nicht völlig zerlegen...

(zur Info: für private Projekte werde ich auf die v4-Profile umsteigen, da hab ich ja alles unter Kontrolle *g*)

Ich hoffe ihr könnt die Entscheidung nachvollziehen, und vielleicht hilft es ja dem ein oder anderen, der vor dem selben Problem steht.
Schöne Grüße,
Matthias

Zum Thema:
Von ECI-RGB (egal jetzt ob v1 oder v2, ICC-V2 oder ICC-V4) nach sRGB transformieren.

Danke für deinen Hinweis, Cwil:

Zitat

Ein solcher Schritt sollte mit äußerster Vorsicht durchgeführt werden und gut überlegt sein. Der Grund ist, dass beide Profile Matrix-basiert sind und es daher bei der Transformation, auch bei Verwendung des perzeptiven Rendering Intent, stets zu Clipping kommen kann. Einige Motive werden da empfindlicher drauf reagieren als andere Motive.

Mein Problem ist:
Ich kann aufgrund der im vorherigen Post genannten Probleme unmöglich noch ein zusätzliches Profil (z.B. sRGB_v4 ) in den Workflow mit aufnehmen. Da steigen mir die User endgültig aus. Warum muss CMS denn immerso kompliziert sein...

Mir bleiben also zwei Möglichkeiten:
1. Cwils Einwand weitestgehend ignorieren und bei der Generierung der Webderivate
einfach mit perzeptiven Rendering Intent von eciRGB_v2.icc auf sRGB IEC61966-2.1 konvertieren.

2. Bei der Generierung der Webderivate mit perzeptiven Rendering Intent von eciRGB_v2.icc auf sRGB_v4 konvertieren. Und es dann in sRGB_v4 lassen! Doch bei sRGB_v4 gibt es sicher auch wieder Probleme (in manchen Browsern), richtig?

Was würdet ihr mir empfehlen?

Eines möchte ich noch ergänzen:
Unser alter Workflow wandelte die Produktphotos zunächst in CMYK um, alle Retuschen und Lithoarbeiten wurden in CMYK gemacht, um sie dann für Web wieder in sRGB zu konvertieren!!! Arrgh. Aber das kann euch sicher nicht mehr schocken, ich denke das machen echt immernoch extrem viele Firmen so... Wir reden übrigends von ca. 10.000 Bildern pro Saison. Einzelentscheidungen pro Bild sind da natürlich nicht mehr möglich...

Wenn ihr mich also auf Clipping oder andere mögliche Qualitätsverluste hinweist, wäre eine zusätzliche Info sehr wertvoll:
Handelt es sich um ein Problem, dass zu völlig inakzeptablen Ergebnisse führen kann oder ist es eine Feinheit, die uns "Profis" zwar Kopfzerbrechen bereitet, dem Normalverbraucher aber kaum bis garnicht auffallen wird?

Es wäre sehr nett, wenn ihr hier noch eine kurze Einschätzung ergänzen könntet.

Vielen Dank,
Matthias

Antwort auf [ vaude_ml ]

Mein Problem ist:
Ich kann aufgrund der im vorherigen Post genannten Probleme unmöglich noch ein zusätzliches Profil (z.B. sRGB_v4 ) in den Workflow mit aufnehmen. Da steigen mir die User endgültig aus. Warum muss CMS denn immerso kompliziert sein...

Mir bleiben also zwei Möglichkeiten:
1. Cwils Einwand weitestgehend ignorieren und bei der Generierung der Webderivate
einfach mit perzeptiven Rendering Intent von eciRGB_v2.icc auf sRGB IEC61966-2.1 konvertieren.

2. Bei der Generierung der Webderivate mit perzeptiven Rendering Intent von eciRGB_v2.icc auf sRGB_v4 konvertieren. Und es dann in sRGB_v4 lassen! Doch bei sRGB_v4 gibt es sicher auch wieder Probleme (in manchen Browsern), richtig?

Wenn _du_ das so schon nicht umsetzen kannst oder willst, dann kannst du dir das auch komplett sparen und rausgeben was du willst, und dem Datenempfänger komplett im Regen stehen lassen. Ich schrieb ja schon in meinem ersten Post, dass der Vorteil der Wandlung der Webbilder bei euch von ECI-RGB zu sRGB den Vorteil bietet, das ihr bei Bildern die problematisch sind, eingreifen könnt:
Probier das mal:
http://www.richard-ebv.de/..._gruen_fuer_sRGB.jpg
nach sRGB zu wandeln, gerne auch mit dem sRGB V4 Profil mit perceptual RI.

Die Verbesserung (wenn man da überhaupt von einer reden kann), ist den Aufwand ein weiteres Profil ins Portfolio aufzunehmen nicht wert.

Es geht aber eigentlich auch um etwas anderes: Ihr wisst wie eure Bilder aussehen sollten, könnt also bei Problemen am einfachsten und zielgerichtetsten eingreifen. Wie soll jemand, der eh nciht weis, ob das was er da gerade sieht richtig oder falsch ist, entscheiden, ob und wann durch irgendwelche Optimierungen eine Verbesserung bzw. das Optimum erreicht ist.

Antwort auf [ vaude_ml ]

Eines möchte ich noch ergänzen:
Unser alter Workflow wandelte die Produktphotos zunächst in CMYK um, alle Retuschen und Lithoarbeiten wurden in CMYK gemacht, um sie dann für Web wieder in sRGB zu konvertieren!!! Arrgh. Aber das kann euch sicher nicht mehr schocken, ich denke das machen echt immernoch extrem viele Firmen so... Wir reden übrigends von ca. 10.000 Bildern pro Saison. Einzelentscheidungen pro Bild sind da natürlich nicht mehr möglich...

Wieso dass denn nicht? Bei so ein paar Bildern ;-)
Aber Grundsätzlich ist an der Methode, die Webbilder ordentlich Colorgemanaged aus den CMYK Druckdaten zu erstellen nicht allzuviel verwerfliches dran auszusetzen. Gerade die obigen Beispiel, das bei der Wandlung extreme Probleme verursacht wird sicherlich im Print Workflow nicht ungeschoren davon kommen. Also wäre man in dem Fall sogar besser bedient, man nähme die für die CMYK Fassung passend hinretuschierte Version fürs Web als, wie du vorhast die Fullgamutdateien blind nach sRGB zu wandeln.

Es ist aber müssig zu diskutieren, ob bei obigem Beispiel der Weg über CMYK nach sRGB der schlauere wäre, zumal sich da dann auch zeigt wie viel Spiel 2 RIs (oben jeweils perzeptiv, unten Rel FM mit TK) und eine Charakterisierungsdatei noch lassen:
http://www.richard-ebv.de/...fuer_ISOcoatedV2.jpg

Genau dieses Problem ist m.E. eh der größte Pferdefuss der medienneutralen Workflows - man lässt die Verbindlichkeit die man mit einem CMYK basierten Workflow erarbeitet, hinter sich.
Was nützt es einem, bei 2% der Bilder für bestimmte Ausgabebedingungen einen Farbgewinn zu haben, wenn genauso viele Kandidaten dadurch vergeigt werden.

Antwort auf [ vaude_ml ]

Wenn ihr mich also auf Clipping oder andere mögliche Qualitätsverluste hinweist, wäre eine zusätzliche Info sehr wertvoll:
Handelt es sich um ein Problem, dass zu völlig inakzeptablen Ergebnisse führen kann oder ist es eine Feinheit, die uns "Profis" zwar Kopfzerbrechen bereitet, dem Normalverbraucher aber kaum bis garnicht auffallen wird?

Siehe oben – entscheide selbst.