VB.NET Gezichten herkennen in JPG*

[bluesbrother]

Beste Tweakers,
Ik ben een heel simpel programmaatje aan het maken voor een afdeling die door 14000 studentenfoto's voor pasjes moet harken en daar de slechte uit moet halen. Dwz de fotos waar geen studenten opstaan maar alleen de achtergrond. Word vaak als testfoto gebruikt om te kijken of de camera goed geinstalleerd staat. Maar deze komt in de grote berg van goede foto's terrecht.
Dit is niet organisitorich of technisch anders op te lossen.

Ik wil nu een app maken die van elke foto kijkt hoeveel kleuren deze heeft, aangezien ik al met de hand gezien heb dat hierop gefilterd kan worden.

Ik zoek dus in VB.NET waar ik dat mee kan doen. Ik heb de GDI+ class uit zitten pluizen, system.drawing, en de namespaces die daaronder vallen. Ik ben van alles tegen gekomen, over brushes, en pen's enz. Maar niet wat ik zoek.

Ik heb ook Ik heb ook gegooled, en kom alleen iets tegen dat voor VB6 geschikt is.
Wel allerlei andere code die van alles doet met plaatjes, maar niet wat ik zoek.

Kan iemand mij in de juiste richting duwen? Ik ben even uitgezocht.

[beany]

Laad een plaatje in, converteer het naar BMP(gebruik de bmp class) en bekijk de afzonderlijke pixels. Defineer de kleur range van de achtergrond en ga kijken welk percentage van de foto deze kleur range bevat.

[Niemand_Anders]

Via de System.Drawing.Bitmap class kun je via GetPixel de kleur (Color) terug krijgen. Elke unieke kleur plaats je vervolgens in een List. Als je alle pixels van de image hebt doorlopen, is een count van de list voldoende om het aantal kleuren te achterhalen.

