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
