4. RGB -> RG Farbraum Umwandlung

RGB -> RG Farbraum Umwandlung

  • A

    Hi Leute!

    Habe ein Problem mit der Umwandlung vom RGB in den RG Farbraum.
    Lese eine Grafikdatei aus, ein Pixel besteht aus 3 Werten (für RGB), jedes Pixel wiederum aus einem Wert zwischen 0 und 255.

    Formel für RG lautet einfach: R = R / (R+G+B), G = G / (R+G+B)

    z.B. RGB Daten: R = 37, G = 155, B = 255
    Umwandlung RG: R = 0,08277404921, G = 0,34675615212527

    Meine Fragen nun:
    1. Was passiert mit dem B im RG-Farbraum? Wird der einfach 0 gesetzt?
    2. Wie sind diese Werte im Beispiel zu interpretieren? Denn es muss ja ein Wert zwischen 0 und 255 sein. Einfach mal 100 rechnen?

    Wär super wenn mir jemand helfen könnte.

    Thx
    Adamn

    0
  • M

    1. ich denke ja. vielleicht hilft google (sicher)
    2. ja, die werte musst du dann wiede rmit 255 multiplizieren, damit wie zwischen 0 und 255 liegen.

    0
  • N

    Öh wenn du einen RG-Farbraum hast, dann hast du ja kein Blau mehr, deswegen ja auch RG und nicht RGB 😉 Die Farbkanäle werden halt bissl umgerechnet, dass man das fehlende Blau etwas kompensieren kann.
    Wobei ich jetzt aber noch nie was von einem RG-Farbraum gehört habe, aber ist auch egal 😉

    Bei Frage 2: Du musst das mit 255 multiplizieren, da deine Ergebnisse ja den normalisierten Wert darstellen.

    0
  • H

    Adamn schrieb:

    1. Was passiert mit dem B im RG-Farbraum? Wird der einfach 0 gesetzt?

    Welchem B? Es gibt nur R und G.

    Adamn schrieb:

    2. Wie sind diese Werte im Beispiel zu interpretieren? Denn es muss ja ein Wert zwischen 0 und 255 sein. Einfach mal 100 rechnen?

    Wieso muss es ein Wert zwischen 0 und 255 sein?

    0
  • N

    Helium schrieb:

    Adamn schrieb:

    2. Wie sind diese Werte im Beispiel zu interpretieren? Denn es muss ja ein Wert zwischen 0 und 255 sein. Einfach mal 100 rechnen?

    Wieso muss es ein Wert zwischen 0 und 255 sein?

    Naja er hat ja gesagt, dass bei seinem Ausgangs-RGB-Pixel jeder Farbkanal Werte zwischen 0 und 255 hat. Also ist mal stark davon auszugehen, dass er 8 Bit Pro Farbkanal benutzt (was ja auch normal ist). Dann müssen auch die Werte der RG-Farbkanäle wieder zwischen 0 und 255 liegen

    0
  • A

    Danke Leute für eure Antworten!
    Übrigens ist RG der chromatische Farbraum, d.h. die Helligkeitsinformationen werden eliminiert. Ich brauche diesen, um eine Hand zu tracken und dort spielt die Helligkeit der Farbe keine Rolle.

    Helium schrieb:

    Welchem B? Es gibt nur R und G.

    Ein *.pnm File (magic number P6) wird eingelesen. Jedes Pixel besteht lt. Definition aus einem Trippel (R G B).

    Trotz Umwandlung in RG-Farbraum brauch ich also immer noch 3 Werte, da wieder ein *.pnm File erzeugt werden soll.
    Wird daher B einfach auf 0 gesetzt? Konnte im Internet leider nix drüber finden.

    0
  • B

    Adamn schrieb:

    Helium schrieb:

    Welchem B? Es gibt nur R und G.

    Ein *.pnm File (magic number P6) wird eingelesen. Jedes Pixel besteht lt. Definition aus einem Trippel (R G B).
    Trotz Umwandlung in RG-Farbraum brauch ich also immer noch 3 Werte, da wieder ein *.pnm File erzeugt werden soll.
    Wird daher B einfach auf 0 gesetzt? Konnte im Internet leider nix drüber finden.

    mit B kannst du nachen was du willst, wenn du's nicht brauchst. Warum nimmst du fuer's abspeichern nachher nicht ein besseres Format?

    0
  • A

    Blue-Tiger schrieb:

    Adamn schrieb:

    Helium schrieb:

    Welchem B? Es gibt nur R und G.

    Ein *.pnm File (magic number P6) wird eingelesen. Jedes Pixel besteht lt. Definition aus einem Trippel (R G B).
    Trotz Umwandlung in RG-Farbraum brauch ich also immer noch 3 Werte, da wieder ein *.pnm File erzeugt werden soll.
    Wird daher B einfach auf 0 gesetzt? Konnte im Internet leider nix drüber finden.

    mit B kannst du nachen was du willst, wenn du's nicht brauchst. Warum nimmst du fuer's abspeichern nachher nicht ein besseres Format?

    Weil ich lt. Vorgabe dieses Format verwenden muss!

    0
  • C

    Du könntest im B-Kanal ja die rausgerechnete Helligkeitsinformation unterbringen, damit du im Ernstfall das Bild rekonstruieren kannst (oder du packst dort "B/(R+G+B)" rein - ist zwar redundant, aber möglich).

    0
  • H

    nep schrieb:

    Helium schrieb:

    Adamn schrieb:

    2. Wie sind diese Werte im Beispiel zu interpretieren? Denn es muss ja ein Wert zwischen 0 und 255 sein. Einfach mal 100 rechnen?

    Wieso muss es ein Wert zwischen 0 und 255 sein?

    Naja er hat ja gesagt, dass bei seinem Ausgangs-RGB-Pixel jeder Farbkanal Werte zwischen 0 und 255 hat. Also ist mal stark davon auszugehen, dass er 8 Bit Pro Farbkanal benutzt (was ja auch normal ist). Dann müssen auch die Werte der RG-Farbkanäle wieder zwischen 0 und 255 liegen

    Naja, meine Suchergebnisse zum Thema R-G-Farbraum haben immer irgendwas mit der Erkennung von menschlicher Haut in Bildern zu tun gehabt und alle Skalen, die in den Dokumenten vorkamen für die R- und G-Werte gingen von 0 bis 1. Deswegen nehme ich an, das es so üblich ist.

    0
  • N

    Ja und? Das hat ja jetzt nichts so wirklich damit zu tun 😉

    0
  • H

    Naja, wozu sollte man einen Wert einfach so mit 255 Multiplizieren, zumal die Algorithmen, die so im Internet zum Thema Hauterkennung rumfliegen alle für 0-1 ausgelegt sind (er will eine Hand "tracken").
    Kann doch keiner Ahnen, dass er die Bilder auch als pnm speichern will. Aber was ist das in dem Fall überhaupt für 'ne Frage. Wenn pnm ein bestimmtes Format vorgibt, muss man sich eben daran halten.

    0
  • A

    Jetzt hab ich mal ein Ergebnis meiner Umwandlung. Sieht aber doch recht seltsam aus.

    Originalbild: http://img516.imageshack.us/img516/4993/colorrgbzh7.jpg
    RG-Pendant: http://img211.imageshack.us/img211/7155/colorrgeo1.jpg

    Ein Großteil des Bildes ist weiß, das Pixel hätte dann die Werte RGB(255,255,255).
    Der normalisierte RG-Wert laut Formel (R=(R/(R+G+B))*255,G=(G/(R+G+B))*255, B=0) ergibt dann RG(85,85,0), was dieses "Schlamm-Grün" im Ergebnisbild liefert.

    Soll das so aussehn oder ging da was schief mit Runden? Also liegt da ein verfälschtes Ergebnis durch Abschneiden der Nachkommastellen vor?

    0
  • H

    85 ist richtig. Gilt übrigens nciht nur für weiß, sondern auch für Grautöne (Helligkeitsinformationen werden bekanntlich verworfen).

    0
  • N

    Helium schrieb:

    Naja, wozu sollte man einen Wert einfach so mit 255 Multiplizieren, zumal die Algorithmen, die so im Internet zum Thema Hauterkennung rumfliegen alle für 0-1 ausgelegt sind (er will eine Hand "tracken").
    Kann doch keiner Ahnen, dass er die Bilder auch als pnm speichern will. Aber was ist das in dem Fall überhaupt für 'ne Frage. Wenn pnm ein bestimmtes Format vorgibt, muss man sich eben daran halten.

    Weiß schon was du meinst, hast ja auch vollkommen recht, nur ging das halt irgendwie schon aus seinem Postings heraus 😉

    Back @ Topic: Bist du dir eigentlich sicher, dass das tatsächlich Rot-Grün sein muss? Also ich hab da jetzt nicht so wirklich eine Ahnung von alledem, aber ich denke dir sagt YUV bestimmt auch was oder? Weil da hast du ja auch einen Luminanz-Anteil (also die Helligkeit) und einen Chrominanz-Anteil. Allerdings ist die Chrominanz letztendlich der Rot- und Blauanteil (also RB). Da kannst du glaub ähliche Sachen auch machen. Nur mal so als "Einwurf"...

    0
Anmelden zum Antworten