Of deze methode handig is betwijfel is. Vergroot met een grafisch programma maar eens een foto flink (zodat je duidelijk de pixels kunt zien. Je zult dan zien dat een foto met een rode achtergrond met gemak 200 verschillende kleuren rood heeft.

De System.Drawing namespace is een management toegang tot de GDI+. Misschien is het verstandig dat je ook in de MSDN wat artikels leest over de System.Drawing classes en hoe je ze moet gebruiken. Zoeken heeft alleen zin als je weet wat je zoekt..

[beany]

Niemand_Anders schreef op woensdag 04 juni 2008 @ 10:24:
Of deze methode handig is betwijfel is. Vergroot met een grafisch programma maar eens een foto flink (zodat je duidelijk de pixels kunt zien. Je zult dan zien dat een foto met een rode achtergrond met gemak 200 verschillende kleuren rood heeft.

Daarom gaf ik ook aan dat je een kleur range moet defineren

[bluesbrother]

oef....... het gaat om soms 15000 leerlingen foto's, dus als per foto de pixels bekeken en geteld moeten worden dan denk ik dat het 2 dagen duurt voor hij klaar is.
Dat is niet echt werkbaar.
In Paint Shop Pro kan ik bij informatie gewoon gelijk zien hoeveel kleuren erin zitten.
Ik heb ook gezocht of in de metadata van een JPG dit soort informatie staat, maar tot op heden niet kunnen vinden.

Ik voel aan mijn water dat er toch een makkelijker en minder omslachtige manier moet zijn....
Maar misschien is mijn water niet goed.........

[TeeDee]

Pixel voor Pixel uitlezen van een 640x480 (oid) afbeelding gaat vrij snel hoor. Je bent echt niet 2 dagen bezig om het e.e.a. uit te lezen.

Verder (en dan wil ik niet flamen) wil ik je nog wijzen op een quote van House (de NL versie):

Ja, ja.... denken is makkelijk dan zeker weten!

Ik kwam trouwens nog dit tegen. Ziet er veelbelovend uit.
Vrij traag (en ja, dat is een understatement.) Maar alsnog veelbelovend en interessant.

[ Voor 27% gewijzigd door TeeDee op 04-06-2008 10:56 ]

[beany]

Hoe groot zijn de foto's dan? Als elke foto 15MB is, ja... dan duurt het wel even. Maar als een foto 1MB is dan gaat het vrij snel hoor.

Zorg dat je algoritme een beetje goed in elkaar zit.

En vergeet niet dat het met de hand bekijken en beoordelen altijd langzamer is

[bluesbrother]

De grootste is 35 KB.
en 432 x 576 pixels. = 248.832 pixels.
Dus dan ga ik aan de gang, maar als jullie nog een inval hebben dan houdt ik mee aanbevolen.

[ Voor 55% gewijzigd door bluesbrother op 04-06-2008 11:25 ]

[TeeDee]

bluesbrother schreef op woensdag 04 juni 2008 @ 11:21:
De grootste is 35 KB.
Dus dan ga ik aan de gang

Peanuts dus Hou je wel rekening met de opmerking van Niemand_Anders? Het zal bij benadering zijn, dus bij twijfel, verplaatst, flag of wat dan ook de afbeelding voor handmatige controle.

[beany]

Misschien is dit wat: http://www.codeproject.co...Image_Processing_Lab.aspx

En dan vooral de Histogram ?? (download de demo, menu item View -> Histogram).

Source code is beschikbaar op dezelfde pagina, inclusief een hoop uitleg over plaatjes e.d.

[Janoz]

bluesbrother schreef op woensdag 04 juni 2008 @ 10:35:
In Paint Shop Pro kan ik bij informatie gewoon gelijk zien hoeveel kleuren erin zitten.

En hoe dacht je dat Paint Shop Pro dit doet?

[Ghannes]

beany schreef op woensdag 04 juni 2008 @ 11:30:
Misschien is dit wat: http://www.codeproject.co...Image_Processing_Lab.aspx

En dan vooral de Histogram ?? (download de demo, menu item View -> Histogram).

Source code is beschikbaar op dezelfde pagina, inclusief een hoop uitleg over plaatjes e.d.

dat programma is goed, maar weet neit of het handig is voor het doel van TS.

Kijk eens naar de openCV library. Zijn veel voorbeelden van face-detection

[.oisyn]

Janoz schreef op woensdag 04 juni 2008 @ 11:32:
[...]

En hoe dacht je dat Paint Shop Pro dit doet?

Iig niet door ze in een List (een array dus) te zetten, zoals Niemand_Anders suggereert

[ Voor 5% gewijzigd door .oisyn op 04-06-2008 11:59 ]

[Janoz]

Ligt eraan hoe je de opmerking interpreteert. Als hij met de list/array een histogram bedoeld dan lijkt het me niet meer dan logisch.

[Verwijderd]

Als je bang bent dat het 2 dagen duurt, misschien wat dingen paralliseren, i.e. multithreaden?

[? ?]

..

[ Voor 121% gewijzigd door ? ? op 25-01-2013 09:51 ]

[.oisyn]

Janoz schreef op woensdag 04 juni 2008 @ 12:15:
Ligt eraan hoe je de opmerking interpreteert. Als hij met de list/array een histogram bedoeld dan lijkt het me niet meer dan logisch.

Ik snap niet hoe je het volgende:

Niemand_Anders schreef op woensdag 04 juni 2008 @ 10:24:
Via de System.Drawing.Bitmap class kun je via GetPixel de kleur (Color) terug krijgen. Elke unieke kleur plaats je vervolgens in een List. Als je alle pixels van de image hebt doorlopen, is een count van de list voldoende om het aantal kleuren te achterhalen.

Als histogram kunt interpreteren eigenlijk . Niet dat het zo per se langzaam is overigens. Inoptimaal, dat wel (namelijk O(n*k), met n het aantal pixels en k het aantal unieke kleuren). Maar m'n punt was hoe paint shop pro het deed, en die gebruiken ongetwijfeld een slimmer algoritme om unieke kleuren te tellen

[ Voor 16% gewijzigd door .oisyn op 04-06-2008 12:58 ]

[Janoz]

Alleen de 'count' is wat vreemd, maar met 'Elke unieke kleur plaats je vervolgens in een List' word al lichtelijk naar een histogram gehint. Het rijmt iig niet met het omzetten naar een volledige array gezien het woordtje 'uniek'. Sowieso is zijn omschrijving in strijd met zichzelf, voor het interpreteren is het alleen van belang welk deel je daarvan weglaat

[RemcoDelft]

beany schreef op woensdag 04 juni 2008 @ 10:08:
Laad een plaatje in, converteer het naar BMP(gebruik de bmp class) en bekijk de afzonderlijke pixels. Defineer de kleur range van de achtergrond en ga kijken welk percentage van de foto deze kleur range bevat.

Dit heb ik ooit gedaan (in een Bash shell script!) om dubbele foto's te vinden: gewoon BMP maken, in mijn geval deed ik zelfs eerst een resize om ook dubbelen van verschillende afmetingen te pakken, en daarna de hex-code per kleur "optellen". Zit die onder de 3 (op een schaal tot 255) per pixel: dan is de achtergrond zwart.

[Woy]

Voor de TS is het mischien een Idee om diagonaal door elk plaatje heen te lopen en dan kijken op grote contrasten. Als een plaatje hierdoor positief gemarkeerd word kan je eventueel nog een volledige controle doen.

Op een plaatje van alleen een effen achtergrond zal je niet zo'n hoog contrast hebben. Omdat op een pasfoto de persoon altijd redelijk in het midden staat is het natuurlijk niet nodig om de complete foto te doorlopen.

[Zoijar]

Anders post je even een voorbeeld van de typische plaatjes. Image processing gebruik je het lieftst de meest simpele en robuste manier; face-detetction zou ik niet aan beginnen, dan zit er ineens weer een nigeriaan met een zonnebril en een petje bij die niet herkend wordt

(diagonaal van rwb klinkt wel goed. Soort 1D edge-detector)

[ Voor 10% gewijzigd door Zoijar op 04-06-2008 13:53 ]

[Verwijderd]

Van alle foto's moet toch al bekend zijn wie er op staat? Anders kun je alles later nog opzoeken, lijkt me niet. Indien dit zo is kun je toch gewoon alle foto's pakken die niet aan een persoon gebonden zijn, of anders alle personen waar meer dan 1 foto van is (of komt dat vaker voor dan alleen bij die testshots?). Al lijkt me dat je met 3 mensen in een paar uurtjes alle lege foto's eruit hebt gevist als je gewoon thumbnail weergave pakt, het menselijk oog herkent dit soort dingen een stuk makkelijker dan een computer! Denk dat je ondertussen al meer tijd aan het zoeken bent naar een oplossing dan dat je het manueel had kunnen doen

[pkuppens]

Nu ik de ideeen hierboven gelezen heb zou ik het wel ongeveer weten.
JPG converteren naar een gray-scale (7 of 8 bit) BMP.
Een goed plaatje blijft 'overeind' in grijs, en je ben van al die rare schakeringen af.
Echt contrast/edge detection is JPG niet goed in, het BMP resultaat daarvan ook niet.
Ik verwacht wel dat een plaatje duidelijk is al zeg 20% minstens 75% donker en 20% minstens 75% licht is.
Een slecht plaatje zal 80% licht of 80% donker zijn, of 80% ergens er tussenin.
Is makkelijker tellen dan een heel histogram?
Een beetje tweaken aan die getallen zal nodig zijn. Kan aan de hand van een test set van 7 goede en 3 slechte plaatjes.
Een twijfelgevallen-set aanmaken voor niet expliciet goede of expliciet foute plaatjes is ter overweging.

[Niemand_Anders]

.oisyn schreef op woensdag 04 juni 2008 @ 12:50:
Als histogram kunt interpreteren eigenlijk . Niet dat het zo per se langzaam is overigens. Inoptimaal, dat wel (namelijk O(n*k), met n het aantal pixels en k het aantal unieke kleuren). Maar m'n punt was hoe paint shop pro het deed, en die gebruiken ongetwijfeld een slimmer algoritme om unieke kleuren te tellen

Ik heb vrijwel geen verstand van grafische analyses, maar op basis van de vraag van de TS (aantal kleuren in een plaatje), was dit het eerste wat in mij opkwam.

PSP zal een soortgelijke manier gebruiken, alleen dan over meerdere threads. Omdat List een lineare search uitvoert (Contains) is met Dictionary<Color, object> een optimalisatie mogelijk, waarbij alleen de ContainsKey methode wordt gebruikt. De value van elke entry kan gewoon op null gehouden worden. Via ReaderWriterLockSlim kunnen meerdere threads gebruik maken van de dictionary en via de Semaphore class is het aantal gelijktijdige threads goed in de hand te houden.

Wat betreft de histogram: werken histogrammen niet door een afbeelding naar grijstinten om te zetten en dan van die 256 grijstinten de intensiteit te tonen?

[Woy]

pkuppens schreef op woensdag 04 juni 2008 @ 14:37:
Echt contrast/edge detection is JPG niet goed in, het BMP resultaat daarvan ook niet.

Hoezo niet? Je leest een JPG gewoon in waarna je gewoon een in memory representatie hebt ( Het storage formaat is voor de rest niet van belang ) van een image. Het omzetten van de complete image is ook niet nodig, in je edge detection algoritme kan je de daadwerkelijke kleur altijd nog mappen op grijswaarden.

[ Voor 5% gewijzigd door Woy op 04-06-2008 14:50 ]

[Verwijderd]

Ik neem aan dat de achtergrond redelijk vast is, en dat de studenten zoveel mogelijk in het midden op de foto staan?

Dan pak je een groot stuk uit midden van de foto, maak een histogram en vergelijk de waardes met ene waarvan je zeker bent dat er alleeen een achtergrond opstaat.

Waarschijnlijk wil je voor het maken van de histogram het aantal kleuren gaan beperken om makkelijker te vergelijken.

(dit principe wordt gebruikt door diverse sites om te kijken of op andere sites iets door een foto geplaatst wordt, hint: schuine streep met tekst "verkocht").

[ Voor 16% gewijzigd door Verwijderd op 04-06-2008 14:53 ]

[.oisyn]

Niemand_Anders schreef op woensdag 04 juni 2008 @ 14:43:
[...]

Ik heb vrijwel geen verstand van grafische analyses, maar op basis van de vraag van de TS (aantal kleuren in een plaatje), was dit het eerste wat in mij opkwam.

PSP zal een soortgelijke manier gebruiken, alleen dan over meerdere threads. Omdat List een lineare search uitvoert (Contains)

Exact. Threads zijn niet interessant, dat is een implementatiedetail. De algoritmiek is wat hier belangrijk is. De lineaire search van de list wordt een ramp bij heel veel unieke kleuren. Als elke pixel een unieke kleur heeft is het algoritme O(n²), terwijl bij een hashtable (die als ik het goed begrijp ook wordt gebruikt bij een Dictionary) dat (amortized) O(n) is.

Wat betreft de histogram: werken histogrammen niet door een afbeelding naar grijstinten om te zetten en dan van die 256 grijstinten de intensiteit te tonen?

Een histogram is een diagram van de frequentieanalyse van de data, oftewel een staafdiagram dat voor elke categorie (bijv. elke grijstint is een eigen categorie) aangeeft hoe vaak die categorie in de data voorkomt.

rwb schreef op woensdag 04 juni 2008 @ 14:47:
[...]

Hoezo niet? Je leest een JPG gewoon in waarna je gewoon een in memory representatie hebt ( Het storage formaat is voor de rest niet van belang ) van een image. Het omzetten van de complete image is ook niet nodig, in je edge detection algoritme kan je de daadwerkelijke kleur altijd nog mappen op grijswaarden.

Waar pkuppens volgens mij op doelt is dat JPG juist niet geschikt is om hoogfrequente verschillen in contrast mee te encoderen, en dat contrast dus verloren gaat. Het omzetten naar BMP brengt dat contrast logischerwijs niet ineens terug. Overigens ben ik het niet met 'm eens, een kernel van 2 pixels is wellicht idd niet geschikt maar ik kan uit jouw originele post niet opmaken dat je dat idd ook bedoelde. Maar het is niet alsof je voor een foto geencodeerd met JPG - juist uitermate geschikt voor normale foto's - geen edge detection meer kunt toepassen

Met een simpele embossing filter met kernel
[0 1 0]
[1 0 -1]
[0 -1 0]
op de grijswaarden van de foto is imho al voldoende om een indicatie te geven van of er iemand op staat of niet (door bijvoorbeeld die kernel over elke pixel te gooien, daar de absolute waarde van nemen, en dat allemaal bij elkaar optellen). Een plaatje met niemand erop zal dicht bij 0 liggen, terwijl als er wel iemand op staat die waarde een stuk hoger zal liggen. Dan is het alleen nog een kwestie van die threshold tweaken: bereken de waarde voor een foto met niemand erop (a), doe het zelfde voor een foto waar wel iemand opstaat (b), en neem als threshold dan bijv. 0.75*a+0.25*b

[ Voor 13% gewijzigd door .oisyn op 04-06-2008 15:40 ]

[Zoijar]

.oisyn schreef op woensdag 04 juni 2008 @ 15:28:
Exact. Threads zijn niet interessant, dat is een implementatiedetail. De algoritmiek is wat hier belangrijk is. De lineaire search van de list wordt een ramp bij heel veel unieke kleuren. Als elke pixel een unieke kleur heeft is het algoritme O(n²), terwijl bij een hashtable (die als ik het goed begrijp ook wordt gebruikt bij een Dictionary) dat (amortized) O(n) is.

Ik neem aan dat photoshop gewoon een bucket per kleur per kanaal gebruikt, dan is zo'n hash table gewoon O(n) worst-case. Zelfs met 16bit image data heb je op die manier maar 4*4*64k = 1MB nodig.

oh, maar je wilde alle verschillende kleuren tellen, laat maar, dat kan dan niet.

[ Voor 6% gewijzigd door Zoijar op 04-06-2008 15:47 ]

[MrSleeves]

Een praktisch punt: met Image.GetThumbnailImage kan je een thumbnail ophalen uit de JPG (zit er vaak in gebakken), zo rond de 120x120. Dat zijn niet zoveel punten en in principe moet je uit een thumbnail al veel kunnen opmaken.

[ThunderNet]

Ik zou een histogram maken van alle plaatjes.
Daar een marge opzetten, en op die manier de juiste niet juisten eruit filteren

[bluesbrother]

Ik zie dat de meningen verdeeld zijn.
Ik heb hieronder wat voorbeelden neergezet.
Misschien dat jullie er wat mee kunnen.
Ik ben er na wat verdere research ook nog niet uit.
Ik zoek ook nog even verder aan de hand van jullie tips,
en dan komt ik er op terug.






Hieronder de foute exemplaren:




De fotos. zowel de verkeerde als de goede verschillen nogal, dus
het is dan moeilijk om te filteren. Hoewel ze qua bestandsgroote ook vaak afwijken is dat niet fullproof. Ik heb geen invloed op hoe de foto's aangeleverd worden.
En de mensen die de foto's maken (verschillende lokaties van onze school) denken ook niet altijd aan de persoon die de foto's moet uitzoeken. Ik moet het hiermee doen.
Ook op de namen van de fotos kan niet geselecteerd worden.
Tot nu toe doet iemand dat handmatig en daar willen we graag een oplossing voor bedenken.
Maar de boven en onderstaande discussie geeft wel aan dat het nog een lastige klus word.

Het is inderdaad moeilijk om iets vinden wat er uitziet dat zal gaan werken.

[ Voor 47% gewijzigd door bluesbrother op 05-06-2008 16:32 ]

[Janoz]

Misschien handig wanneer je ook een paar foto's van verkeerde foto's neerzet. Sowieso zie ik alvast 1 groot probleem. De achtergrond is niet constant. Een simpel kleuren tel algoritme gaat je probleem niet oplossen.

[Voutloos]

Janoz schreef op donderdag 05 juni 2008 @ 16:15:
Misschien handig wanneer je ook een paar foto's van verkeerde foto's neerzet.

Enkel een doek of bakstenen muurtje is niet zo moeilijk voor te stellen toch?

Sowieso zie ik alvast 1 groot probleem. De achtergrond is niet constant. Een simpel kleuren tel algoritme gaat je probleem niet oplossen.

Contrast is veel krachtiger voor het vinden van een onderwerp, maar dan kunnen zulke bakstenen muurtjes als achtergrond wel erg stom zijn. Als het op kleur moet zou ik per foto de linker- en rechtbovenhoekjes tot achtergond kleur bombarderen.

Als je op basis van een aantal punten een weging/score gaat berekenen, kan je zelfs ook het tijdstip meenemen. Bij de gemiddelde reeks foto's (opeenvolgende foto's binnen kort tijdsbestek) zal een testshot, indien aanwezig, doorgaans de 1e foto zijn, en als iemand vaker op de foto staat zal doorgaans de laatste de beste zijn, omdat er niet voor niets nogmaals een foto genomen wordt.

edit:
Nav. Bergen: filesize kan idd ook mee in de heuristiek.

Maar voorlopig zet ik in op een algortime puur basis van contrast.

[ Voor 28% gewijzigd door Voutloos op 05-06-2008 16:36 ]

[Janoz]

Sowieso is het bakstenen voorbeeldje al erg lastig. De bakstenen kleur lijkt heel erg op de huidskleur. Eigenlijk geld dat bijna voor alle foto's behalve de eerste.

Betere resultaten zijn waarschijnlijk te halen wanneer er meer met andere vormen van herkenning gewerkt wordt (edge detection bv. Vooral het haar zal flink uitslaan op gedifferentieerde versies van die foto's)

Ik vermoed echter dat dit toch een beetje de mogelijkheden van de topicstarter ontstijgd.

[Bergen]

Kun je ze niet gewoon sorteren op grootte? Foto's met een lege achtergrond zijn veel makkelijker in te pakken en daarom waarschijnlijk ook veel kleiner.

Je kunt ook kijken naar de hoeveelheid donkere kleuren. Een lege foto heeft voornamelijk veel lichte kleuren (weinig tot geen donkere kleuren tot zwart). Resize de foto eerst tot half of kwart van de grootte zoals je ze hier post om het proces te versnellen, begin daarna met pixels tellen die onder een bepaalde helderheid zitten. Zodra je qua aantal donkere pixels over een bepaalde threshold komt, markeer je die foto als ok.

Heeft VB.NET trouwens niet wat snellere mogelijkheden dan GetPixel? Is dat niet net zo traag als bijvoorbeeld Canvas.Pixels van Delphi? Kijk eens of je niet rechtstreeks de bitmaps kunt uitlezen, dan hoeft het ook geen 2 dagen te duren. Donkere pixels tellen hoeft per plaatje niet langer te duren dan een paar milliseconden. 14,000 foto's scannen hoeft dan ook niet langer dan een paar minuten te duren.

[ Voor 35% gewijzigd door Bergen op 05-06-2008 16:49 ]

[TeeDee]

Bergen schreef op donderdag 05 juni 2008 @ 16:29:
Heeft VB.NET trouwens niet wat snellere mogelijkheden dan GetPixel? Is dat niet net zo traag als bijvoorbeeld Canvas.Pixels van Delphi? Kijk eens of je niet rechtstreeks de bitmaps kunt uitlezen, dan hoeft het ook geen 2 dagen te duren.

offtopic:
Het schijnt dat LockBits sneller werkt. Zelf heb ik dat nog niet getest.

[Voutloos]

Janoz schreef op donderdag 05 juni 2008 @ 16:28:
Sowieso is het bakstenen voorbeeldje al erg lastig.

False positive? Goh, foto van persoon afgekeurd met verwijzing naar een regeltje dat een egale achtergrond vereist is.
[/bureaucratische oplossing]

TeeDee schreef op donderdag 05 juni 2008 @ 16:36:
[...]

offtopic:
Het schijnt dat LockBits sneller werkt. Zelf heb ik dat nog niet getest.

Micro optimalisaties tov het grote besparingswerk: Een paar lijnen langs de randen en een paar lijnen door het centrum berekenen zal toch wel voldoende mogen zijn. En wellicht is verdere optimalisatie dan niet meer noodzakelijk.

Sowieso moet het in eerste instantie om het eigenlijke algoritme gaan, subtiele optimalisaties kan je doen als je de bottleneck gemeten hebt (bottleneck bepalen en netjes profilen en kijken wat er gebeurt alvorens wat te gokken sluit ook aan op TeeDees topic )

[Woy]

Voutloos schreef op donderdag 05 juni 2008 @ 16:51:
Micro optimalisaties tov het grote besparingswerk: Een paar lijnen langs de randen en een paar lijnen door het centrum berekenen zal toch wel voldoende mogen zijn. En wellicht is verdere optimalisatie dan niet meer noodzakelijk.

Sowieso moet het in eerste instantie om het eigenlijke algoritme gaan, subtiele optimalisaties kan je doen als je de bottleneck gemeten hebt (bottleneck bepalen en netjes profilen en kijken wat er gebeurt alvorens wat te gokken sluit ook aan op TeeDees topic )

Op zich ben ik het met je eens, maar GetPixel is wel heel erg traag. Ik ben er ook wel eens mee bezig geweest en direct op de data werken was echt significant sneller.

[Bergen]

Even uit de losse pols (let niet op de ranzige code), dit stukje scant 14,000 foto's van bovenstaand formaat in een dikke 7 seconden op een Athlon64 3200.

[code=delphi]
procedure TForm1.Button1Click(Sender: TObject);
var
fn : String;
b: TBitmap;
c, t1, t2: Integer;
i: Integer;
begin
fn := 'C:\Documents and Settings\Gerben Wijnja\Bureaublad\foto2.bmp';
b := TBitmap.Create;
b.LoadFromFile(fn);
t1 := GetTickCount;
for i := 1 to 14000 do
c := CountDarkPixels(b, 32); // tel pixels met (r+g+b < 32)
t2 := GetTickCount;
showmessage(inttostr(t2 - t1)+ ' msec, '+inttostr(c)+' pixels');
end;

function TForm1.CountDarkPixels(const Bitmap: TBitmap; const Threshold: Integer): Integer;
var
x, y: Integer;
offset: Integer;
row: PByteArray;
total: Integer;
begin
Result := 0;
for y := 0 to Bitmap.Height - 1 do
begin
row := Bitmap.ScanLine[y];
offset := 0;
for x := 0 to Bitmap.Width - 1 do
begin
if row[offset] + row[offset + 1] + row[offset + 2] < Threshold then Inc(Result);
Inc(offset, 3);
end;
end;
end;[/code=delphi]Met dat aantal zou je weer naar een percentage kunnen kijken, etc. Anyway, als je code 2 dagen nodig heeft doe je iets heel erg fout.

[TeeDee]

Voutloos schreef op donderdag 05 juni 2008 @ 16:51:
Sowieso moet het in eerste instantie om het eigenlijke algoritme gaan, subtiele optimalisaties kan je doen als je de bottleneck gemeten hebt (bottleneck bepalen en netjes profilen en kijken wat er gebeurt alvorens wat te gokken sluit ook aan op TeeDees topic )

offtopic:
Zo jammer weer he.... , we wisten al waar het aan lag

[BtM909]

Bergen schreef op donderdag 05 juni 2008 @ 16:29:
Kun je ze niet gewoon sorteren op grootte? Foto's met een lege achtergrond zijn veel makkelijker in te pakken en daarom waarschijnlijk ook veel kleiner.

Ze zijn allemaal van verschillende grootte, dus dat kan in sommige gevallen lastig worden, maar dit is wel een hele simpele methode, aangezien er jpg's (dus compressed) worden gebruikt

[Verwijderd]

Hier hoe ik het zou doen.

1) Bereken de gemiddelde waarde van alle RGB waarden in de linker bovenhoek
2) Bereken de gemiddelde waarde van alle RGB waarden in het midden van het beeld (dus +- het gezicht)

