@Bernhard: Das bei der Umwandlung von CMYK in
RGB Verluste auftreten ist mir schon bewusst, nur soll das ganze am ende als Textur auf einem 3D-Model in GLScene dienen. Da müsste man der Scene die CMYK-Darstellung beibringen und das geht zum einen noch über meinen Horizont, zum anderen müsste man das ganze dann auch an jedes Update anpassen. Glücklicherweise ist die Umwandlung eher der Ausnahmefall und mit annähernd richtigen Farben kann man schon viel besser leben als mit einer komplett falschen Darstellung.
@Medium: Meine Vermutung war ja fast, das der Kunde einen 25 Seiten pro Sekunde Drucker hat statt eines Bildschirms.
Ich werd mich mal durch deine Links arbeiten.
@jus: Auch die Vampyre-Bibliothek werd ich mir mal anschaun. Die Sache, das ich dem Kunden schlecht sagen kann sieht in etwa so aus:
Nichtinformatiker haben ja selten wirklich ein Verständnis dafür, was so alles im Hintergrund abläuft. Sprich sein Photohop kann das richtig, die Windowsanzeige kann das richtig und was erschwerend hinzukommt: das Konkurenzprodukt kann das richtig!
Nun handelt es sich bei dem Konkurenzprodukt leider um den Markführer in dem Bereich, der auch den Standard definiert. Das macht also einen denkbar schlechten Eindruck, wenn wir da auf einmal ankommen und sagen: "Tut uns leid, aber die Methode, die ihr bisher verwendet habt und die beim eigentlichen Marktführer läuft, ist an sich ungeeignet. Ändert die mal."
Ich persönlich finds unsinnig auf biegen und brechen einen für Drucker optimierten Farbbaum zur reinen Darstellung über Monitor zu verwenden. Aber man steckt ja nicht in den Köpfen der Leute. Da wird sich vielleicht jemand gedacht haben "Je mehr Farb/Bit-Tiefe umso besser!".