Du arbeitest dich Pixel für Pixel in einer Schleife durch. Dabei wendest du + (NSColor *)colorWithDeviceCyan:(float)cyan magenta:(float)magenta yellow:(float)yellow black:(float)black alpha:(float)alpha an, und kannst dann mit - (void)getRed:(float *)red green:(float *)green blue:(float *)blue alpha:(float *)alpha davon den Rot/Grün/Blau Anteil holen. Bin mir nicht sicher, aber ich hoffe es klappt so - sicher gibt es eine elegantere Methode.

Gruss
Wulfie

Normalerweise sind Bilder in PNG, TIFF, JPEG oder GIF oder sonstwas und nicht in rgb oder cmyk gespeichert. Und jedes Bildformat legt fest ob die Farben als rgb oder cmyk gespeichert sind.

Und eine NSBitmapImageRep ist immer RGB oder RGBA.

Deshalb verstehe ich die Frage überhaupt nicht...

-- hns

Original von hns
Normalerweise sind Bilder in PNG, TIFF, JPEG oder GIF oder sonstwas und nicht in rgb oder cmyk gespeichert. Und jedes Bildformat legt fest ob die Farben als rgb oder cmyk gespeichert sind.

Hmmm - jetzt bringst Du aber Farbräume und Bildformate etwas durcheinander, oder? Jedes Bild ist sicherlich in einem Format gespeichert, darum ging es macuser ja gar nicht. Aber einen Farbraum hat jedes digitale Bild. Und obwohl nicht alle Kombinationen möglich sind, legt das Format das nicht fest - z.B. können TIFF und JPEG (genauer JFIF) sowohl Bilder im CMYK- als auch im RGB-Farbraum speichern.

Original von hns
Und eine NSBitmapImageRep ist immer RGB oder RGBA.

Nein.

@Wulfie: Das sollte gehen, ist aber bestimmt etwas langsam...

@macuser: Schau mal z.B. unter CGImageCreateCopyWithColorSpace()

Original von mattik

Original von hns
Normalerweise sind Bilder in PNG, TIFF, JPEG oder GIF oder sonstwas und nicht in rgb oder cmyk gespeichert. Und jedes Bildformat legt fest ob die Farben als rgb oder cmyk gespeichert sind.

Hmmm - jetzt bringst Du aber Farbräume und Bildformate etwas durcheinander, oder? Jedes Bild ist sicherlich in einem Format gespeichert, darum ging es macuser ja gar nicht. Aber einen Farbraum hat jedes digitale Bild. Und obwohl nicht alle Kombinationen möglich sind, legt das Format das nicht fest - z.B. können TIFF und JPEG (genauer JFIF) sowohl Bilder im CMYK- als auch im RGB-Farbraum speichern.

Meine ich doch: jedes Bildformat legt fest wie es gespeichert ist: als CMYK oder RGB-Farbraum oder etwas anders (RGB-Farbtabelle bei GIF). Und das schließt natürlich den Fall ein, dass im Dateiformat auch ein oder zwei Bits verschiedene Farbräume erlauben. Damit wird die Umwandlung aber schon beim dekodieren des Farbformats gemacht.

Original von hns
Und eine NSBitmapImageRep ist immer RGB oder RGBA.

Nein.

Hm: warum steht dann in der Doku unter getBitmapDataPlanes:

Color components in planar configuration are arranged in the expected order—for example, red before green before blue for RGB color.

Man kann allerdings die Farbe eines Pixels mit colorAtX:y: auslesen und diese NSColor dann wahlweise nach RGB oder CMYK oder was sonst noch supported wird auslesen.

Ich weiss von Thorsten Lemke (der mit dem GraphicConverter) die Umwandlung von CMYK nach RGB nicht völlig trivial ist.

Aber Details weiss ich nicht mehr

Alex

Original von below
Ich weiss von Thorsten Lemke (der mit dem GraphicConverter) die Umwandlung von CMYK nach RGB nicht völlig trivial ist.

Ist GraphicConverter eigentlich schon in Core Image und Cocoa umgeschrieben worden?

