ZITAt (guenterfrank @ 11.07.2006 - 12:19) Schärfen eher nicht, (also ich mache das immer erst zuletzt das es ja von der Ausgabegrösse abhängt)[/quote]
Genau. Hängt auch ab vom Ausgabemedium.
Beste Grüße.
ZITAt (guenterfrank @ 11.07.2006 - 12:19) Schärfen eher nicht, (also ich mache das immer erst zuletzt das es ja von der Ausgabegrösse abhängt)[/quote]
Genau. Hängt auch ab vom Ausgabemedium.
Beste Grüße.
Beiträge: | 2.931 |
Registriert am: | 15.12.2005 |
So, ich hatte die letzten Tage keine Zeit, daher kann ich mich erst heute wieder dem Thema widmen.
Zuerst möchte ich mich mal für alle persönlichen "Tiefschläge" entschuldigen - allerdings weniger bei Olaf, der bekommt nur den Tonfall zurück, den er selbst anschlägt, mehr bei den anderen. Ich muss Ingo Recht geben, das Thema leidet darunter (allerdings hast Du Dich mit Deinem komplett sinnfreien Posting bestens für unseren kleinen Club qualifiziert - und Deine Diskussion mit Thomas zwischendurch... Glashaus).
Nun zum Thema. Es ist keine Rechthaberei um ihrer selbst Willen, aber es gibt hier eben einige Aussagen, die so nicht richtig sind:
1. "Aber in irgend einen Farbraum konvertieren sie trotzdem, einerlei welchen Namen der trägt."
Nicht richtig. Um Daten in einen irgendwie gearteten Farbraum zu konvertieren, benötigt man dreivier (EDIT: Danke Olaf! Dinge:
- Angaben zum Quellfarbraum
- Angaben zum Zielfarbraum
- eine Konvertierungsvorschrift - also die mathematischen Formeln, an Hand derer umgerechnet wird
- einen PCS als übergeordneten geräteneutralen Farbraum, der als Farbbasis zur Umrechnung benötigt wird.
Das heißt also, bei der Entwicklung einer Raw-Aufnahme in einem Raw-Konverter wird auf ein hinterlegtes (oder individuell auswählbares) Kameraprofil zurückgegriffen, ein Ausgabeprofil gewählt (zB sRGB) und dann werden die Rohdaten umgerechnet.
Das muss aber nicht passieren, denn man kann die Rohdaten komplett ohne Konvertierung ausgeben. Dabei gibt es keinen Zielfarbraum und auch keine Konvertierungsvorschrift. Es werden die einzelnen Farbwerte ausgelesen, im Zuge der Farbinterpolation zu vollwertigen RGB-Werten komplettiert, und ohne Umrechnung in einen bestimmten Farbraum ausgegeben. Es wird also weder konvertiert, noch gibt es einen definierten Farbraum. Die Farbwerte werden sozusagen aus dem Kamerafarbraum übernommen - allerdings ohne in irgendeiner Weise darauf Rücksicht zu nehmen. "In einen Farbraum konvertieren" ist etwas ganz anderes, siehe nächster Punkt.
2. "so etwas wie "exakt die RGB-Werte, die der Sensor aufnimmt" existiert nicht. Die Abbildung der Rohdaten ins RGB-Farbmodell erfolgt zwangsläufig gemäß irgend eines Farbprofiles -- selbst wenn dieses Profil implizit oder zufällig oder unbekannt oder sonstwie nicht näher spezifiziert ist."
Der Sensor kennt zwar keine RGB-Werte, aber er kennt R-, G- und B-Werte. Diese werden direkt ausgelesen, und bekommen im A/D-Wandler einen Wert zwischen 0 und 4.095 zugewiesen. Das sind genau die Farben, die der Sensor "sieht". Diese Farben liegen exakt vor und sind auch genau so auslesbar. Natürlich erhält man damit nur ein Bild aus kleinen roten, grünen und blauen Pixeln. Um "echte" RGB-Werte zu erhalten, muss man die fehlenden Werte interpolieren. Wichtig ist, das dabei logischerweise die originalen Farbwerte nicht verändert werden. Es werden pro Pixel die zwei fehlenden Farben "hinzugeschätzt" (interpoliert). Hierbei geht aber nichts verloren. Insofern ist es auch sinnlos darüber zu debattieren, was mit 12bit langen Wörtern bei deren mathematischer Bearbeitung so alles passiert, und ob das Ergebnis dann 24bit sein müsse: Die Farbwerte sind quasi frei erfunden (okay, sagen wir "gezielt" erfunden), somit besteht überhaupt keine Notwendigkeit bei diesen Daten eine höhere Genauigkeit zu verlangen, als bei den originalen Daten.
Man kann dann diese RGB-Werte ausgeben - in einem geeigneten Raw-Konverter. Das Bild wird sehr dunkel sein, da von den für das Bildformat notwendigen 16bit nur "die linken" 12bit genutzt werden, und außerdem keine Gamma-Korrektur stattfand. Man kann dann die Werte mit 16 multiplizieren, und somit das volle 16bit-Spektrum ausnutzen, natürlich entstehen bei dieser Spreizung Lücken im Histogramm, aber verloren geht nichts. Man kann auch eine Gamma-Korrektur vornehmen, um so die linearen Daten an die Monitor-Ausgabe anzupassen - dabei geht auch "nichts" verloren. Was wir dann sehen, sind quasi die Farben, die der Sensor aufgenommen hat, angepasst an unsere Bearbeitungskette. Es fand aber bis zu diesem Augenblick keine Konvertierung der Sensordaten in einen (anderen) Farbraum statt. Die Farben blieben unberührt, es gab keine Vorschrift, wie welche Farben zu behandeln sind, oder "wohin" sie umgerechnet werden sollen. Sie werden quasi durchgereicht: Die originalen werden gespreizt und aufgehellt, die fehlenden ergänzt. Was eine Farbraumkonvertierung ist, habe ich ja oben beschrieben - das hier ist keine.
An Hand dieser "rohen" Daten kann man ein Kameraprofil erstellen, und das diesen Daten anhängen, damit sie farbrichtig von einem entsprechenden Programm wiedergegeben werden können.
3. Was ist eine Separation? Gibt es einen universellen CMYK-Farbaum?
Unter Separation kann man verschiedene Dinge verstehen. Zum einen ist es bereits eine Separation, wenn farbiges Licht in unterschiedliche Bestandteile zerlegt wird, zB Rot, Grün und Blau. Somit ist die Darstellung am Monitor schon definitiv eine Farbseparation. Auch die Zerlegnung in Cyan, Magenta, Gelb und Schwarz ist eine Separation. Zum anderen wird die Umwandlung von Bilddaten, die in einem RGB-Farbraum vorliegen, in einen Druckerfarbraum, der mit cyanfarbiger, magentafarbiger, gelber und schwarzer Tinte druckt, als Separation bezeichnet. Es gibt unterschiedliche Druckverfahren und unterschiedliche Bedruckstoffe (das ist das, worauf gedruckt wird), und auch unterschiedliche Druckfarben. Für jedes Verfahren gibt es unterschiedliche Parameter: Wie werden die Farben erzeugt, wie werden Grautöne erzeugt, wie sehr wird das Schwarz miteinbezogen, wieviel Farbe darf insgesamt aufgetragen werden, wie zerfließen die Farben auf dem Bedruckstoff, etc. Diese Parameter unterscheiden sich teilweise ganz drastisch. Und daher ist es unmöglich, einen "universellen" CMYK-Farbraum zu erfinden, der für alles geeignet ist. Daher muss eine Umwandlung von RGB nach CMYK immer direkt in das endgültige Profil erfolgen. Alles andere ist nicht empfehlenswert, und kann sehr unschöne Ergebnisse bringen. Eine Unterscheidung in Farbmodus-Änderung und Separation kann also nicht vorgenommen werden, denn man kann mit konkreten Bild-Daten keine Farbmodusänderung ohne ein konkretes Zielprofil vornehmen.
Beiträge: | 5.313 |
Registriert am: | 17.11.2004 |
ZITAt (tatatu @ 9.07.2006 - 23:02) - Eine Profilzuweisung sollte im Prozess so früh als möglich erfolgen, damit 'Farbmanagement' überhaupt greift.[/quote]Genau, wobei der häufigste Fall ist, dass das der Konverter macht.
ZITAT- Große Arbeitsfarbräume wurden entwickelt, um maximal viele Farben aus RGB und CMYK gleichzeitig zu erfassen, so dass eine Konvertierung quasi von irgend einem RGB-Farbraum in irgend einen CMYK-Farbraum möglichst verkustfrei stattfinden kann.[/quote]Nicht ganz, große RGB-Farbräume wurden entwickelt, um die maximale Anzahl von Farben, die von Eingabegräten erfasst (Scanner, Digitalkamera) wurden, überhaupt erst mal weiterbearbeiten zu können. Große CMYK-Farbräume gibt es praktisch nicht. Für eine Tranformation von RGB nach CMYK wäre ein möglichst kleiner Farbraum ideal.
ZITATDas Bild liegt also jederzeit so vor, dass es in einen auch später erst zu wählenden Ausagbefarbraum möglichst verlustfrei konvertiert werden kann.[/quote]Dann gibt es eigentlich nur eine Wahl: ProPhotoRGB. Doch gerade dieser Farbraum ist nicht ohne Tücken.
ZITATDafür bietet sich z.B. AdobeRGB an. Allerdings wohl auch mit problematischen Einschränkungen - nicht umsonst wurde z.B. ein Farbraum wie ECI-RGB entwickelt; andere natürlich auch.[/quote]AdobeRGB ist ein von Adobe direkt aus sRGB abgeleiteter Standard der sich nicht großartig (gar nicht) an der Druckindustrie orientiert. Im Prinzip ist es ein ziemlich ungeeigneter Farbraum für die Druckvorstufe. Das hängt auch damit zusammen, dass wir hier in Europa (Deutschland) eine völlig andere "Druckkultur" habe, als die Amerikaner. ECI-RGB ist ein RGB-Farbraum, der ganz speziell auf die ISO-CMYK-Profile hin ausgerichtet wurde, und ist somit ein "echter" Arbeitsfarbraum für die Druckvorstufe. Ähnlich, wie bereits früher schon erwähnt, verhält es sich mit dem ISO coatde FOGRA 27 Profil, das Photoshop neuerdings beiliegt. Da hat sich Adobe irgendetwas an Hand der Charakterisierungsdaten zusammengebastelt, nur brauchbar ist es nicht. Es unterscheidet sich deutlich von den originalen FOGRA-Profilen. Wer also hierzulande drucken will, sollte sich tunlichst bei der FOGRA oder ECI informieren, und nicht einfach auf den Kram vertrauen, den Adobe in USA bastelt.
ZITAT- Die Arbeit mit Arbeitsfarbräumen bedarf einer gewissen Praxiserfahrung hinsichtlich späterer Konvertierung in Ausgabefarbräume. Ein Proof ist eine aussagekräftige Referenz, ist aber eben nicht das final gedruckte Bild.[/quote]Der Sinn eines Proofs ist es, das spätere Druckergebnis innerhalb genau definerter Normen zu simulieren, daher gilt er auch als Maßstab für die Druckerei (contract proof). Unterschiede dürfen - platt gesagt - wahrnehmbar sein, aber keinesfalls augenfällig. Oder meinst Du den Softproof?
ZITATIm Gegenteil geht es wohl eher darum, möglichst standardisiert zu arbeiten, nicht möglichst spezifisch.[/quote]Fluch oder Segen? /wink.gif" style="vertical-align:middle" emoid="" border="0" alt="wink.gif" />
Beiträge: | 5.313 |
Registriert am: | 17.11.2004 |
ZITAt (guenterfrank @ 10.07.2006 - 13:09) Das ist es, wass CMM eigentlich beschreibt.[/quote] /smile.gif" style="vertical-align:middle" emoid="" border="0" alt="smile.gif" /> Fast: CMM ist das Color Matching Module (oder Method), das sind die kleinen Programme, die die konkrete Farbumwandlung an Hand von Profilen vornehmen. Du meinst wahrscheinlich CM im sinne von Color Mangament.
ZITATAngemerkt sei, dass es hier unetrschiede zwischen den Plattformen PC MAC und den Monitoren an sich gibt, wer viel Geld hat kann sich Monitore kaufen die Adobe RGB darstellen könne, (aber wer kann das schon).[/quote]Nur bringt das momentan noch nicht viel, denn der "bottleneck" ist die Versorgung mit Daten von der Grafikkarte zum Monitor, und die ist leider immer noch 8bittig, wie ich mir habe sagen lassen. Und AdobeRGB mit 8bit am Monitor kannst Du knicken, da dann die Änderung einer Farbe von einem zum nächsten Wert schon einen deutlichen Sprung bedeuten kann. Für einen AdobeRGB-Monitor sind mindestens 10bit Farbtiefe notwendig.
ZITATEin Monitor kann sRGB, gerade so und scheinbar nicht mal das immer.[/quote]Meistens deutlich mehr /wink.gif" style="vertical-align:middle" emoid="" border="0" alt="wink.gif" /> sRGB basiert auf dem technischen Standard von 1993, seit dem gab es große Fortschritte in der Monitor-Technik (wie Du ja oben sagst, gibt es mittlerweile sogar AdobeRGB-Geräte). Und sogar damals war sRGB ein Durchchnitt, also gab es durchaus "normale" Monitore, die darüber lagen.
ZITATAdobe RGB beispielsweise ist ein wesentlich grösserer Farbraum als die Teilmenge sRGB.[/quote]Eigentlich nicht soooo viel größer: Lediglich der grüne Eckpunkt wurde ein wenig nach "außen" verschoben, ansonsten ist er mit sRGB identisch (also die rote und die blaue "Ecke" sind gleich).
ZITATSchlimmer noch, würde man aus dem Farbraum mit den vielen Farben das Bild in einen Farbraum mit weniger Farben übergeben, (konvertieren von Adobe RGB nach sRGB) würde das Bild dabei verlieren, weil auch die Farben die der kleinere Farbraum "nicht kann" abgeschnitten werden, (Dennis).[/quote]Das passiert, wenn Du das in PS vornimmst, aber, wenn Du es in der Kamera einstellst, kann es sein, dass diese Farben nicht abgeschnitten werden, sondern "reingequetscht" werden. Du würdest dann - wie oben zu sehen war - ein etwas blasseres Bild bekommen, bei dem aber die stark gesättigten Partien feiner differenziert sind. Bei solchen Motiven sollte man aber tunlichst das Raw-Format verwenden. Deswegen kann ich hier auch keine Erfahrungswerte beisteuern: Ich fotografiere sowieso in Raw, und wenn in JPEG, dann in sRGB.
ZITATWelcher Farbraum wäre der richtige Arbeitsfarbraum für eine guten Umwandlung in den CMYK Modus der Druckerei?
In welchem Ausgangsformat sollten die Daten Kameraseitig vorliegen.[/quote]Das hängt von diesem Farbraum ab, der dort genutzt wird. In Deutschland sind die ISO-Profile der FOGRA der Branchen-Standard, und darauf ist ECI-RGB abgestimmt. Eine andere recht pfiffige Idee ist der von tatatu erwähnte PhotoGamutRGB: Ein RGB-Farbraum in CMYK-Gestalt.
ZITATIch denke (und hoffe hier nochmal auf Hilfe), dass in dem Fall wohl der Adobe RGB Farbraum für die Umwandlung in den CMYK Farbraum der bessere ist weil er den Farbspektrum von CMYK näher ist als sRGB.[/quote]In AdobeRGB sind einige Farben enthalten, die außerhalb von sRGB liegen, aber trotdem innerhalb von vielen CMYK-Farbräumen. Bei iccview.de kannst Du Dir das sehr schön anschauen.
Beiträge: | 5.313 |
Registriert am: | 17.11.2004 |
ZITAt (01af @ 10.07.2006 - 15:41) Oder du willst für jede mögliche Anwendung die maximal mögliche Qualität herausholen -- dann wirst du für jede Anwendung eine eigene Rohdatenkonvertierung durchführen müssen. Und demzufolge die Rohdatei als Basis ansehen.[/quote]Dem würde ich grundsätzlich auch zustimmen. Nur gibt es da auch andere Ansichten: Nämlich die Konvertierung nach 16bit-ProPhotoRGB als Basis. Damit könnte man dann eine Masterdatei erstellen, und in der sogar praktisch alle Korrekturen und Retuschen vornehmen, und ist dann quasi für alle noch kommenden Druckverfahren mit ihren stetig wachsenden Gamuts gewappnet. Das erscheint mir nicht unlogisch, und wenn der nachgelagerte Workflow bis hin zum endgültigen Ausgabefarbraum stimmt, kann das wohl auch funktionieren (bei anderen funktioniert es wohl). Leider kann ich das nicht aus eigener Erfahrung beurteilen.
ZITATZu diesem Zwecke werden die Farben bei der Anzeige quasi "übersetzt" ... das ist natürlich nur ein Kompromiß, aber es funktioniert recht gut. Sofern alles richtig eingestellt und farb-gemanagt ist.[/quote]Mit der Kalibrierung und Profilierung eines Monitors erreichst Du aber nur eine farbrichtige Darstellung der darstellbaren Farben. Die nicht darstellbaren werden nach RelCol geclippt - Stichwort: Channel clipping. Das heißt, AdobeRGB wird nicht auf dem Monitor angezeigt. Wenn Du eine AdobeRGB-Datei am Monitor "nach Sicht" bearbeitest, bist Du im absoluten Blindflug unterwegs - was die OOG-Farben angeht. Die kannst Du nur an Hand von Hisotgramm, Gamut-Warnung oder über die Option "Monitorfarben Desaturieren" abschätzen.
ZITATDer höchstwertige Farbraum ist nicht der größte, sondern der passendste -- also der kleinste, der groß genug ist.[/quote]Die zentrale Wahrheit des gesamten CM!
Beiträge: | 5.313 |
Registriert am: | 17.11.2004 |
ZITAt (Dennis @ 11.07.2006 - 15:20) man kann die Rohdaten komplett ohne Konvertierung ausgeben.[/quote]
Wie würde das dann praktisch aussehen? Als untagged Tif?
ZITAt (Dennis @ 11.07.2006 - 15:51) Genau, wobei der häufigste Fall ist, dass das der Konverter macht.[/quote]
Klar!
ZITATNicht ganz, große RGB-Farbräume wurden entwickelt, um die maximale Anzahl von Farben, die von Eingabegräten erfasst (Scanner, Digitalkamera) wurden, überhaupt erst mal weiterbearbeiten zu können.[/quote]
So ist's natürlich präziser - klar: erstmal erfassen, dann weitergeben.
Aber die Gestalt der Arbeitsfarbräume für die Druckvorstufe - dachte ich zumindest - orientiert sich auch an realen Ausgabemöglichkeiten [ECI, Photogamut u.a. sind, soweit ich das bsilang verstanden hatte, gerade wg. z.B. der Probleme mit AdobeRGB entwickelt worden ...].
Die Arbeitsfarbräume mit maximalen Farbereichen berücksichtigen dagegen vor allem die Eingabeseite [also: 'viele Farben erfasssen'].
ZITATFür eine Tranformation von RGB nach CMYK wäre ein möglichst kleiner Farbraum ideal.[/quote]
Schau Dir mal Photogamut an. Einen Offsetdruck habe ich damit noch nicht erstellen lassen. Aber selbst bei RGB-Belichtung arbeite ich mit diesem Profil eindeutig konsistenter als mit sRGB. Selbst auch, wenn ich die Daten am Ende in sRGB dem Belichter übergebe!
Da Du öfter Bilder drucken läßt: vielleicht kannst Du ja mal einen Test damit machen. Würde mich wirklich interessieren. Falls es mal irgendwann passen sollte...
ZITATOder meinst Du den Softproof?[/quote]
Sorry: Softproof.
ZITATFluch oder Segen? /wink.gif" style="vertical-align:middle" emoid="" border="0" alt="wink.gif" />[/quote]
Segen. Ein wahrer Segen :-))! Oder erfindest Du gerne alles dauernd neu?
Beste Grüße.
Beiträge: | 2.931 |
Registriert am: | 15.12.2005 |
ZITAt (01af @ 10.07.2006 - 15:42) Im Zweifelsfalle vorher die Druckerei fragen.[/quote] /biggrin.gif" style="vertical-align:middle" emoid="" border="0" alt="biggrin.gif" /> Theoretisch richtig. In der Praxis wird man leider feststellen, dass sehr viele Druckereien mit einer Beantwortung dieser Frage völlig überfordert sind. Man klammert an der althergebrachten Druckerkunst, kennt seine Maschine, und stellt die intuitiv ein - an Hand eines Proofs. Aus gutem Grund weigern sich immer noch nicht gerade wenige Druckereien, ein gesundes CM zu impelementieren: So ist nämlich der Fotograf der Buhmann, der "undruckbare" Vorlagen oder "schlechte" Daten liefert. Wenn die Druckerei sich auf Standards festlegt, dann sind sie auch in der Verpflichtung, diese einzuhalten. Ich würde also im Vorfeld lieber erst mal einige Druckereien anrufen und genau nach solchen Dingen fragen. Wenn man dann wirklich gute Antworten bekommt, und Profile erhält oder genannt bekommt, dann ist da Vertrauen berechtigt. Aber man wird oft die Auskunft bekommen: "Die Daten müssen in CMYK vorliegen". /rolleyes.gif" style="vertical-align:middle" emoid="" border="0" alt="rolleyes.gif" />
ZITATDas ist normalerweise egal, denn die meisten Druckereien kommen mit allen möglichen Daten zurecht.[/quote]Sollte man meinen - in aller Regel werden aber CMYK-Daten verlangt, oft skurilerweise ohne genaue Angabe welches CMYK gemeint ist. Wenn ich's nicht rausbekomme, dann schicke ich einfach ISO coated hin.
ZITATEinfach in Photoshop mal auf Bild > Modus > CMYK-Farbe zu drücken ist sinnlos und macht der Druckerei eher mehr Arbeit als welche zu sparen.[/quote]Es ist sinnlos, aber macht der Druckerei keine Arbeit: Die drucken nämlich dann einfach die CMYK-Daten. Falls jemand eine Druckerei kennt, die aus eigenen Stücken so etwas korrigiert: Unbedingt merken!
ZITATNoch einmal: "der" CMYK-Farbraum existiert nicht. CMYK ist ein Farbmodell, kein Farbraum.[/quote]Ich interpretiere Günters Aussage so, dass er mit "was kann der CMYK-Farbraum eigentlich darstellen" eigentlich meinte: "was kann der jeweilige CMYK-Farbraum eigentlich darstellen".
Es ist doch hier sinnlos über Farbmodelle zu reden, es geht hier um konkrete Farbräume und Profile. Das geht eigentlich aus dem Kontext hervor, und eine explizite Unterscheidung ist zu umständlich und muss nicht immer gemacht werden - bei einer Diskussion um Druckfarbräume sollte klar sein, dass es nciht um Farbmodelle geht.
Beiträge: | 5.313 |
Registriert am: | 17.11.2004 |
ZITAt (01af @ 10.07.2006 - 19:11) Also jetzt zum dritten Mal: Ein besonders großer Farbraum hält nicht alle Optionen offen!
Wenn die Archivierung als Rohdatei nicht möglich ist und eine RGB-Datei archiviert werden soll oder muß (aus welchen Gründen auch immer), dann wird man natürlich einen eher großen (nicht unbedingt den allergrößten) Farbraum wählen, das ist klar. AdobeRGB kommt hier in Frage. Doch der entscheidende Punkt ist: dies stellt bereits einen Kompromiß dar! Er mag für viele Anwendungsfälle nützlich und gut genug sein und genügend Optionen offenhalten. Aber eben nicht alle!
Noch einmal: Der optimale Farbraum ist nicht der größte, sondern der kleinste, der groß genug ist. Das heißt, ein übermäßig großer ist schlechter! Und auch der Umstand, daß ein zu kleiner noch schlechter ist, macht die Methode des "großen" Farbraumes nicht besser. Sicher, die Verluste durch einen für die konkrete Anwendung zu großen Arbeitsfarbraumes mögen verschmerzbar oder sogar vernachlässigbar sein. Doch entscheidend in einer Grundlagendiskussion wie dieser hier ist, daß man sich ihrer erst einmal bewußt ist. Ob man sie in der Praxis in Kauf nehmen kann, mag man dann entscheiden.
Sicher die "edelste" Variante. Heißt aber auch, daß Du alles "nachbasteln" mußt, was Du am Bild ggf. justiert hast. Okay, kann man sich drauf einlassen.[/quote]Das ist scheinbar eine zentrale Frage. Und sie ist natürlich nicht leicht zu beantworten.
Alle Optionen hält man sich natürlich mit Raw offen. Wird nun ein RGB-Farbraum gesucht, der ähnlich universell sein soll, dann sollte es mE einer sein, der den kompletten Kamera-Farbraum umfasst. Es gilt ja schließlich - analog zum Raw-Format - die ursprünglichen Farben zu erhalten, und nicht schon irgendwei druckfreundlich zu speichern. Und dafür ist AdobeRGB nun ungeeignet. Zum einen ist es sichtlich kleiner als viele Kamera-Farbräume, und da eine Konvertierung im Raw-Konverter im Zweifelsfall eher RelCol abläuft, gehen Farben verloren. Zum anderen wird AdobeRGB schon heute von guten Druckern geknackt - und die Entwicklung geht weiter. Holt man in 10 Jahren in AdobeRGB archivierte Daten hervor, wird man sich ziemlich sicher ägern.
Zwar ist die Aussage bzgl Farbraum "so groß wie nötig, so klein wie möglich" absolut richtig, aber logischerweise nur bei bekanntem Zielfarbraum praktisch umsetzbar. Bei unbekanntem Zielfarbraum kann sich diese Maxime nur am Quellfarbraum orientieren - also am Kamerafarbraum. Der Intermediär-Farbraum sollte also den Kamerafarbraum einschließen - und wo landen wir da? Bei ProPhotoRGB.
Allerdings taucht ProPhotoRGB auf Grund seiner Matrix-TRC-Architektur nur als Intermediärfarbraum, wenn danach direkt in LUT-basierte Farbräume konvertiert wird, wie zB die ganzen CMYK-Farbräume. Will man dagegen in einen Monitorfarbraum konvertieren, bekommt man auf Grund des zwangsläufigen farbnetrischen Renderings Probleme mit den OOG-Farben.
Nun bin ich an anderer Stelle darauf hingewiesen worden, dass man schließlich immer die OOG-Farben manuell und sanft in den Zielfarbraum durch gezielte Entsättigung bringen müsse. Das kann ich aus eigenere Erfahrung nicht so ganz entkräften, allerdings ziehe ich intuitiv ein perzeptives Rendering vor, weil dann die Farbrealtion erhalten bleibt. Wenn ich dagegen manche Farben gezielt desaturiere, ändere ich ja die Relation der Farben untereinander. Hier bin ich noch zu keiner abschließenden Meinung gekommen.
Auf jeden Fall muss diese Speicherung in ProPhotoRGB in 16bit erfolgen, nur dann ist sichergestellt, dass allen Lab-Werten des Sensors auch ein hinreichend genauer RGB-Wert innerhalb von ProPhotoRGB zugeordnet werden kann.
Beiträge: | 5.313 |
Registriert am: | 17.11.2004 |
Hallo zusammen,
wieder jep,
ich meinte genau, was kann der "jeweilige" CMYK Farbraum, die Frage zielte
(analog zum Konvertierungsprozess von etwa AdobeRGB auf sRGB)
auf den Seperationsprozess von (als Beispiel) Adobe RGB nach CMYK ISO coated ab und was dabei passiert wenn in eben diesem Quellfarbraum Farben sind die dann im Zielfarbraum nicht dargestellt werden können.
Im übrigen sind meine Erfahrungen mit Druckereien so wie von Dennis beschrieben, ich habe eigentlich nicht den Eindruck, dass ich dort wirklich sehr gezielte Auskünfte bekommen könnte.
Ganz sicher weiss ich aber, dass, wenn was schiefläuft erst mal jeder Schuld ist, -- nur nicht die Druckerei.
Da bekommt man dann Aussagen zu hören von denen schon ich weiss das das faule Ausreden sind und das will was heissen.
Grüsse
Günter
ZITAt (Dennis @ 11. 7. 2006 - 15.20 h) Um Daten in einen irgendwie gearteten Farbraum zu konvertieren, benötigt man drei Dinge:Angaben zum Quellfarbraum,Angaben zum Zielfarbraum,eine Konvertierungsvorschrift -- also die mathematischen Formeln, an Hand derer umgerechnet wird,einen PCS als übergeordneten geräteneutralen Farbraum, der als Farbbasis zur Umrechnung benötigt wird.[/quote]
Ah ja -- so sieht das also aus, wenn man bis drei, aber nicht bis vier zählen kann /biggrin.gif" style="vertical-align:middle" emoid="" border="0" alt="biggrin.gif" /> ... nein, Späßle gemacht.
Diese drei, äh, vier Dinge "braucht" man keineswegs, um in "einen irgendwie gearteten Farbraum zu konvertieren". Sondern man braucht sie, um gezielt und korrekt in einen bestimmten Farbraum zu konvertieren.
ZITAt (Dennis @ 11. 7. 2006 - 15.20 h) ... denn man kann die Rohdaten komplett ohne Konvertierung ausgeben. Dabei gibt es keinen Zielfarbraum und auch keine Konvertierungsvorschrift. Es werden die einzelnen Farbwerte ausgelesen, im Zuge der Farbinterpolation zu vollwertigen RGB-Werten komplettiert, und ohne Umrechnung in einen bestimmten Farbraum ausgegeben. Es wird also weder konvertiert, noch gibt es einen definierten Farbraum.[/quote]
Das ist Unsinn. Es gibt keine Konvertierung ohne Konvertierung. Um aus kamerainternen R-Daten, G-Daten und B-Daten brauchbare RGB-Daten zu machen, erfolgt selbstverständlich eine Rohdatenkonvertierung und damit unvermeidlicher-, zwangsläufiger- und naturgemäßerweise auch eine Farbraum-Konvertierung. Letztere kann implizit sein, und es kann eine triviale Konvertierung sein. Aber irgendeine ist es. Anderenfalls wären ja gar keine RGB-Daten da.
Gewöhnlich ist es wünschenswert, daß diese initiale Farbraum-Konvertierung eine klar definierte sein möge -- denn sonst kann man schließlich in der Weiterverarbeitung höchstens noch raten, wie die durch die RGB-Werte beschriebenen Farben eigentlich genau aussehen sollen.
ZITAt (Dennis @ 11. 7. 2006 - 15.20 h) Die Farbwerte werden sozusagen aus dem Kamerafarbraum übernommen ...[/quote]
Selbst wenn deine etwas naiven Annahmen über das Bayer-Farbinterpolationsverfahren richtig wären -- hier sagst du ja selber, daß die RGB-Daten hinterher in irgendeinen Farbraum vorliegen: dem (etwas nebulösen) "Kamerafarbraum" nämlich. Tatsächlich ist es aber nicht "der Kamerafarbraum" (so etwas gibt's gar nicht), sondern ein Farbraum, der sich aus den technischen Eigenschaften der Kamera plus dem gewählten Farbinterpolationsverfahren ergibt. Aber das ist an dieser Stelle eher nebensächlich ...
ZITAt (Dennis @ 11. 7. 2006 - 15.20 h) Der Sensor kennt zwar keine RGB-Werte, aber er kennt R-, G- und B-Werte. Diese werden direkt ausgelesen, und bekommen im A/D-Wandler einen Wert zwischen 0 und 4.095 zugewiesen. Das sind genau die Farben, die der Sensor "sieht". Diese Farben liegen exakt vor und sind auch genau so auslesbar.[/quote]
Wie ich schon sagte: deine Vorstellung darüber, was der Sensor "sieht" und was bei einer Rohdatenkonvertierung vor sich geht, ist eine starke Vereinfachung und hat mit der Realität nur ganz ungefähr zu tun. Du meinst offensichtlich, wenn der Rohwert z. B. eines roten Rohpixels, sagen wir, 3.743 lautet, dann wird dieser direkt und unmittelbar zu R = 234 im 8-bit-RGB-Tripel bzw. zu R = 59.888 im 16-bit-RGB-Tripel konvertiert? So einfach ist das aber nicht! Denn der Rohwert enthält neben dem Rot-Wert noch eine Menge ganz anderer Sachen, die mit aufwenigen Rechenoperationen extrahiert werden müssen. Ob am Ende tatsächlich 234 oder etwa 186 oder 241 oder sonstwas herauskommt, hängt von einer Menge von Faktoren ab.
ZITAt (Dennis @ 11. 7. 2006 - 15.20 h) Wichtig ist, das dabei logischerweise die originalen Farbwerte nicht verändert werden.[/quote]
Das ist weder wichtig noch logisch, sondern einfach nur naiv.
ZITAt (Dennis @ 11. 7. 2006 - 15.20 h) ... da von den für das Bildformat notwendigen 16 bit nur "die linken" 12 bit genutzt werden, und außerdem keine Gamma-Korrektur stattfand. Man kann dann die Werte mit 16 multiplizieren, und somit das volle 16-bit-Spektrum ausnutzen, natürlich entstehen bei dieser Spreizung Lücken im Histogramm, aber verloren geht nichts.[/quote]
Das ist schon wieder sehr naiv. Du meinst, durch Multiplikation mit 16 würden aus 12-bit-Daten auf einmal 16-bit-Daten? Lächerlich! Es würden die Daten einfach nur von den niederen zu den höheren 12 bit innerhalb der 16-bit-Wortbreite verschoben, weiter nichts. Es bleiben trotzdem 12-bit-Daten; von einer "Spreizung" kann keine Rede sein.
Nein, ich wiederhole es noch einmal: bei der Bayer-Farbinterpolation von 12-bit-Rohdaten entstehen RGB-Daten mit etwa 16 bis 24 bit (je nach Interpolationsverfahren). Und wird auch noch am Gamma herumgedreht, so steigt die Zahl der Bits noch einmal an.
ZITAt (Dennis @ 11. 7. 2006 - 15.20 h) Es fand aber bis zu diesem Augenblick keine Konvertierung der Sensordaten in einen (anderen) Farbraum statt.[/quote]
Noch einmal: diese Aussage ist absurd. Wenn gar keine Konvertierung in irgend einen Farbraum stattgefunden hätte, dann gäbe es auch nichts, was du mit deinen Augen angucken könntest. Es wäre allenfalls möglich, daß keine explizite Konvertierung stattgefunden haben könnte. Was aber nicht sehr sinnvoll wäre, weil du dann RGB-Daten in einem undefinierten Farbraum vorliegen hättest ... was etwas anderes ist als "kein Farbraum".
ZITAt (Dennis @ 11. 7. 2006 - 15.20 h) Die Farben blieben unberührt, es gab keine Vorschrift, wie welche Farben zu behandeln sind, oder "wohin" sie umgerechnet werden sollen. Sie werden quasi durchgereicht: Die originalen werden gespreizt und aufgehellt, die fehlenden ergänzt.[/quote]
Das ist soo lächerlich und zeigt, wie sehr du keine Ahnung hast, wovon du redest!
ZITAt (Dennis @ 11. 7. 2006 - 15.20 h) An Hand dieser "rohen" Daten kann man ein Kameraprofil erstellen, und das diesen Daten anhängen, damit sie farbrichtig von einem entsprechenden Programm wiedergegeben werden können.[/quote]
Und genau dies -- also das Anhängen bzw. Einarbeiten des Kamera-Farbprofiles -- muß der Rohdatenkonverter tun, weil sonst jedwede farbkorrekte Weiterverarbeitung des konvertierten RGB-Bildes ausgeschlossen ist. Und alle Rohdatenkonverter, die ich kenne, tun es auch. Zugegeben, ich kenne bei weitem nicht alle.
-- Olaf
Beiträge: | 2.871 |
Registriert am: | 05.03.2005 |
ZITAt (tatatu @ 11.07.2006 - 16:36) Wie würde das dann praktisch aussehen? Als untagged Tif?[/quote]Genau, Du erhältst ein 16bittiges TIFF oder PSD, dem Du dann ein Profil zuweisen kannst, oder PS interpretiert es eben im Arbeitsfarbraum. Wie das genau funktionieren kann, habe ich in meiner Anleitung für den dcraw-Konverter hier im Forum geschrieben.
ZITATAber die Gestalt der Arbeitsfarbräume für die Druckvorstufe - dachte ich zumindest - orientiert sich auch an realen Ausgabemöglichkeiten [ECI, Photogamut u.a. sind, soweit ich das bsilang verstanden hatte, gerade wg. z.B. der Probleme mit AdobeRGB entwickelt worden ...].[/quote]Schon, aber Du musst unterscheiden:
- Es gibt RGB-Farbräume, die sind als Eingabefarbraum konzipiert, wie zB ProPhotoRGB, das ja ursprünglich als ROMM-RGB von Kodak entwickelt wurde.
- Es gibt gezielt konstruierte Intermediär-Farbräume (Stichwort: Medienneutral), die eine optimale Ausgngsbasis für eine Konvertierung in einen CMYK-Farbraum liefern sollen - das heißt konkret: Alle Druckfarben miteinschließen.
- Es gibt Exoten, wie PhotoGamutRGB: "Normale" RGB-Farbräume sind auf Matrix-TRC-Profilen aufgebaut, sie werden also über die drei Primärfarben und einige Parameter definiert. Daher sind sie auch in der "Schuhsohle" so schön dreieckig. PhotoGamutRGB ist ein LUT-basierter Farbraum, dh. er wurde quasi wie ein CMYK-Farbraum "ausgemessen" und in einer Tabelle implementiert. Daher ist dieser RGB-Farbraum nicht dreieckig, sondern eher wie ein CMYK-Farbraum ausgestaltet. Dieser Farbraum ist aber auch - auf Grund seiner Annäherung an die Druckfarbräume - eher als ausgabeorientierter RGB-Farbraum anzusehen. Allerdings sollte er - im Gegensatz zu Matrix-TRC-Profilen - alle vier Rendering Intents bereitstellen, also auch perzeptiv. Dh. damit wäre es möglich, von ProPhotoRGB nach PhotoGamutRGB perzeptiv zu konvertieren. Das könnte wirklich eine Möglichkeit sein, muss ich mal bei Gelegenheit ausprobieren. Definitv nimmt dieser Farbraum auf Grund seiner Architektur eine absolute Sonderstellung ein.
ZITATSegen. Ein wahrer Segen :-))! Oder erfindest Du gerne alles dauernd neu?[/quote]Nein, aber "medienneutral" bedeutet "prozess-de-optimiert". Es sind zur Zeit auch einige Diskussionen darüber im Gange, aber Fakt ist, dass "medienneutral" sehr gehypt wurde, und bei weitem nicht so viele Probleme löst, wie es gerne dargestellt wird, aber dafür neue einführt. Bin mal gespannt, was die Experten da ausknobeln.
Beiträge: | 5.313 |
Registriert am: | 17.11.2004 |
ZITAt (guenterfrank @ 11.07.2006 - 17:37) Da bekommt man dann Aussagen zu hören von denen schon ich weiss das das faule Ausreden sind und das will was heissen.[/quote] /laugh.gif" style="vertical-align:middle" emoid="" border="0" alt="laugh.gif" /> Der gefällt mir...
Beiträge: | 5.313 |
Registriert am: | 17.11.2004 |
ZITAt (Dennis @ 11.07.2006 - 17:43) Allerdings sollte er - im Gegensatz zu Matrix-TRC-Profilen - alle vier Rendering Intents bereitstellen, also auch perzeptiv. Dh. damit wäre es möglich, von ProPhotoRGB nach PhotoGamutRGB perzeptiv zu konvertieren. Das könnte wirklich eine Möglichkeit sein, muss ich mal bei Gelegenheit ausprobieren. Definitv nimmt dieser Farbraum auf Grund seiner Architektur eine absolute Soderstellung ein.[/quote]
Laut Beschreibung ist das so [ http://www.photogamut.org/D_ICC_Profil.html ]:
ZITATBilder, die in digitalen Kameras oder Scannern entstanden sind, empfehlen wir relativ farbmetrisch in PhotoGamutRGB zu konvertieren. Extrem große Scanner- bzw. Kamerafarbräume könnten in Verbindung mit außergewöhnlich gesättigten Farben die Wandlung mit dem perzeptiven (oder fotografischen) Rendering Intent notwendig machen; dies wird man im Einzelfall entscheiden müssen. Der PhotoGamutRGB-Farbraum beinhaltet als ‚echtes’ Druckerprofil alle vier Rendering Intents.[/quote]
ZITATNein, aber "medienneutral" bedeutet "prozess-de-optimiert".[/quote] Das ist leider die Kehrseite. Ich meinte aber eher: ich will einfach in der möglichst immer gleichen [oder zumindest ähnlichen] Weise arbeiten, nicht dauernd anders. Dass ein in jeder Hinsicht optimales Ergebnis natürlich genau das erfordert, ist etwas anderes.
Danke + beste Grüße.
Beiträge: | 2.931 |
Registriert am: | 15.12.2005 |
ZITAt (01af @ 11.07.2006 - 17:38) Um aus kamerainternen R-Daten, G-Daten und B-Daten brauchbare RGB-Daten zu machen, erfolgt selbstverständlich eine Rohdatenkonvertierung und damit unvermeidlicher-, zwangsläufiger- und naturgemäßerweise auch eine Farbraum-Konvertierung.[/quote]Nein, das ist falsch. Bei einer Farbraumkonvertierung werden Daten vom einen Koordiantensystem in ein anderes übertragen. Hier wird lediglich das Koordinatensystem selbst ein wenig gestreckt, aber die Positionen der Farben relativ zum Koordinatensystem bleiben erhalten. Die Rohdatenkonvertierung mit Farbinterpolation hat nichts mit Farbraumkonvertierung zu tun.
ZITATLetztere kann implizit sein, und es kann eine triviale Konvertierung sein. Aber irgendeine ist es. Anderenfalls wären ja gar keine RGB-Daten da.[/quote]Die RGB-Daten entstehen durch die Farbinterpolation (Demosaicing) und haben mit einer Farbraumkonvertierung nichts zu tun. Keine Farbraumkonvertierung kann aus einzelnen R-, G- und B-Werten RGB-Tripel machen.
ZITATSelbst wenn deine etwas naiven Annahmen über das Bayer-Farbinterpolationsverfahren richtig wären[/quote]Sie sind es: Die jewiligen Farbwerte, die der Sensor liefert, werden natürlich nicht verändert. Das ist nicht naiv, sondern Tatsache.
ZITATTatsächlich ist es aber nicht "der Kamerafarbraum" (so etwas gibt's gar nicht), sondern ein Farbraum, der sich aus den technischen Eigenschaften der Kamera plus dem gewählten Farbinterpolationsverfahren ergibt.[/quote]Natürlich gibt es einen Kamerafarbraum. Wie jedes Eingabegerät, hat auch ein Sensor einen geräteabhängigen Farbraum. Wie kommst Du auf die Idee, dass ausgerechnet eine Kamera keinen Farbraum hat? Ich sage ja nicht, dass dieser immer und überall konstant ist. wenn Du weißt, wie man eine Kamera profiliert, dann weißt Du ja auch, dass ein Profil nur für bestimmte Lichtsituationen gilt. Wie sollte man überhaupt ein Profil erstellen, wenn die Kamera keinen Farbraum hat?
ZITATDu meinst offensichtlich, wenn der Rohwert z. B. eines roten Rohpixels, sagen wir, 3.743 lautet, dann wird dieser direkt und unmittelbar zu R = 234 im 8-bit-RGB-Tripel bzw. zu R = 59.888 im 16-bit-RGB-Tripel konvertiert?[/quote]Ganz genau so ist es, und das lässt sich auch einfach mit dcraw und PS nachvollziehen.
ZITATSo einfach ist das aber nicht! Denn der Rohwert enthält neben dem Rot-Wert noch eine Menge ganz anderer Sachen, die mit aufwenigen Rechenoperationen extrahiert werden müssen.[/quote]Was soll den ein Pixel noch so alles an "Sachen" speichern? Das ist lustig, das musst du mal erklären.
ZITATOb am Ende tatsächlich 234 oder etwa 186 oder 241 oder sonstwas herauskommt, hängt von einer Menge von Faktoren ab.[/quote]Ich kann Dir die Faktoren genau nennen:
- Der A/D-Wandler spuckt einen Wert aus
- Dieser wird um einen Faktor korrigiert, der die unterschiedliche Dichte der Mosaikfilter-Farben ausgleicht.
- Es wird eine einfache Spreizung auf das 16bit-Format oder eine Stauchung auf das 8bit.Format vorgenommen.
- Es wird eine Gama-Korrektur vorgenommen, um die lineare Kennkurve des Sensors auf die logarithmische der Ausgabemedien und des menschlichen Auges anzupassen.
- Es wird eine Farbraumkonvertierung vorgenommen.
- Bei der Speicherung in JPEG verändern sich die Werte gemäß der Komprimierung.
ZITATDas ist schon wieder sehr naiv. Du meinst, durch Multiplikation mit 16 würden aus 12-bit-Daten auf einmal 16-bit-Daten?[/quote]Ganz genau. Das kannst Du selber gerne mit dcraw und PS nachvollziehen. Du kannst direkt die 12bittigen Werte des Sensors un-interpoliert als Graustufen ausgeben, Du kannst an Hand dieser Werte eine Farbinterpolation vornehmen und so "rohe" 12bittige RGB-Tripel erhalten, Du kannst die Multiplikatoren der einzelenen Farbkanäle anwenden, Du kannst sie linear als 12bittiges PSD ausgeben lassen, oder linear als 16bittiges PSD - was Du willst!
ZITATEs würden die Daten einfach nur von den niederen zu den höheren 12 bit innerhalb der 16-bit-Wortbreite verschoben, weiter nichts. Es bleiben trotzdem 12-bit-Daten; von einer "Spreizung" kann keine Rede sein.[/quote]Nichts wir verschoben, es wird gespreizt Du beherrschst doch wohl die Multiplikation, oder? Ein 12bittiger Wert von 0 wird auf einen 16bittigen von 0 skaliert, und der 12 bittige Wert von 4.095 auf den 16bittigen Wert von 65.535. Dazwischen werden die anderen Werte verteilt. Das nennt sich Spreizung.
ZITATNein, ich wiederhole es noch einmal: bei der Bayer-Farbinterpolation von 12-bit-Rohdaten entstehen RGB-Daten mit etwa 16 bis 24 bit (je nach Interpolationsverfahren).[/quote]Aber doch nicht für die Werte, die schon da sind! Die wurden in 12bit vom Sensor aufgezeichnet, und dienen als Berechnungsgrundlage für die zu interpolierenden Werte. Da diese sowieso nur interpoliert werden, ist dort eine höhere Genauigkeit absolut absurd. Was nutzen Dir ein 24bittiger R- und B-Wert, die auch noch abgeschätzt wurden, wenn der als Rechengrundlage dienende "echte" (ausgelesene) Wert nur in 12 bittiger Genauigkeit vorliegt?
Beiträge: | 5.313 |
Registriert am: | 17.11.2004 |
ZITATUnd wird auch noch am Gamma herumgedreht, so steigt die Zahl der Bits noch einmal an.[/quote]Ja, bei jeder Rechenoperation gibt es Rundungsfehler.
ZITATWenn gar keine Konvertierung in irgend einen Farbraum stattgefunden hätte, dann gäbe es auch nichts, was du mit deinen Augen angucken könntest.[/quote]Willst Du es nicht verstehen?
Der Sensor zeichnet Graustufen in 12bittiger Genauigkeit an, die kann ich mir angucken.
Diese Graustufen können in die jeweiligen Farben des Mosaikfilters umgewandelt werden. Die kann ich mir auch angucken.
Zu jedem Pixel können die zwei fehlenden Farben interpoliert werden, dann erhalte ich endlich RGB-Pixel, und die kann ich mir noch viel besser angucken.
Ich kann jetzt noch die 12bit auf 16bit spreizen, damit die Ansicht im 16bit-Modus stimmt. Ich kann jetzt noch eine Gamma-Korrektur vornehmen, damit nicht die hellst Tonwertstufe im Bild die Hälfte der dargestellten Tonwerte einnimmt.
Aber ich habe bis dahin noch keine Farbraumkonvertierung vorgenommen, die besagen würde, RGB[Quelle] wird nach RGB[Ziel] umgewandelt. Außer natürlich, Du bezeichnest die Spreizung von 12bit nach 16bit oder die Gammakorrektur als Farbraumkonvertierung.
ZITATUnd genau dies -- also das Anhängen bzw. Einarbeiten des Kamera-Farbprofiles -- muß der Rohdatenkonverter tun,[/quote]Nein, das ist falsch. Was denkst Du warum PS die Option anbietet, ein Profil zuzuweisen? Damit man genau das machen kann. Ein Profil muss vor der Bildbearbeitung zugewiesen werden, aber nicht zwangsläufig vom Konverter.
Aber wie ich sehe, hast Du noch immer nicht die von mir angeratenen Artikel bei bacICColor gelesen, sonst wüßtest Du, wie das professionell gehandhabt wird.
Beiträge: | 5.313 |
Registriert am: | 17.11.2004 |
Einfach ein eigenes Forum erstellen |