Transparenz selbst berechnen aus RGB Werten

Hallo Leute,

ich habe folgendes Problem. Ich habe Bitmaps mit halbtransparenten Grafiken beinhaltet. Hintergrundfarbe ist Magenta der Bitmaps.

So nun möchte ich jedoch in meiner Applikation die volle Transparenz nutzen und zwar ohne Boardmittel. Das heißt ich müsste anhand des Magenta Wertes irgendwie das Megenta entfernen. Ich hatte mir überlegt, dass man eventuell irgendeine Differenz der RGB Werte berechnen kann und damit den Alpha Kanal befüllt. Jedoch weiß ich nicht wie die Berechnung laufen müsste.

Wäre cool wenn sich ein Grafikgenie hier aus dem Forum der SAche mal kurz annehmen kann. Wahrscheinlich ist das eine ganz einfache Formel^^

Danke schonmal!

Grüße ViperNeo

Also ich finde, daß Magenta da eine nicht so gute Wahl ist, weil der Wert gleich aus zwei RGB-Komponenten zusammengesetzt ist. Im Prinzip heißt das, was du vorhast "Chroma Keying", also einen Farbwert zu "Keyen" bzw. zu Maskieren. Beschrieben ist die Vorgehensweise ganz grob in diesem Artikel: Chroma_key.

okay, danke schonmal für das stichwort. welche farbe wäre denn für sowas interessant? ich dachte an magenta weil windows das auch nutzt in vielen grafiken (transparency key etc.).

okay das eine füllfarbe das beste ist, grün oder blau, habe ich nun rausgefunden... frage ist nun nur, wie man das genau berechnet... irgendwie werd ich aus der formel nicht so schlau...

Es kommt ganz darauf an, was in den Bildern so enthalten ist. Für manche Zwecke eignet sich Blau besser, für andere Grün. Wenn du Bäume freistellst, solltest du also nicht unbedingt Grün als Hintergrundfarbe nehmen.
Wie es funktioniert, ist doch eigentlich offensichtlich. Wenn du einen Farbwert hast, wie #00FF00, und du willst den Grün-Kanal durch den Alpha-Wert ersetzen, dann ist der Pixel völlig transparent. Wenn du irgendwas hast, wie #007700 oder #437750, dann ist in beiden Fällen der Alpha-Wert 0x77 bzw. 0.5.

Hallo ViperNeo,

da es schon von Grundsatz her nicht möglich ist, die Information von 4 Bytes in nur 3 Bytes zu speichern, ist es auch nicht möglich aus 3 Bytes wieder die 4 Bytes herzustellen. Oder anders gesagt, wenn du ein beliebiges RGBA-Bild auf einen einfarbigen (z.B. grünen) Hintergrund zeichnest, dann kannst du anschießend nicht mehr das RGBA-Ausgangsbild daraus zurückrechnen.

Wenn du z.B. grau mit halber Transparenz auf den grünen Hintergrund zeichnest, dann kommt ein graugrün raus. Das gleiche passiert aber, wenn du dieses graugrün ohne Transparenz auf den grünen Hintergrund zeichnest. Kein Mensch (und erst recht kein Computer) kann nachher sagen, welche der beiden Ausgangssituationen vorlag. Und es gibt ja nicht nur zwei mögliche Ausgangssituationen sondern es gibt für jede Farbe (im Schnitt) 256 Kombinationen, die im Ergebnis diese Farbe liefern. Welche der 256 Situationen zu dem Ergebnis geführt haben, kann man nachher aber gerade nicht mehr sagen. Diese Information ist bei der Reduktion von 4 Bytes auf 3 Bytes unwiederbringlich verloren gegangen.

herbivore

Hallo herbivore,

prinzipiell hast du ja Recht, aber das Verfahren wird trotzdem angewendet, um ein Bild von einem Hintergrund freizustellen. Bestes Beispiel ist das Bluescreen- bzw. Greenscreen-Verfahren, bei dem Schauspieler vor einem blauen bzw. grünen Hintergrund gefilmt werden und dann in einen anderen Hintergrund reingesetzt werden. Daß es funktioniert, sieht man jeden Tag z.B. in der Tagsschau, wo auch der Hintergrund aus dem Computer kommt. Natürlich gibt es dabei Beschränkungen, z.B. dürfen die Moderatoren keine grünen bzw. blauen Sachen anhaben, und bei feinen Strukturen wie Haaren kommt es oft zu Darstellungsfehlern. Aber prinzipiell funktioniert es schon...

Schöne Grüße,
Christian

Hallo MrSparkle,

freistellen ist auch was anderes, als der Versuch, den kompletten Transparenz-Kanal wiederherzustellen. Laut ViperNeo geht es ihm um Bitmaps mit halbtransparenten Grafiken. Außerdem funktioniert selbst das Freistellen - wie du sagst hast - nur, wenn die freizustellende Farbe nicht im Bild vorhanden ist.

Klar kann man versuchen, es bestmöglich hinzubekommen, aber es gibt eben prinzipielle Grenzen. Auf die wollte ich hinweisen.

herbivore

hm... danke... ich hab etwas rumgespielt mit verschiedenen farben und ich bin der festen überzeugung, dass es doch irgendwie gehen muss...

