RGB -> HSV, HSV -> RGB verlustfrei umrechnen

[Meier (Gast)]

Hallo,

gibt es eine Möglichkeit, bei der Rundungsfehler am besten nicht ins 
Gewicht fallen. Die Werte können wenn nötig auch im 16Bit vorliegen.

Wichtig wäre mir, das ich mir keine doofen Rundungsfehler einschleuse 
bei der Berechnung von Sättigung und Helligkeit.

[W.A. (Gast)]

Meier schrieb:
> gibt es eine Möglichkeit, bei der Rundungsfehler am besten nicht ins
> Gewicht fallen.

Das kommt auf deinen Maßstab drauf an. Probiers mal mit 
Festkommaarithmetik.

[Georg (Gast)]

Meier schrieb:
> Wichtig wäre mir, das ich mir keine doofen Rundungsfehler einschleuse

Das ist mathematisch nicht möglich. Wenn du eine Festkommazahl mit 
Multiplikation/Division in eine andere Festkommazahl umrechnest und das 
Ganze zurück, kann nicht garantiert werden, dass die ursprüngliche Zahl 
herauskommt. Besonders wenn der Wertebereich nur 0..255 ist.

Du müsstest deine Farbwerte immer als Gleitkommazahl führen (HDR) und 
nur bei der Ausgabe an entsprechende Geräte in RGB usw. umrechnen.

Georg

[Karl H. (kbuchegg)]

W.A. schrieb:
> Meier schrieb:
>> gibt es eine Möglichkeit, bei der Rundungsfehler am besten nicht ins
>> Gewicht fallen.
>
> Das kommt auf deinen Maßstab drauf an.

Hätte ich jetzt auch gesagt.
Wenn man die RGB Werte im Zahlenraum 0 bis 255 als ganze Zahl benutzt 
und auch für HSV entsprechende Zahlenrräume benutzt (H 0 bis 360, S und 
V 0 bis 255) dann ist es relativ simpel eventuelle float 
Kummulierungsfehler durch eine Rundungskorrektur vor dem Niedercasten 
auf int loszuwerden. Einfach 0.5 addieren.

Ansonsten:
so gross sind die Wertebereiche dann auch wieder nicht, dass man den AVR 
mal ein paar Minuten damit beschäftigen kann, alle möglichen 
Kombinationen von RGB nach HSV und wieder zurück wandeln zu lassen und 
mit den Ausgangswerten zu vergleichen. Dann hat man die Gewähr, dass das 
für alle vorkommenden Kombinationen auch tatsächlich einwandfrei 
funktioniert, weil man es ja getestet hat

   for( R = 0; R < 255; R++ ) {
     for( G = 0; G < 255; G++ ) {
       for( B = 0; B < 255; B++ ) {

         rgbToHsv( R, G, B, H, S, V );
         hsvToRgb( H, S, V, R1, G1, B1 );

         if( R != R1 || G != G1 || B != B1 ) {

           Fehler! Auf LCD anzeigen, LED aufleuchten lassen
           Sirene einschalten, per UART die RGB Werte ausgeben lassen,
           die NSA benachrichtigen, auf Facebook und Twitter posten (ach
           nee, die NSA hatten wir ja schon), ....
         }
       }
     }
   }

   "alles ok" ausgeben

das mag vielleicht ein wenig dauern, aber so ein Computer hat ja Zeit. 
Überhaupt in der Nacht, während du schläfst.

[Wolfgang (Gast)]

Georg schrieb:
> Du müsstest deine Farbwerte immer als Gleitkommazahl führen (HDR) und
> nur bei der Ausgabe an entsprechende Geräte in RGB usw. umrechnen.

Gleitkommazahlen braucht man, wenn man einen großen Dynamikbereich 
abdecken muss oder zu faul ist, den Wertebereich der in der Rechnung 
auftretenden Zahlen vorher mal abzuschätzen. Wenn man nicht gerade eine 
FPU auf dem µC hat, ist hier auch aus Performancegründen 
Festkommaarithmetik deutlich geeigneter. Das was einem bei einer 
Gleitkommazahl für den Exponenten an Bits verloren geht, hat man bei 
gleicher Genauigkeit bei Verwendung von Festkommazahlen als zusätzlichen 
Dynamikbereich.