Original von hns
Hm: warum steht dann in der Doku unter getBitmapDataPlanes:

Color components in planar configuration are arranged in the expected order—for example, red before green before blue for RGB color.

Es ist ein Beispiel. Für CMYK wäre es die Reihenfolge Cyan, Magenta, Yellow, Black (Key). In der Doku steht z.B. unter initWithBitmapDataPlanes: ...:

The spp (samples per pixel) argument is the number of data components. It includes both color components and the coverage component (alpha), if present. Meaningful values range from 1 through 5. An image with cyan, magenta, yellow, and black (CMYK) color components plus a coverage component would have an spp of 5; a grayscale image that lacks a coverage component would have an spp of 1.

Original von mattik

Original von hns
Hm: warum steht dann in der Doku unter getBitmapDataPlanes:

Color components in planar configuration are arranged in the expected order—for example, red before green before blue for RGB color.

Es ist ein Beispiel. Für CMYK wäre es die Reihenfolge Cyan, Magenta, Yellow, Black (Key). In der Doku steht z.B. unter initWithBitmapDataPlanes: ...:

The spp (samples per pixel) argument is the number of data components. It includes both color components and the coverage component (alpha), if present. Meaningful values range from 1 through 5. An image with cyan, magenta, yellow, and black (CMYK) color components plus a coverage component would have an spp of 5; a grayscale image that lacks a coverage component would have an spp of 1.

Danke! Ich habe auch den colorSpaceName:-Teil von -init bisher immer übersehen...

Damit kann das AppKit anscheinend steuern wann die Umwandlung in RGB gemacht wird, denn der Bildschirm kann nur RGB. Es muss also nicht - wie ich gedacht hatte - schon beim Einlesen von JPEG/TIFF usw. aus einer Datei geschehen. Sondern kann auch bei -draw erfolgen.

Die Frage die sich mir trotzdem stellt: wann interessiert mich das? Wenn ich in einem anderen Dateiformat abspeichere, dann wird es wennnötig hinter den Kulissen umgewandelt. Wenn ich es auf den Bildschirm male - dann muss es sowieso gleich aussehen.

Oder vielleicht wenn ich das Bild als RGB bearbeiten will (z.B. Farbauszüge, Farbfilter, Farbeffekte). Dann muss ich das Bild natürlich pixelweise als RGB auslesen können. Das kann ich mit einer Schleife über

machen. Dabei kann ich anscheinend sogar wählen ob ich die NSColor als CMYK oder RGB auslesen möchte - egal wie es gespeichert ist.

-- hns

Stimmt - man kann die Farbräume der Farben konvertieren und beliebig drauf zugreifen. Für einfache Sachen ist es egal, wie die Bitmap gespeichert ist. Aber es gibt eine Menge Fälle, in denen das nicht egal ist. Einmal kostet die Konvertierung Rechenkapazität. Wenn ich z.B. von "irgendwo draußen" rohe Bitmap-Daten bekomme und die schnell (z.B. flüssig animiert) darstellen will, könnte ich mir eine Farbraumkonvertierung, auch eine implizite, kaum leisten. Und dann ist die Konvertierung nicht nur langsam, sondern nicht immer exakt und problemlos durchführbar. Die Farbräume haben verschiedene Umfänge, d.h. es gibt Farben, die in CMYK darstellbar sind, aber nicht in RGB - und andersrum. Wenn Du hin- und zurückkonvertierst, bleibt Dir nur die Schnittmenge übrig. Und weil die Auflösung ebenfalls unterschiedlich ist, bekommst Du Rundungsfehler rein. Außerdem ist die Abbildung von RGB nach CMYK nicht eindeutig: Viele in CMYK unterschiedliche Farben werden in RGB auf eine Farbe projiziert (Projektion von 4D nach 3D, da geht immer etwas flöten). Wenn Du mit RGB arbeitest und das Zeugs zum Schluss einfach wieder als CMYK speicherst, werden Dir die Print-Leute aufs Dach steigen, weil das drucktechnisch (und auch visuell) schon einen Unterschied macht...

