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
