-
PHP
(
http://www.devprotalk.com/forumdisplay.php?f=9)
| ivanhoe |
27. 03. 2010. 21:43 |
provera duplikata fajlova
Treba da sprecim da se 2 iste slike uploaduju, pa trazim sto efikasniji nacin za to.
Da li se crc32 moze pouzdano koristiti za detekciju duplikata? On je pre svega predvidjen za detekciju gresaka, i cuo sam da on ima mnogo vecu sansu za koliziju kljuceva(da sve razlicite vrednosti daju isti hash) od npr. md5, ali je i dosta brzi. Posto se radi o slikama od po 7-10MB performanse nisu zanemarljiva stvar, ali me brine da se ne desi da u nekom trenutku dve razlicite slike imaju isti "potpis" ? Kolike su tacno sanse za koliziju i da li treba brinuti o tome sa nekih 300K slika u bazi?
|
| dinke |
27. 03. 2010. 22:24 |
Ja bih pre probao da procitam exif podatke (npr timestamp snimka i model kamere koji je koriscen), mada ne znam sa kakvim slikama baratas, tj. da li je exif available.
|
| zlukic |
28. 03. 2010. 14:07 |
Pokusaj da imenujes slike tako da nikad ne dodju u koliziju. Mozda jedna od varijanti da ti bude da u njihovo ime dodajes datum do milisekunde ili da ih u potpunosti zamjenis sa datumom. U bazi drzi njihov opis koji ces smjesti u alt="" i to bi bilo dovoljno.
U nekim aplikacijam gdje se unose vece kolicine slika koristio sam takvan nacina upisa i nikad nije doslo do dupliranja. Isao sam i krak dalje te sam prema datumu radio i sistem foldera u koje sam unosio slike. Kasnije mi je to pomoglo da lakse radim arhiviranje. Laksa je automatizacija jer postoji neka logika bez potrebe da citam vrijeme upisa ili modifikacije slike. Ako dodje do pogreske pri unosu lako je zamjeniti sliku pod istim imenom.
Ovakav ili slican nacin imenovanja slika primjetio sam da koriste neke aplikacije koje dnevno primaju vise hiljada slika.
|
| DejanVesic |
29. 03. 2010. 11:39 |
Kako CRC32 ima 2^32 kombinacija, šansa da ti dve od 300K slika upadne u istu klasu (da daju isti CRC a da su zaista različite) je oko 0.007 %
Ja bih išao na MD5
|
| ivanhoe |
29. 03. 2010. 14:32 |
@dinke: teoretski bih mogao da gledam ime fotografa i vreme, sto nije losa ideja.. a mozda postoji i neki ID kamere u Exif-u, odnosno IPTC... istrazicu..
@zlukic: nije problem u imenovanju, problem je da neko ne uploaduje istu sliku 2 puta
@dejan: mislim da to ne mozes tako da racunas, jer tu se primenjuje onaj birthday paradox, a i nije idealna hash funkcija u pitanju (da pokrije svih 2^32 kombinacija)
Anyhow, znaci md5() za sad, i meni se cini... a i Dinketov predlog je odlican...
|
MD5 bi bio ok. Samo je pitanje je koliko ce ti hash pomoci kada su slike u pitanju, jer je dovoljno da slika bude u drugom formatu, optimizovana ili u malo drugacijoj rezoluciji i tebi ce izgledati da su razlicite, iako su prakticno "iste".
Pretpostavljam da je jedini nacin da se u vecini slucajeva obezbijedis od duplikata upotreba nekog liba za poredjenje slika po slicnosti (piksela).
|
| jablan |
29. 03. 2010. 15:01 |
Možeš da probaš sa sledećim trikom: porediš ovim redosledom:
* Veličina fajla
* MD5 poslednjih n bajtova fajla (tipa 16k), ovo bi trebalo da ide brzo.
Pa tek ako su oba ova broja ista, radiš MD5 celih fajlova.
|
| McKracken |
29. 03. 2010. 15:56 |
Imas nekoliko image hashing resenja koja podrzavaju i perceptualno poredjenje,
npr: http://www.phash.org/ |
| zidoo |
29. 03. 2010. 16:03 |
md5, imam bazu od ~400.000 slika i za sad ni jedan problem ... Dejan rece da je sansa 0.007% ... veca je sansa da meteor pogodi server ...
|
| ivanhoe |
29. 03. 2010. 20:26 |
@zidoo: za md5 nije frka, sanse za koliziju sa minimalne, samo je on malo sporiji i zahtevniji, zato sam mislio da mozda koristim neki drugi...
@McKracken: thanks za ovo, pogledacu
@zira: svestan sam toga, ali to mi nije toliki problem, ovo je arhiva za profi fotografe i samo je bitno da neko greskom ne uveze iste slike 2 puta, a ako bude nekih izmena (tipa editori vrate sliku na doradu) to ionako tretiraju kao potpuno novu sliku, tako da me to ne pogadja.
@jablan: hmmm, mudro zboris :)
|
| dinke |
29. 03. 2010. 20:30 |
A sta je sa dve iste fotke u razlicitoj rezoluciji? To se smatra duplikatom ili ne? Ako da onda hash check ne pije vodu, onda ti je exif ili perceptualni check (ovo sto kaze McKracken) jedino resenje.
|
| jablan |
29. 03. 2010. 21:04 |
Citat:
Originalno napisao ivanhoe
(Napišite 82558)
@jablan: hmmm, mudro zboris :)
|
Zapravo, zamisli iduću perverziju: s obzirom da su u pitanju goleme fotke čiji upload verovatno ume da potraje, odradiš MD5 početnih n kilobajta u toku uploada i odmah upozoriš korisnika da takva fotka već postoji, pre nego što se upload završi. ;) |
| ivan.skugor |
08. 04. 2010. 15:03 |
Citat:
Originalno napisao jablan
(Napišite 82562)
Zapravo, zamisli iduću perverziju: s obzirom da su u pitanju goleme fotke čiji upload verovatno ume da potraje, odradiš MD5 početnih n kilobajta u toku uploada i odmah upozoriš korisnika da takva fotka već postoji, pre nego što se upload završi. ;)
|
Imam 2 pitanja u vezi ovog:
1. kako mislis rjesiti problem slika koji imaju isti hash za prvih n kilobyte-a?
2. je li uopce i kako je moguce napraviti hash od prvih n kilobyte-a ako cijela slika nije uploadana? Pricam naravno o PHP rjesenju. |
| jablan |
08. 04. 2010. 15:52 |
Kao prvo, cela ideja je samo ideja, daleko od toga da sam radio nešto slično, dakle u pitanju je teoretisanje. Za većinu sajtova kojoj velike fotke nisu u centru pažnje, ovo nema smisla, ali verovatno postoje i sajtovi kojima se isplati da istraže malo u ovom pravcu. Naravno, uvek postoji mogućnost da se upload radi nekim dedicated klijentom, Java appletom ili bilo čime drugim.
Citat:
Originalno napisao ivan.skugor
(Napišite 82943)
1. kako mislis rjesiti problem slika koji imaju isti hash za prvih n kilobyte-a?
|
Npr. tako što se prenos neće automatski prekinuti, već npr. ajax-om prikazati thumbnail već postojeće slike sa prigodnim tekstom, na foru: "sledeća slika već postoji, da li ste sigurni da ne šaljete istu tu?".
Citat:
2. je li uopce i kako je moguce napraviti hash od prvih n kilobyte-a ako cijela slika nije uploadana?
|
Zašto ne (naglašavam, teoretski) bi bilo moguće? Ti kilobajti su preneseni na server, zar ne? A kako, ne znam. :) Uvek ostaje mogućnost da sam iskodiraš specijalan veb server (ostatak sajta da ostane na mod_php ili čemu već), samo za POST-ovanje slika, pa da imaš punu kontrolu na nivou soketa. |
| ivan.skugor |
08. 04. 2010. 16:12 |
Citat:
Originalno napisao jablan
(Napišite 82945)
Kao prvo, cela ideja je samo ideja, daleko od toga da sam radio nešto slično, dakle u pitanju je teoretisanje. Za većinu sajtova kojoj velike fotke nisu u centru pažnje, ovo nema smisla, ali verovatno postoje i sajtovi kojima se isplati da istraže malo u ovom pravcu. Naravno, uvek postoji mogućnost da se upload radi nekim dedicated klijentom, Java appletom ili bilo čime drugim.
|
Bilo bi zanimljivo vidjeti kako je to rjesio jedan Flickr ili nekakav slican servis. :)
Citat:
Originalno napisao jablan
(Napišite 82945)
Npr. tako što se prenos neće automatski prekinuti, već npr. ajax-om prikazati thumbnail već postojeće slike sa prigodnim tekstom, na foru: "sledeća slika već postoji, da li ste sigurni da ne šaljete istu tu?".
|
Nisi shvatio. :)
Probat cu pojednostaviti. Uzmi npr. da imas jednu uploadanu sliku ciji bitovi pocinju sa npr. "0000" i drugu koju namjeravas uploadati ciji bitovi pocinju isto sa "0000". Za njih dvije ces izracunati isti hash ako racunas hash na temelju prva 4 bita, ali one ne moraju nuzno biti iste, prva moze biti "0000 0000 ..." a druga moze biti "0000 1111 ...".
Nadam se da ti je sad jasnije (iako, i ova situacija je daleko teoretiziranje :) ).
Citat:
Originalno napisao jablan
(Napišite 82945)
Zašto ne (naglašavam, teoretski) bi bilo moguće? Ti kilobajti su preneseni na server, zar ne? A kako, ne znam. :) Uvek ostaje mogućnost da sam iskodiraš specijalan veb server (ostatak sajta da ostane na mod_php ili čemu već), samo za POST-ovanje slika, pa da imaš punu kontrolu na nivou soketa.
|
Da, tako se i meni cini, jer gledano sa aplikativnog sloja ili imas cijelu sliku ili je nemas uopce (npr. ukoliko je doslo do nekakve greske u prijenosu koja se ne moze otkloniti). |
| ivanhoe |
08. 04. 2010. 16:21 |
ideja je dobra, ali moralo bi se uzeti u obzir da slike na pocetku imaju zaglavlje koje zavisi od formata.
Ja bih to ovako: Flash upload koji prenese samo deo fajla (mislim da je to izvodljivo), onda se to uporedi, nadju se slike koje se matchuju (jedna ili vise), pa se korisniku prikaze dijalog: Da li je slika koju uploadujete neka od ovih slika? i prikazu se thumbovi tih slika koje su vec u bazi.
Ali to neki drugi put, kad ne budem imao pametnijeg posla :)
|
| jablan |
08. 04. 2010. 16:29 |
Citat:
Originalno napisao ivan.skugor
(Napišite 82946)
Nisi shvatio. :)
Probat cu pojednostaviti. Uzmi npr. da imas jednu uploadanu sliku ciji bitovi pocinju sa npr. "0000" i drugu koju namjeravas uploadati ciji bitovi pocinju isto sa "0000". Za njih dvije ces izracunati isti hash ako racunas hash na temelju prva 4 bita, ali one ne moraju nuzno biti iste, prva moze biti "0000 0000 ..." a druga moze biti "0000 1111 ...".
Nadam se da ti je sad jasnije (iako, i ova situacija je daleko teoretiziranje :) ).
|
Ama jesam shvatio.
Slike ne moraju nužno biti iste. Pretpostavimo da na serveru postoji još jedna (ili više, što bi bilo ekstremno retko) slika sa istim fingerprintom na osnovu prvih N kilobajta. Ajaxom se korisniku, u toku uploada, prikažu thumbnailovi tih slika sa istim fingerprintom i poruka da može da prekine upload ako među thumbnailovima vidi onu koju uploaduje. Eto.
@ivanhoe: tačno je da postoji zaglavlje, ali pretpostavljam da je ono u prvih kilobajt-dva, 16 ili 32k verovatno zahvata dobrim delom sam image-data, a prenese se začas. |
| ivan.skugor |
09. 04. 2010. 00:40 |
Citat:
Originalno napisao jablan
(Napišite 82950)
Slike ne moraju nužno biti iste. Pretpostavimo da na serveru postoji još jedna (ili više, što bi bilo ekstremno retko) slika sa istim fingerprintom na osnovu prvih N kilobajta. Ajaxom se korisniku, u toku uploada, prikažu thumbnailovi tih slika sa istim fingerprintom i poruka da može da prekine upload ako među thumbnailovima vidi onu koju uploaduje. Eto.
|
Aha. Da, to donekle ima smisla. Samo onda vjerovatno hash nije najbolje rjesenje, posto on za totalno razlicite slike moze dati slican hash, dok za one s minimalnom razlikom moze dati ogromnu razliku.
S druge strane - trebao bi ili racunati hash od prvih n-byte-ova za sve uploadane slike ili imati negdje spremljene predizracunate hashave, sta opet dodatno opterecuje server narocito ukoliko je velik broj slika u pitanju.
Meni osobno se to cini prekomplicirano za implementirati, a benificije su upitne. :) |
| jablan |
09. 04. 2010. 09:34 |
Off Topic: Hash može biti samo isti ili različit, ne može biti "sličan" ;) |
| misk0 |
09. 04. 2010. 10:46 |
Upitno je koliko ima smisla koristiti prvih nekoliko kilobajta. Mozda bi prije svega toga trebalo uraditi analizu veceg broja slika i vidjeti kakvi se rezultati dobiju.
JPEG koliko znam pocinje fajl sa gornjim lijevim uglom slike i ide prema donjem desnom. Kod BMP formata ide 'odozdo' prema gore.
Dosta slika prirode imaju 1/3nu neba koje je u gornjem dijelu i moguce je da je isto/slicno za velik broj slika.
|
| ivan.skugor |
09. 04. 2010. 11:53 |
Citat:
Originalno napisao jablan
(Napišite 82985)
Off Topic: Hash može biti samo isti ili različit, ne može biti "sličan" ;)
|
Slican hash u smislu da dvije slike imaju isti hash za prvih n kilobyte-a. :) |
| ivanhoe |
09. 04. 2010. 12:24 |
jpg ne ide po scan linijama, nego se deli slika na kvadrate, pa se oni cik-cak (tj. dijagonalno) prolaze od lego-gore ka desno-dole, pa se na tome radi Furijeova transformacija i odsecanje gornjih harmonika (znaci svi pixeli iz kvadrata uticu na rezultat). Ali u svakom slucaju primedba stoji da sve slike kojima je vece povrsina jednobojna, npr. cosak je beo (ogromna kolicina stock fotki) imaju verovatno vrlo slican data deo, ali ipak im se verovatno razlikuje meta deo (exif i sl..), tako da mislim da bi ovo sto jablan kaze radilo bez problema...
|
| robi-bobi |
09. 04. 2010. 14:30 |
|
| jablan |
09. 04. 2010. 15:33 |
Citat:
Originalno napisao misk0
(Napišite 82986)
Dosta slika prirode imaju 1/3nu neba koje je u gornjem dijelu i moguce je da je isto/slicno za velik broj slika.
|
Kao što rekoh, nema kod slika slično, nego ili je isto ili nije... :)
Mogli bismo da napravimo mali eksperiment: svako od nas napravi skroz beli JPG 1000x1000, pa da vidimo koliko prvih bajtova im se poklapa. Ja tipujem na između 10 i 50. ;) |
| misk0 |
09. 04. 2010. 16:20 |
Citat:
Originalno napisao ivanhoe
(Napišite 82993)
jpg ne ide po scan linijama, nego se deli slika na kvadrate, pa se oni cik-cak (tj. dijagonalno) prolaze od lego-gore ka desno-dole, pa se na tome radi Furijeova transformacija i odsecanje gornjih harmonika (znaci svi pixeli iz kvadrata uticu na rezultat). A
|
A kolike su velicine tih kvadrata? Stvarno nisam citao nista o formatu, ali znam da kad sam dobijao 'pola slike' (recimo prekine se transfer), da se vidi gornja polovina slika cijela a ostatak je siv. |
| ivanhoe |
09. 04. 2010. 20:18 |
nisam jasno napisao, kvadrati idu sleva na desno, redom, ali unutar svakog kvadrata se skeniranje radi po dijagonali... inace zbog tih kvadrata se javljaju jpeg artefakti, tako da kad stavis maximalnu kompresiju mozes jasno da ih vidis...
|
| Nemanja Avramović |
09. 04. 2010. 22:37 |
Mislim da su kvadrati veličine 8x8px - makroblokovi nad kojima se vrši DCT (furijeova transformacija), kvantizacija pa RLC
|
| ivan.skugor |
11. 04. 2010. 13:30 |
Citat:
Originalno napisao jablan
(Napišite 82998)
Mogli bismo da napravimo mali eksperiment: svako od nas napravi skroz beli JPG 1000x1000, pa da vidimo koliko prvih bajtova im se poklapa. Ja tipujem na između 10 i 50. ;)
|
Postoji vise razlicitih nacina kodiranja JPEG slika, pa je stoga moguce da se sve slike poprilicno razlikuju (byte-ovno gledano).
Medjutim, kad bi svi koristili isti nacin kodiranja, dobili bi iste slike.
Enivej, nisam proucavao JPEG standard, ali sigurno postoje nekakvi meta-podaci o slici kakvi inace postoje kod slicnih stvari (od kojih su neki i nacini kodiranja, level kompresiranja, itd.), a koji su najvjerovatnije stavljeni na pocetak. Njihove varijacije nisu velike, pa stoga vjerojatnost da dvije slike imaju isti hash na temelju prvih n kilobyte-a uvelike raste ako uzmemo u obzir veliku kolicinu slika prvenstveno, a zatim i vec spomenute slicnosti tematike slika (nebo, mrak, jednobojne pozadine). Naravno, ta vjerovatnost uvelike ovisi i o odabiru broja n (veci n manja vjerojatnost pronalaska istog hash-a za razlicite slike).
Ja na problem gledam matematicki, mozda ne bi bilo lose prouciti standard. :) |
| Vreme je GMT +2. Trenutno vreme je 20:02. |
|
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.
