[java] ARGB kleur vergelijken

[IceM]

Hallo,

Ik ben bezig met een applicatie waarin ik afbeeldingen die uit maximaal 256 ARGB kleuren bestaan moet reduceren tot afbeeldingen met 4 ARGB kleuren. Het opvragen van de huidige pixel kleur is niet zo moeilijk, en ik weet dus van elke pixel de kleurcodes (bijv: argb: 93, 16, 16, 16). De uiteindelijke 4 kleuren ken ik ook en het kleuren palette bestaat (vaak) uit 1 volledig transparante kleur, 1 donkere kleur (~zwart), 1 lichte kleur (~wit) en 1 kleur die tussen de lichte en donkere kleur in zit (~grijs). Van deze kleuren heb ik ook de ARGB kleuren.

Nu is mijn vraag: hoe bepaal ik de kleurwaarde die het dichtst bij de originele kleur zit? (dus: moet de huidige pixel transparant, zwart, grijs of wit worden)

Ik ben al een halve dag aan het zoeken maar ik kan hier eigenlijk geen bruikbare informatie voor vinden en het moet toch niet zo heel moeilijk zijn lijkt me?

[Sebazzz]

Ik zou beginnen de pixel te 'converteren' naar grijswaardes - zie Google - en daarna, omdat je dan een RGB waarde met R=G=B hebt kan bepalen welke het dichtst bij zit. De alpha waarde vergelijk je apart.

[DaCoTa]

Zorg dat je met HSV kleuren werkt, daarmee kun je veel eenvoudiger een distance measure maken.

[IceM]

Sebazzz schreef op donderdag 05 februari 2009 @ 15:14:
Ik zou beginnen de pixel te 'converteren' naar grijswaardes - zie Google - en daarna, omdat je dan een RGB waarde met R=G=B hebt kan bepalen welke het dichtst bij zit. De alpha waarde vergelijk je apart.

Hm, het noemen van zwart, grijs en wit was niet zo handig misschien. Wit hoeft niet altijd wit te zijn maar kan ook geel zijn, vandaar ook dat ik donker en licht heb genoemd. Het is dus geen afbeelding met enkel grijswaarden.

Het omzetten van RGB naar een HSB representatie kan met Color.RGBtoHSB, ik zal eens kijken hoe ik daar een "distance" mee kan bepalen. Het bepalen of een pixel transparant moet zijn heb ik gedaan door te kijken of de transparantie waarde groter is als 128 wat redelijk goed lijkt te werken.

[.oisyn]

Gewoon de RGB space als een 3d ruimte zien, met individuele kleuren als punten in die ruimte, en dan simpelweg afstanden berekenen.

[Sebazzz]

.oisyn schreef op donderdag 05 februari 2009 @ 15:56:
Gewoon de RGB space als een 3d ruimte zien, met individuele kleuren als punten in die ruimte, en dan simpelweg afstanden berekenen.

En de alpha is de vierde dimensie, tijd Alpha kan je natuurlijk achteraf berekenen en vergelijken ja.

[MSalters]

IceM schreef op donderdag 05 februari 2009 @ 15:40:
[...]
Hm, het noemen van zwart, grijs en wit was niet zo handig misschien. Wit hoeft niet altijd wit te zijn maar kan ook geel zijn, vandaar ook dat ik donker en licht heb genoemd. Het is dus geen afbeelding met enkel grijswaarden.

Dat maakt niet uit - zwart-wit is je enige variatierichting. Lichtgroen wordt nooit naar donkergroen geconverteerd, maar altijd naar lichtblauw. Je berekent dus de gemiddelde waarde van RGB, en vergelijkt dat met de RGB-gemiddelden van je 3 paletkleuren.

[Zoijar]

(error diffusion) dithering?

Ik weet niet wat je van plan was, maar als je simpelweg voor elke pixel bepaalt welke kleur uit je 4-kleuren palet er het dichtste bij zit (dichtbij hoe? in rgb vector space? in lightness? in perceptie?) en die dan daarmee vervangt, dan resulteert dat in een verschrikkelijk slecht plaatje. Floyd-steinberg dithering helpt hier al goed tegen; als je wat geavanceerders wilt doen kan je naar scolorq kijken.

scolorq maakt bv van dit:



dit 4-kleuren plaatje:



met een simpele replace van kleuren die het dichtsbij zijn krijg je een soort harde edges overal en solide vlakken.

[ Voor 106% gewijzigd door Zoijar op 05-02-2009 19:33 ]