Hallo,
in der Color.pm scheint sich noch ein Fehler eingeschlichen zu sein.
v sollte float(0-1) sein, ist aber int(0-255)
So sollte es zu lösen sein:
sub
rgb2hsv($$$) {
....
$v = $M;
$v = $M / 255;
....
}
danke.
hab es repariert.
gruss
andre
ich habe die änderung gerade zurück gerollt.
der wert ist ohne durch 255 zu teilen schon im bereich 0..1.
wie genau verwendest du rgb2hsv? die übergebenen rgb werte müssen im bereich 0..1 sein.
gruss
andre
Hallo Andre,
ich verwende die Funktion mit Werten 0-255 so wie es auch in der Beschreibung der Funktion vor deiner Änderung stand. Alle anderen Funktionen verlangen ja weiterhin 0-255.
In der Funktion rgb2hsb werden auch für Hue 0-65535 und Saturation 0-255 verwendet und in rgb2hsv 0-1. Wieso werden die Funktionen nicht zu einander kompatibel gehalten?
Gruß
Jurij
die beschreibung von rgb2hsv war falsch und die funktion wird schon an diversen stellen mit dem wertebereich 0..1 verwendet.
rgb2hsv und hsv2rgb verwenden werte im bereich 0..1
hsb2rgb und rgb2hsb verwenden werte im bereich 0..255 bzw. 65535.
hex2hsv verwendet 0..255 und hsv2hex 0..1
das ganze hat historische gründe und liegt daran das die routinen aus unterschiedlichen modulen gekommen sind.
die ct routinen kommen mit kelvin und mired zurecht und konvertieren automatisch. die rgb und hsv routinen könnten eventuell automatisch merken ob es 0..1 oder 0..255 ist. ich weiss nicht ob das potentiell an einer anderen stelle probleme machen könnte.
bis dahin teil bitte einfach vor dem aufruf durch 255.
gruss
andre
Hab das hier gerade erst gesehen...
Du hast also einen falschen Bugfix gebastelt, der dann bei Milight zu Fehlern geführt hat die mich zu einem falschen Bugfix verleitet haben und anschliessend haben wir die Änderungen wieder zurückgerollt?
lol :)
so in etwa :)
Hey, das bedeutet dann immerhin dass sich den Bug niemand eingebildet hatte, auch wenn ich ihn nicht (mehr?) reproduzieren konnte. :)
es ging ja für manche farben gut. und mit der automatischen umrechnung dann sogar für die meisten.