sorry für's Reviven des Threads, hab aber eine Anschlussfrage:

Wie kann ich denn den colorspace eines bildes verlässlich herausfinden? [[[myImage representations] objectAtIndex:0] colorSpaceName] gibt mir bei egal welchem Bild eigentlich immer RGB zurück, auch wenn sie das nicht sind... bei .eps dateien hat NSImage sowieso seine Probleme...
gibt es vielleicht eine verlässliche Carbon-Funktion, um für egal welchen Image-File-Type den color space zu bekommen? Vor allem CMYK und RGB...

danke,
oddy

Anstelle nur eine Representation abzufragen, würde ich erstmal alle untersuchen:

wird gemacht, ok, danke. aber dann?

ich brauche eine Möglichkeit, abzufragen, ob es cmyk oder rgb ist, unabhängig vom Datei-Format, sei es eps oder png, pdf oder jpg. für jpg,tif und png reicht es auch, ein MDItemRef zu erstellen und kMDItemColorSpaceName abzufragen. Aber für pdf, eps u.ä. funktioniert das schon nicht mehr...

Danke!

ich brauche eine Möglichkeit, abzufragen, ob es cmyk oder rgb ist, unabhängig vom Datei-Format, sei es eps oder png, pdf oder jpg. für jpg,tif und png reicht es auch, ein MDItemRef zu erstellen und kMDItemColorSpaceName abzufragen. Aber für pdf, eps u.ä. funktioniert das schon nicht mehr...

Das kann auch nicht funktionieren, ein PDF, PS oder EPS hat nicht einen Farbraum. Jedes Enthaltene Objekt kann ich einem anden Farbraum definiert sein (inkl. Schmuckfarben).

oh, wie gut, dass ich das jetzt weiß danke dir. Damit hat sich die Sache erledigt. mit MDItemCopyAttribute geht es wunderbar.

lg
oddy

Sache hat sich doch nicht erledigt.
Mein Cousin, der das Programm braucht, meint, es gibt cmyk und rgb eps dateien.
Wie kann ich also herausfinden, welchen colorspace nun wirklich die eps datei hat? man suche in google nach "cmyk eps file" download, oder "rgb eps file" download, findet man genug beispiele...
Mit NSImageRep bekomme ich immer NSCalibratedRGBColorSpace, ist also nutzlos... MDItem funzt da nicht, die attributes hat eine eps datei nicht...

DPI kann ich auch nicht errechnen, da ich bei der rep als pixel immer 0x0 bekomme, size ist da...

Sache hat sich doch nicht erledigt.
Mein Cousin, der das Programm braucht, meint, es gibt cmyk und rgb eps dateien.
Wie kann ich also herausfinden, welchen colorspace nun wirklich die eps datei hat? man suche in google nach "cmyk eps file" download, oder "rgb eps file" download, findet man genug beispiele...
Mit NSImageRep bekomme ich immer NSCalibratedRGBColorSpace, ist also nutzlos... MDItem funzt da nicht, die attributes hat eine eps datei nicht...

Meinst Du solche Dateien: Logo Download? Das ist eine einfache EPS-Datei in der nur der CMYK Farbraum genutzt wird. Das ist alles.

DPI kann ich auch nicht errechnen, da ich bei der rep als pixel immer 0x0 bekomme, size ist da...

Ein PDF, PS oder EPS hat auch keine Auflösung -> also alles richtig.

ok, und wie finde ich nun heraus, wenn bei einer datei nur ein farbraum verwendet wird, welcher das ist?

ok, und wie finde ich nun heraus, wenn bei einer datei nur ein farbraum verwendet wird, welcher das ist?

Es gibt nur einen weg, Du musstest die Datei Parsen. Das kann man aber keinem empfehlen, mit einer einfachen suche nach DeviceCMYK oder ähnlichem ist es nicht getan. In jeder PS Datei findest Du einen eigenen Befehlssatz den Du entsprechend Interpretieren müsstest.