[GastForen PrePress allgemein CMS (Color-Management) eciRGB_v2_ICCv4.icc im Web / Internet / WWW verwenden?

  • Suche
  • Hilfe
  • Lesezeichen
  • Benutzerliste
Themen
Beiträge
Moderatoren
Letzter Beitrag

eciRGB_v2_ICCv4.icc im Web / Internet / WWW verwenden?

vaude_ml
Beiträge gesamt: 23

11. Mär 2010, 13:02
Beitrag # 1 von 12
Bewertung:
(9493 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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.]
X

eciRGB_v2_ICCv4.icc im Web / Internet / WWW verwenden?

Thomas Richard
  
Beiträge gesamt: 19164

11. Mär 2010, 13:54
Beitrag # 2 von 12
Beitrag ID: #436090
Bewertung:
(9476 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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.


als Antwort auf: [#436086]
(Dieser Beitrag wurde von Thomas Richard am 11. Mär 2010, 13:57 geändert)

eciRGB_v2_ICCv4.icc im Web / Internet / WWW verwenden?

vaude_ml
Beiträge gesamt: 23

11. Mär 2010, 15:34
Beitrag # 3 von 12
Beitrag ID: #436105
Bewertung:
(9430 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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


als Antwort auf: [#436090]

eciRGB_v2_ICCv4.icc im Web / Internet / WWW verwenden?

Thomas Richard
  
Beiträge gesamt: 19164

11. Mär 2010, 15:46
Beitrag # 4 von 12
Beitrag ID: #436106
Bewertung:
(9425 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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.


als Antwort auf: [#436105]

eciRGB_v2_ICCv4.icc im Web / Internet / WWW verwenden?

vaude_ml
Beiträge gesamt: 23

11. Mär 2010, 16:13
Beitrag # 5 von 12
Beitrag ID: #436114
Bewertung:
(9400 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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


als Antwort auf: [#436106]

eciRGB_v2_ICCv4.icc im Web / Internet / WWW verwenden?

Thomas Richard
  
Beiträge gesamt: 19164

11. Mär 2010, 17:00
Beitrag # 6 von 12
Beitrag ID: #436131
Bewertung:
(9384 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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.


als Antwort auf: [#436114]
(Dieser Beitrag wurde von Thomas Richard am 11. Mär 2010, 17:01 geändert)

eciRGB_v2_ICCv4.icc im Web / Internet / WWW verwenden?

vaude_ml
Beiträge gesamt: 23

11. Mär 2010, 17:17
Beitrag # 7 von 12
Beitrag ID: #436132
Bewertung:
(9371 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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?


als Antwort auf: [#436131]

eciRGB_v2_ICCv4.icc im Web / Internet / WWW verwenden?

loethelm
  
Beiträge gesamt: 6029

11. Mär 2010, 20:51
Beitrag # 8 von 12
Beitrag ID: #436170
Bewertung:
(9341 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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.


als Antwort auf: [#436132]

eciRGB_v2_ICCv4.icc im Web / Internet / WWW verwenden?

Cwil
Beiträge gesamt: 48

11. Mär 2010, 21:49
Beitrag # 9 von 12
Beitrag ID: #436174
Bewertung:
(9327 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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ß


als Antwort auf: [#436170]

eciRGB_v2_ICCv4.icc im Web / Internet / WWW verwenden?

vaude_ml
Beiträge gesamt: 23

12. Mär 2010, 09:52
Beitrag # 10 von 12
Beitrag ID: #436210
Bewertung:
(9273 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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


als Antwort auf: [#436174]

eciRGB_v2_ICCv4.icc im Web / Internet / WWW verwenden?

vaude_ml
Beiträge gesamt: 23

12. Mär 2010, 10:20
Beitrag # 11 von 12
Beitrag ID: #436216
Bewertung:
(9262 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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


als Antwort auf: [#436174]

eciRGB_v2_ICCv4.icc im Web / Internet / WWW verwenden?

Thomas Richard
  
Beiträge gesamt: 19164

12. Mär 2010, 12:01
Beitrag # 12 von 12
Beitrag ID: #436246
Bewertung:
(9230 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
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.


als Antwort auf: [#436216]
(Dieser Beitrag wurde von Thomas Richard am 12. Mär 2010, 12:02 geändert)
X

Veranstaltungskalender

Hier können Sie Ihre Anlässe eintragen, welche einen Zusammenhang mit den Angeboten von HilfDirSelbst.ch wie z.B. Adobe InDesign, Photoshop, Illustrator, PDF, Pitstop, Affinity, Marketing, SEO, Büro- und Rechtsthemen etc. haben. Die Einträge werden moderiert freigeschaltet. Dies wird werktags üblicherweise innert 24 Stunden erfolgen.

pdf-icon Hier eine kleine Anleitung hinsichtlich Bedeutung der auszufüllenden Formularfelder.

Veranstaltungen
02.02.2023

Prozesse optimieren und effizient gestalten

Zürich
Donnerstag, 02. Feb. 2023, 08.00 - 10.00 Uhr

Digitalisierung, Webauftritt

Digitalisierung mitgestalten - Worauf kommt es an? Wie wichtig ist die Webseite? Webseite mit Word Press? Interne Prozesse optimieren

Ja

Organisator: B. Isik - SNF Academy

Kontaktinformation: Birol Isik, E-Mailinfo AT bkcc DOT ch

https://digitalisierung-heute.ch/digitalisierung-informationstag-schweiz/

Veranstaltungen
01.03.2023 - 09.03.2023

Online
Mittwoch, 01. März 2023, 00.00 Uhr - Donnerstag, 09. März 2023, 00.00 Uhr

Online Webinar

Wie gehen wir mit diesen Veränderungen um? Was ist notwendig, damit wir die Digitalisierung im Unternehmen klappt? Veränderungsprozesse verstehen und entsprechend handeln Mitarbeiter als Botschafter Webseite mit WordPress erstellen SEA /SEO (Ads aufschalten)

Ja

Organisator: B. Isik - SNF Academy

Kontaktinformation: B. Isik, E-Mailinfo AT snfa DOT ch

https://www.fernstudiumfitness.ch/digitalisierung-schweiz/