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
