kepek rendezese szin szerint

Grafika: GUI, OpenGL

Sziasztok,

Egy actionscript projekten dolgozom amiben kepeket kellene rendeznem szin szerint.
Nem igazan van jo otletem a temaval kapcsolatban.
Szoval elindultam egy egyszeru uton.
Vegigmegyek a kepek pixelein, letrehozok egy szamot az rgb -bol a
0 - 255255255 -ig levo szam tartomanyban es elosztottam 64-el.
Gondoltam igy a hasonlo szinek ugyanabba a tartomanyba esnek majd.
Ezt a szamot eltaroltam minden kephez es e szerint rendeztem oket.
Mondanom se kell, de nem mukodik.

Tudna valaki segiteni, hogy megis milyen algoritmust hasznalhatnek a problema megoldasara?

Elore is koszi

  • 4643 megtekintés

( uid_2516 | 2010. 01. 11., h – 11:51 )

imagemagick, convert, histogram 


rka@atom:~$ convert 8994218.jpg -format %c histogram:info:- |\
> sort -rn | head -n 10 
      1602: (176,186,198) #B0BAC6 rgb(176,186,198)
      1380: (177,187,199) #B1BBC7 rgb(177,187,199)
      1369: (175,185,197) #AFB9C5 rgb(175,185,197)
      1180: (181,189,200) #B5BDC8 rgb(181,189,200)
      1162: (255,255,255) #FFFFFF white
      1157: (178,188,200) #B2BCC8 rgb(178,188,200)
      1093: (182,190,201) #B6BEC9 rgb(182,190,201)
      1027: (183,191,202) #B7BFCA rgb(183,191,202)
      1023: (180,188,199) #B4BCC7 rgb(180,188,199)
       968: (  0,  0,  0) #000000 black

Az R,G,B értékeken valamilyen statisztikát számolsz (pl. összegzed) és/vagy vektorként értelmezed.

( bri | 2010. 01. 11., h – 11:27 )

szerintem nem indultál el rossz úton, viszont ez az "átlaghoz közelítős" dolog nem szín, hanem kontraszt alapján fogja szortírozni a képeket. ha konkrétan a színek szerint rendeznél, akkor szerintem az rgb-ből téged az r:g, r:b és g:b arányok érdekelnek. definiálsz egy osztályfelbontást, aztán lehet finomítani az osztályhatárokon és az osztályok számán.

szerk.: a szórás miatt ráadásul nem is kell pixelenként vizsgálni. az adott kép összes pixelének összes r, g és b komponensének értékét rendre összeadod, és ezek arányait figyeled.

Ilyesmire gondoltam én is. Konkrétan: az adott kép összes pixelének összes r, g és b komponensének értékét rendre összeadod, így lesz a végén három darab számod, ami a képet jellemzi. Ezeket felfoghatod egy három dimenziós vektor komponenseinek.

Innen adódik, hogy két kép hasonlóságát lehet mérni a hozzájuk tartozó vektorok szögével (normálás után a skalárszorzatuk megadja a szög koszinuszát).

Ha pedig rendezni akarod őket, akkor definiálni kell egy normafüggvényt és aszerint rendezni. Ilyen normafüggvény lehet pl. az, ami a HSV színtér H (hue) komponensét számolja az RGB komponensekből.

Nem teljesen mindegy, az mindegy, hogy a problémát milyen nyelven implementálja. Már két szín között is eléggé sokféle távolságdefiníciót lehet használni (mint ahogy két n-dimenziós vektor távolságán is sokféle dolgot lehet érteni), és akkor itt nem csak két színnek, hanem két képnek a színtávolságát kellene valamilyen metrika szerint kiszámolni, lehetőleg úgy, hogy a felhasználói észlelés is jó legyen.

( PajzsMan | 2010. 01. 11., h – 16:30 )

Igaz, valami egyszeru kellene nekem.
Actionscript nem igazan szereti a szamitasigenyes muveleteket, foleg ha azok szimultan tobb osztalyban tortennek egyszerre.
Nem kell kicsinyiteni, mar kb. 120x80 -as thumbnail-ekkel dolgozom.

Ott tartok, hogy kiszamoltam a r:g r:b g:b aranyokat.

Utana neztem mi az a Hue / merthogy tenyleg felet se tudom a szakszavaknak amiket hasznaltatok :-( / es valami ilyen szerint szertnek en rendezni.

Na, most mar csak az a kerdesem, hogy a kiszamolt aranyokbol hogyan szamolhatom ki a Hue szoget?

Ezt megtalaltam mar ;-)
De ha ezt hasznalom akkor ki kellene szamolni minden pixelhez, nem?
Ha egyszerre beolvasok 500 thumbnailt akkor lefagy a flash player.
Nekem tetszik az a modszer amikor az aranyokat szamolom ki.
/ gyorsabbnak tunik /

Csak azt nem tudom, hogy innen hogyan mehetnek tovabb ...

- R,G,B kiszámítása: összeadod a pixelek r,g,b értékeit (tehát jó nagy egész számok lesznek)
- ha R,G,B mind egyenlő*, akkor szürke
- egyébként a táblázat megfelelő sorába behelyettesíted
- ahogy tetszik, a hue skálát diszkrét intervallumokra felosztod és nevet adsz nekik, hogy pl csak a sárgákat keresed

ps:
- *:pontosabban a max(R,G,B)-min(R,G,B) elég pici (hasraütéssel)
- ha van türelmed próbáld ki amit írtam, az összes pixelre kiszámolod a hue-t aztán sorba rendezed és a középső elem lesz a végső érték, fent ebbe ugyan joggal kötöttek bele, de annyira nem rossz eredményt ad várhatóan "normális" képekre

Koszi, megprobalom.
Mar csak egy kerdes:
"az összes pixelre kiszámolod a hue-t aztán sorba rendezed és a középső elem lesz a végső érték"

Miert a kozepso elem lesz a vegso ertek?
Azt gondoltam volna, hogy a legtobbet elofordulo hue ertek vagy a legtobbet elofordulo diszkret intervallum id-ja.

egy képről megmondani milyen színű elég nehéz, hisz nem nehéz olyat találni amiről az egyik ember azt mondja hogy kép a másik meg hogy fehér, a mediános ez egyfajta megközelítés, azért találod furának mert amit rá akarsz erőltetni az valójában az első, másképpen megfogalmazva, a mediannank az a lényege hogy ha egy kép mondjuk tényleg piros, mert egy nagy piros virág van a közepén, akkor a többi szín ha sok is van belőlük összesen, sorba rendezésnél jó eséllyel esik a "leggyakoribb" középre

Szeretnem megkoszonni mindenkinek a segitseget.
Sikerult kontraszt es a hue szin skala szerint rendeznem a kepeket.
Teszt kepekkel szepen mukodik minden.
Igazi felveteleknel tenyleg mindenki mas szint tart dominansnak egy kepen, szoval azokkal mar nem annyira latvanyos.
Majd a fonokseg eldonti hogy mennyire hasznalhato ez a funkcio.