3) Trek de 2 van elkaar af en neem absolute waarde
4) Verschil kleiner dan treshhold => niets op het plaatje

Ja, dit 14000x :-)

[.oisyn]

.oisyn schreef op woensdag 04 juni 2008 @ 15:28:
Met een simpele embossing filter met kernel
[0 1 0]
[1 0 -1]
[0 -1 0]
op de grijswaarden van de foto is imho al voldoende om een indicatie te geven van of er iemand op staat of niet (door bijvoorbeeld die kernel over elke pixel te gooien, daar de absolute waarde van nemen, en dat allemaal bij elkaar optellen). Een plaatje met niemand erop zal dicht bij 0 liggen, terwijl als er wel iemand op staat die waarde een stuk hoger zal liggen.

Heb dit even snel geïmplementeerd, en met die gegeven foto's kom ik op de volgende waarden:
782.038
1033.2
940.365
1003.33
136.748
154.037

De onderste twee zijn vrij laag, en dat zijn precies de foto's waar niemand op staat. Met een treshold van rond de 250 a 300 moet je een goede selectie kunnen maken . Hou er ook rekening mee dat de waarden bij de mensen op de foto lager zijn uitgevallen door de censuurvlakken in het plaatje - daarbinnen zit geen contrastverschil.

Het uitrekenen van deze waarden kost overigens 5.5 milliseconde (voor de 6 foto's bij elkaar), maar daar moet ik wel bijzeggen dat het al uncompressed greyscale plaatjes waren - het is dus puur de inlees- en filtertijd.

[ Voor 8% gewijzigd door .oisyn op 05-06-2008 17:46 ]

[Nick The Heazk]

Gegeven de foto's die de TS gepost heeft zou ik het als volgt proberen aan te pakken. Deel vooreerst het plaatje op in een aantal tegels. Voor elk van deze tegels berekent men de variantie in de kleur. Vervolgens berekent men de variantie van de variantie van elk van deze tegels. Indien deze variantie beneden een bepaalde waarde ligt, dan heeft men te maken met een achtergrond plaatje.

De variantie voor deze 3-dimensionale kleurvectoren zou ik definiëren als de gekwadrateerde norm van de variantie van de componenten:

code:

VAR( (r,g,b) ) = VAR(r)² + VAR(g)² + VAR(b)²

Voor achtergrond plaatjes zal de variantie van de verschillende tegels erg klein zijn. Merk op dat dit ook opgaat als de achtergrond een muur is. De variantie van elk van de tegels zal dan ongeveer gelijk zijn, en zodus is de variantie van die varianties klein.

Bij plaatjes met personen zal door de opdeling in tegels de variantie van deze tegels sterker variëren dan bij achtergrond plaatjes.

Misschien dat ik vanavond eens een proof-of-concept in elkaar flans.

Edit: De achterliggende idee komt overeen met wat .oisyn heeft bedacht; meet de verschillen in het plaatje op.

@.oisyn: Ik denk trouwens dat je je waarde best nog eens deelt door het aantal pixels; mijn inziens hangt je waarde af van het aantal pixels in het plaatje.

[ Voor 11% gewijzigd door Nick The Heazk op 05-06-2008 17:55 ]

[.oisyn]

Nick The Heazk schreef op donderdag 05 juni 2008 @ 17:51:
@.oisyn: Ik denk trouwens dat je je waarde best nog eens deelt door het aantal pixels

Klopt, ik doe momenteel 100 * waarde / ((breedte - 2) * (hoogte - 2)). Die 100 is natuurlijk redelijk arbitrair en kon ik net zo goed weglaten, maar ik vond de waarden zo "mooier"

Ik trek 2 van de breedte en hoogte af omdat ik het filter niet toepas op de pixels aan de rand zelf.

[? ?]

..

[ Voor 114% gewijzigd door ? ? op 25-01-2013 09:51 ]

[Bergen]

era.zer schreef op donderdag 05 juni 2008 @ 20:18:
Waarom reageer je (Bluesbrother) niet inhoudelijk op mijn post?

Omdat ze niet gelinkt zijn I guess. Anders zou hij dit topic ook niet aanmaken lijkt mij.

Ik vind de emboss-oplossing van .oisyn ook erg mooi moet ik zeggen! In plaats van de foto's eerst te grayscalen, zou je het filter overigens ook op het totaal van de RGB-waarden van elke pixel kunnen toepassen.

[.oisyn]

Bergen schreef op donderdag 05 juni 2008 @ 22:27:
Ik vind de emboss-oplossing van .oisyn ook erg mooi moet ik zeggen! In plaats van de foto's eerst te grayscalen, zou je het filter overigens ook op het totaal van de RGB-waarden van elke pixel kunnen toepassen.

Wat in feite hetzelfde is, alleen is elk resultaat dan 3x zo groot . De reden dat ik ze gegreyscaled had was overigens omdat ik even snel een proof of concept wilde implementeren in C++ zonder op te moeten gaan zoeken hoe ik een JPG in moest laden. Had de foto's dus even maar grayscale opgeslagen als raw formaat en de grootte van elke foto gehardcore in mijn programma

[Gomez12]

Ik zal dan wel een simpele ziel zijn hoor, maar ipv 2 dagen op een forum te overleggen daarna nog een stukje te gaan proggen, daarna nog de exacte randwaardes gaan bepalen en daarna nog wat te gaan testen zou ik gewoon in de verkenner alles als thumbnails tonen, student erachter zetten die de foute ertussen uithaalt en verplaatst naar een mapje.

Juist met dit soort foto's ( wel / niet leeg ) is het imho perfect met thumbnails te doen, passen er lekker veel op je scherm. Ik gok dat een beetje doorzetter hier 2 uur mee bezig is ( en daarna wel even compleet geen plaatje meer wil zien ).

Maarja, als dit elk jaar moet gebeuren kan het lonend zijn om hier een algoritme voor op te stellen...

[.oisyn]

Zie het als forumvulling .

[Bergen]

Waarom makkelijk doen als het moeilijk kan?

[? ?]

..

[ Voor 144% gewijzigd door ? ? op 25-01-2013 09:51 ]

[Gomez12]

era.zer schreef op donderdag 05 juni 2008 @ 23:34:
[...]
Maar nu is het gewoon idioot.

Ho, ho 2e forumvulling post gaat worden hoe er nu van een los naw-bestand en 14.000 losse plaatjes een compleet pasje gemaakt kan worden. Dan komen er weer tig posts met de meest fantastische software opzetjes hoe iemand met een burka op (90% gelijke kleur ) waarschijnlijk niet uit het oosten van het land kan komen, zit er in de burka een ajaxlogo verweven dan komt de persoon waarschijnlijk uit amsterdam, schijnt er een rood lichtje op de achtergrond dan is het waarschijnlijk de wallen.
NAW-gegeven bekijken hoeveel studenten er op de wallen wonen, is dit er 1 dan heb je of de goede foto bij de goede student gevonden of een grappige groninger die lollig dacht te zijn...

Heb je er meerdere dan kan je natuurlijk nog even alle foto's van hyves / facebook / flicker etc downloaden, hier een facial recognition programma op los laten die alle foto's daarvan vergelijkt met jouw foto...

Of je had in 1e instantie gewoon een administratie bij kunnen houden tijdens het foto's maken maar dan hadden we geen forumvulling gehad...

[TeeDee]

@Gomez12: dat stadium zijn we al voorbij (ik wel in ieder geval): het gaat nu om zo efficient mogelijk images c.q. gezichten te herkennen.

Laten we daar over discussieren, en niet over het feit of het nu wel of niet goed aangepakt is in het begin.

Dus, in navolging op jouw 'tig' posts een leuk forumvullinkje:

1 to change the light bulb and to post that the light bulb has been changed
14 to share similar experiences of changing light bulbs and how the light bulb could have been changed differently
7 to caution about the dangers of changing light bulbs
1 to move it to the Lighting section
2 to argue then move it to the Electricals section
7 to point out spelling/grammar errors in posts about changing light bulbs
5 to flame the spell checkers
3 to correct spelling/grammar flames
6 to argue over whether it's "lightbulb" or "light bulb" ... another 6 to condemn those 6 as stupid
2 industry professionals to inform the group that the proper term is "lamp"
15 know-it-alls who claim they were in the industry, and that "light bulb" is perfectly correct
19 to post that this forum is not about light bulbs and to please take this discussion to a lightbulb forum
11 to defend the posting to this forum saying that we all use light bulbs and therefore the posts are relevant to this forum
36 to debate which method of changing light bulbs is superior, where to buy the best light bulbs, what brand of light bulbs work best for this technique and what brands are faulty
7 to post URL's where one can see examples of different light bulbs
4 to post that the URL's were posted incorrectly and then post the corrected URL's
3 to post about links they found from the URL's that are relevant to this group which makes light bulbs relevant to this group
13 to link all posts to date, quote them in their entirety including all headers and signatures, and add "Me too"
5 to post to the group that they will no longer post because they cannot handle the light bulb controversy
4 to say "didn't we go through this already a short time ago?"
13 to say "do a Google search on light bulbs before posting questions about light bulbs"
1 forum lurker to respond to the original post 6 months from now and start it all over again.

[Gomez12]

TeeDee schreef op donderdag 05 juni 2008 @ 23:52:
@Gomez12: dat stadium zijn we al voorbij (ik wel in ieder geval): het gaat nu om zo efficient mogelijk images c.q. gezichten te herkennen.

Laten we daar over discussieren, en niet over het feit of het nu wel of niet goed aangepakt is in het begin.

Dan even een quote uit de originele TS :

Ik ben een heel simpel programmaatje aan het maken

Kijk de discussie die jij noemt vind ik op zich wel interessant.
Maar adhv jpg'jes vanuit cameraphones ( zo lijkt het voor mij ) dit willen doen is imho een vergeefse moeite, vanwege de missende kleurechtheid / kleurgelijkheid gaat imho elk algoritme wat je bedenkt al mank op een simpele foto van een teddybeer / een bloemenvaas.

Wordt de discussie professioneler ( vb altijd zelfde achtergrond / zelfde camera / ongeveer zelfde belichting ) dan wordt het interessant. Maar als we uit blijven gaan van de genoemde foto's dan blijft het wmb een excercitie in nutteloosheid en alleen een stukje forumvulling.

offtopic:
Ik vond jouw stukje forumvulling trouwens wel humor, dat dan weer wel

[Zoijar]

Als een leeg bakstenen muurtje ook kan, dan wordt het nog wel interessant... anders, draai er een edge detector over en klaar.

(het grappige is dat een face detector precies zoekt naar oa die zwarte balken die jij over die gezichten hebt gezet om ze onherkenbaar te maken)

[ Voor 37% gewijzigd door Zoijar op 06-06-2008 00:19 ]

[? ?]

..

[ Voor 100% gewijzigd door ? ? op 25-01-2013 09:51 ]

[Janoz]

Hebben we helemaal geen appart topic voor nodig. Ik zal alleen 'kleuren tellen' in de topictitel vervangen door 'gezichten herkennen' en we kunnen hier gewoon verder .

[Zoijar]

Ik heb een tooltje voor je gemaakt in C++ met opencv...

http://www.xs4all.nl/~smit/facedetect.zip

- Pak het ergens uit (vanaf nu \)
- Kopieer al je images naar de "\images" directory
- Draai \run.bat
- Alle niet-gezichten worden gemoved naar \images\noface, de rest blijft staan

[Pascal]

Zoijar schreef op vrijdag 06 juni 2008 @ 15:33:
Ik heb een tooltje voor je gemaakt in C++ met opencv...

http://www.xs4all.nl/~smit/facedetect.zip

- Pak het ergens uit (vanaf nu \)
- Kopieer al je images naar de "\images" directory
- Draai \run.bat
- Alle niet-gezichten worden gemoved naar \images\noface, de rest blijft staan

Als iemand een error krijgt met libguide40.dll -- > download http://www.dlldll.com/getdll/3035.html

[RobIII]

Zoijar schreef op vrijdag 06 juni 2008 @ 15:33:
Ik heb een tooltje voor je gemaakt in C++ met opencv...

http://www.xs4all.nl/~smit/facedetect.zip

- Pak het ergens uit (vanaf nu \)
- Kopieer al je images naar de "\images" directory
- Draai \run.bat
- Alle niet-gezichten worden gemoved naar \images\noface, de rest blijft staan

"Deze toepassing kan niet worden gestart omdat libguide40.dll niet kan worden gevonden..."
Daarbij is het nogal leentje-buur van (o.a.?) Intel. Ik had wat (eigen) source interessanter gevonden

[ Voor 4% gewijzigd door RobIII op 06-06-2008 15:40 ]

[Zoijar]

RobIII schreef op vrijdag 06 juni 2008 @ 15:39:
[...]

"Deze toepassing kan niet worden gestart omdat libguide40.dll niet kan worden gevonden..."
Daarbij is het nogal leentje-buur van (o.a.?) Intel. Ik had wat (eigen) source interessanter gevonden

Yep, ik merkte het ook net dat ik een dll ben vergeten.

Die andere zijn OpenCV dll's, opensource van intel idd. Zelf maken is leuk, maar kost je maanden. Als je tools nodig hebt, dan kan je beter gebruiken wat er is

[ Voor 11% gewijzigd door Zoijar op 06-06-2008 15:42 ]

[RobIII]

Zoijar schreef op vrijdag 06 juni 2008 @ 15:41:
[...]

Yep, ik merkte het ook net dat ik een dll ben vergeten.

Die andere zijn OpenCV dll's, opensource van intel idd. Zelf maken is leuk, maar kost je maanden. Als je tools nodig hebt, dan kan je beter gebruiken wat er is

Nou ja, was ook een beetje mijn eigen schuld...
Ik las:

Ik heb een tooltje voor je gemaakt in C++

...en was dus benieuwd. Had alleen even over

met opencv...

heen gelezen Ik vond daarom dat je nogal veel credit 'opeiste' door te zeggen dat je het had gemaakt terwijl je tegen 3rd party componenten aan zat te lullen. Maar again, dat was dus omdat ik het niet goed gezien had.

[Zoijar]

Oh ok, zo bedoelde ik het idd niet. Dit was quick en dirty, half uurtje werk idd.

Nb. heb de .zip file geupdate, zou nu moeten werken (libguide40.dll zit erbij, en de rest is statisch gelinked)

[Verwijderd]

Edit: tweede en derde pagina van de comments gemist. Dan doet mijn verhaal niet meer terzake

[ Voor 89% gewijzigd door Verwijderd op 06-06-2008 16:04 ]

[leuk_he]

Ik snap niet wat topic starter moet met een grote bak foto's als hij niet weet wat er op de foto staat (welke persoon). Ergens moet iemand toch weer aan de persoon gegevens vastknopen? en die kan ook niet in de grote bak zoeken.

Zoijar schreef op vrijdag 06 juni 2008 @ 15:33:
Ik heb een tooltje voor je gemaakt in C++ met opencv...
http://www.xs4all.nl/~smit/facedetect.zip

+1 interresant,

Kun je heel kort vertellen hoe dit in elkaar zit, welke componten je aan elkaar knoopt? Heeft het zin de source in je zip te knopen of in ieder geval de kern daarvan te posten?

[Zoijar]

Source is erg simpel, gebruikt basic opencv, verder niks speciaals. Beetje in elkaar gehacked; kan vast beter.

C++:

#include "cv.h"
#include "highgui.h"

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
#include <math.h>
#include <float.h>
#include <limits.h>
#include <time.h>
#include <ctype.h>

#include <iostream>
#include <string>

int main( int argc, char* argv[] ) {
    CvMemStorage* storage = 0;

    CvHaarClassifierCascade* cascade = (CvHaarClassifierCascade*)cvLoad("haarcascade_frontalface_alt.xml", 0, 0, 0 );
    
    if(!cascade) {
        std::cout << "ERROR: Failed to find .xml file" << std::endl;
        exit(1);
    }
    
    storage = cvCreateMemStorage(0);

    std::string str;
    while (std::cin >> str) {
        str = std::string("images\\") + str;
        std::cout << "Processing " << str << " ...";

        cvClearMemStorage( storage );

        IplImage *img = cvLoadImage(str.c_str());

        if (img == 0) {
            std::cout << "File not found." << std::endl;
            continue;
        }
        CvSeq* faces = cvHaarDetectObjects(img, cascade, storage, 1.1, 2, CV_HAAR_DO_CANNY_PRUNING, cvSize(40, 40) );

        if (faces && faces->total > 0) {
            std::cout << "   Face found!" << std::endl;
        } else {
            std::cout << "   No face found, moving ..." << std::endl;
            std::string command = std::string("move ") + str + std::string(" images\\noface");
            std::cout << command << std::endl;
            system(command.c_str());
        }
    cvReleaseImage(&img);
    }
    
    return 0;
}