Jinak ... když si povolíš logování, tak se loguje i grafická reprezentace toho textu, takže tam uvidíš, co a jak to rozpoznává.
Honza 2010/2/13 Jan Bilak <[email protected]>: > Ahoj, > ten copyright je vlevo nahoře, ale pak i na souřadnici cca [530,510] px. > > Ta detekce bodů ... toho jsem si nevšiml. Jak to kontroluješ? > > Check ... to značí opravdu i nepatrný překryv. Pokud si to není jisté, > tak je tam znak otazník a v hranatých závorkách seznam možností. Ještě > tam dám jednu kontrolu a mělo byt o být myslím 100% spolehlivé, když > tam nebude žádný červený bod chybět (tedy je třeba použít možnost a) > nebo b) vypořádání se s copyrightem). > > Ořez před detekcí nedělám ... detekce si sama řídí, kdy skončit. > > Check by nemělo být nic, co by bylo třeba ručně kontrolovat - až se > vyřeší ten copyright a přidám tam tu jednu drobnou kontrolu. Těch > možností, kdy se tam objeví otazník (není si to jisté) je myslím > minimum. Zatím se mi to nestalo. > > Honza > > > 2010/2/13 Petr Dlouhý <[email protected]>: >> Ahoj, >> >> ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud >> tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti >> dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla >> kreslí jen na dlaždici s tečkou). >> >> Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že >> by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší, >> tak to asi nebude problém udělat na jednou počítači. >> >> Chyby vidím následující: >> >> -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný >> text (přestože jsou daleko od všeho). >> -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud >> je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se >> ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na >> jiné posunutí č.e. vs č.p.). >> -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo >> ve vyšším rozlišení a detekovat to. >> >> >> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak <[email protected]> >> wrote: >> >>> Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy. >>> Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne. >>> Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze >>> červenou barvu. Jsou 3 možnosti jak to řešit: >>> >>> a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z >>> těch částí mapy, které copyright není. Výhody: Nejlepší výsledky. >>> Nevýhody: Nutnost stahovat více dat z WMS. >>> >>> b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy >>> downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody: >>> Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem >>> - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale >>> nemusí to znamenat nic, i když se to trefí. >>> >>> c) Provádět ruční kontrolu všech popisků s překryvem (těch může být >>> hodně). >>> >>> Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený >>> názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít >>> postřehnutelně horší výsledky. >>> >>> Honza >>> >>> >>> >>> 2010/2/12 Jan Bilak <[email protected]>: >>>> Doplnil jsem tam chybějící číslici 4. >>>> >>>> Honza >>>> >>>> 2010/2/12 Jan Bilak <[email protected]>: >>>>> K vyzkoušení: >>>>> http://jabi.aspone.cz/osm/OcrBeta1.zip >>>>> >>>>> Má to stejné ovládání jako původní tile-processor, ale navíc možnost >>>>> logování: >>>>> >>>>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv >>>>> -log log.txt -all >>>>> >>>>> -log log.txt ... pokud se toto uvede, tak program bude logovat >>>>> nerozpoznané body nebo ty, které byly narušené překryvem. >>>>> >>>>> Pokud se uvede navíc -all, tak se budou logovat všechny body. >>>>> >>>>> Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je >>>>> to také textový soubor, který když zobrazíte fontem s pevnou šířkou, >>>>> tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za >>>>> č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při >>>>> spuštění v aktuálním adresáři. >>>>> >>>>> Honza >>>>> >>>>> >>>>> 2010/2/12 Jan Bilak <[email protected]>: >>>>>> Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude >>>>>> výrazně lepší než byla (to už je myslím teď). Ale stoprocentní >>>>>> samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. >>>>>> >>>>>> Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou >>>>>> dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A >>>>>> také jim to bude zatěžovat servery, když se to přežene s rychlostí >>>>>> stahování (mnoho vláken apod.). >>>>>> >>>>>> Honza >>>>>> >>>>>> >>>>>> 2010/2/12 Petr Dlouhý <[email protected]>: >>>>>>> Kvůli překryvům - čísla se s rozlišením zmenšují. >>>>>>> Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících >>>>>>> se >>>>>>> číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. >>>>>>> Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím >>>>>>> zabralo počítání. >>>>>>> >>>>>>> Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc >>>>>>> cenu, >>>>>>> protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat >>>>>>> příliš >>>>>>> mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení >>>>>>> může >>>>>>> nastat spíš tím, že je nutné zpracovat větší množství obrazové >>>>>>> informace. >>>>>>> >>>>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak >>>>>>> <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Ahoj, >>>>>>>> k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým >>>>>>>> rozlišením >>>>>>>> ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho >>>>>>>> detekovat oblasti, které obsahují adresní body. A jen tyto úseky >>>>>>>> stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit >>>>>>>> množství stahovaných dat. Přijde mi, že nejpomalejší bude právě >>>>>>>> stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas >>>>>>>> prodloužil. >>>>>>>> >>>>>>>> Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, >>>>>>>> které byste mohli někam hodit zazipované, abych to nemusel stahovat >>>>>>>> z >>>>>>>> WMS pro testování? >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>>> >>>>>>>> 2010/2/12 Petr Dlouhý <[email protected]>: >>>>>>>>> Ahoj, >>>>>>>>> >>>>>>>>> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, >>>>>>>>> tak by >>>>>>>>> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší >>>>>>>>> detekci >>>>>>>>> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším >>>>>>>>> zoomem, >>>>>>>>> tak to bude další plus). >>>>>>>>> >>>>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak >>>>>>>>> <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Ahoj, >>>>>>>>>> >>>>>>>>>> pokusná implementace je velmi rychlá a měla by být i spolehlivá. >>>>>>>>>> >>>>>>>>>> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. >>>>>>>>>> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas >>>>>>>>>> zpracování jednoho adresního bodu je 17 ms. To vše v jednom >>>>>>>>>> vlákně a >>>>>>>>>> tedy to zatěžuje jen jedno jádro procesoru. >>>>>>>>>> >>>>>>>>>> Zítra to snad dodělám do použitelného stavu. >>>>>>>>>> >>>>>>>>>> Honza >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2010/2/11 Petr Dlouhý <[email protected]>: >>>>>>>>>>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat >>>>>>>>>>> pouze >>>>>>>>>>> ta >>>>>>>>>>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je >>>>>>>>>>> tam ta >>>>>>>>>>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že >>>>>>>>>>> by to >>>>>>>>>>> nešlo >>>>>>>>>>> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, >>>>>>>>>>> takže >>>>>>>>>>> by >>>>>>>>>>> to bylo dobré napravit bez toho, abychom museli všechno >>>>>>>>>>> předělávat. >>>>>>>>>>> >>>>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec >>>>>>>>>>> <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat >>>>>>>>>>>> uříznutou >>>>>>>>>>>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Petr Dlouhý >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Talk-cz mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-cz mailing list >>>>>>>>>> [email protected] >>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Petr Dlouhý >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Petr Dlouhý >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> [email protected] >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> [email protected] >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> -- >> Petr Dlouhý >> >> _______________________________________________ >> Talk-cz mailing list >> [email protected] >> http://lists.openstreetmap.org/listinfo/talk-cz >> > _______________________________________________ Talk-cz mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-cz