folgendes habe ich ausprobiert. ich habe eine schwarze grundfläche mit den werten (A255 R0 G0 B0). Darüber habe ich eine Fläche gezeichnet mit den Werten (A100 R100 G100 B0). Die neue Farbe die durch die Überlagerung entsteht ist die (A255 R40 G40 B0). Nun frage ich mich, man müsste doch anhand dieser neuen Farbe eine konkruente Farbe berechnen können mit Alpha-Kanal, denn jede Farbe mit Alpha Kanal müsste sich doch zurückberechnen lassen über einen bestimmten Farbwert. Oder sehe ich da was falsch? Leider stoße ich bei meinen Berechnungsversuchen an meine mathematischen Grenzen. Aber irgendwie denke ich, dass wenn man die darunterliegende Farbe kennt, man doch den Rückweg berechnen können müsste. Irgendwie macht das GDI+ doch auch wenn ich was zeichne. Und Windows kann das mit Magenta auch sogar in Word.

Hallo ViperNeo,

Oder sehe ich da was falsch?

ja, siehst du. Was du falsch siehst, habe ich schon oben beschrieben, siehe das graugrün-Beispiel. Die Berechnung, die dir vorschwebt, ist mathematisch unmöglich (bzw. gibt es eben zuviele unterschiedliche Lösungen, von denen keiner weiß, welches die richtige ist). Auf dem Hinweg hat du einen Informationsverlust von einem ganzen Byte, das du eben nicht wieder rekonstruieren kannst.

Wenn es dir gelingen würde, den vollständigen Informationsgehalt von 4 Bytes in 3 Bytes unterzubringen, wäre dir der Nobelpreis (genauer gesagt der Turing-Award) sicher. Aber es geht eben nicht. Wenn es ginge, dann könnte man die Kompression von 4 Bytes in 3 Bytes in einer Schleife immer wieder anwenden, mit immer wieder einem zusätzlichen Byte und damit beliebig große Informationsmengen in 3 Bytes speichern. Es ist offensichtlich, dass das unmöglich ist.

herbivore

okay, dann bleibt mir wohl nur ein nahezu perfektes berechnungsergebnis^^ aber wie macht das microsoft bei seinen icons mit magenta hintergrund? da wird einfach alles was magenta ist wahrscheinlich ersetzt mit alpha wie mrsparkle das gesagt hat. okay glaube ich habs langsam verstanden^^

Hallo herbivore,
hallo ViperNeo,

das ist ein berechtigter Hinweis. Ich habe einfach vorausgesetzt, daß es ganz offensichtlich ist, daß das Verfahren seine Grenzen hat. Daß heißt aber nicht, daß es nicht funktioniert. Zumal bei solchen einfachen Sachen wie Icons. Jedenfalls wenn der Ersteller dabei beachtet hat, keine Magenta-farbenen Icons zu zeichnen 😃

Für besonders harte Fälle kann man den Algorithmus auch anpassen um den Übergang zwischen Farben und Transparenz genau steuern zu können. Also z.B. welche Toleranzwerte verwendet werden sollen und wie hart oder weich der Übergang stattfinden soll. Dann kann man mit wenigen Einstellungen fast jedes Bild freistellen.

Warum allerdings Microsoft für sowas ausgerechnet Magenta gewählt hat, habe ich bisher auch nicht verstanden. Aber ich kenne das eigentlich nur von GIF-Bildern, die mit richtiger Transparenz erstellt wurden und trotzdem eine Hintergrundfarbe definiert hatten, die dann an den in Wirklichkeit transparenten Pixeln angezeigt wird. Da hat man aber auch keinen weichen Übergang, weil in GIFs ein Pixel immer nur transparent oder nicht transparent sein kann.

Schöne Grüße,
Christian

Hallo ViperNeo,

aber wie macht das microsoft bei seinen icons mit magenta hintergrund?

naja, solange nur eine feste Farbe dazu führt, dass alle Pixel dieser Farbe volle Transparenz bekommen, ist das natürlich kein Problem. Aber du wolltest ja im Gegensatz dazu Halbtransparenz.

herbivore

okay und diese halbtransparenz ist nicht möglich, weil man das genaue mischverhältnis der grundfarbe und der dahinterliegenden farbe unmöglich berechnen kann und somit auch nicht auf die grundfarbe kommen kann?

Hallo ViperNeo,

so ist es.

herbivore

Hallo ViperNeo,

Also wegen Magenta hab ich jetzt doch mal nachgeschaut, und ich hab hier folgendes gefunden:

Back in the Win32-only days, there were some Common Controls (like the Toolbar, and ListView) that took these bitmaps and a colour to be treated as transparent, and then rendered that colour as transparent. I imagine that, behind the scenes, they used functions like TransparentBtl.

Das Konzept kommt mir aus der System.Drawing.Bitmap-Klasse bekannt vor, da gibt es einen TransparencyKey, der genau die eingestellte Farbe transparent zeichnet. Also definitiv ohne weichen Verlauf bzw. mit einen 1Bit-Alpha-Kanal. Wenn deine Icons so aufgebaut sind, kannst du sie anzeigen, ohne selbst was implementieren zu müssen. Wenn nicht, sehe ich aber wie gesagt nicht viele Möglichkeiten, weil Magenta eine sehr schlecht "zu keyende" Farbe ist.

Zu deinen Berechnungsversuchen hat doch herbivore schon sehr treffend gesagt:

Wenn es dir gelingen würde, den vollständigen Informationsgehalt von 4 Bytes in 3 Bytes unterzubringen, wäre dir der Nobelpreis (genauer gesagt der Turing-Award) sicher.

Die Ursprungsfarbe wiederherzustellen ist nicht möglich, bzw. nur annäherungsweise durch das Keying. Ich würde mir an deiner Stelle lieber den Grafiker vornehmen, der die Icons gestaltet hat 8)

Schöne Grüße,
Christian