467 odpovědí na toto téma

[Parkis]

aktuální verzi mám, teď jsem koukal na ten obrázek a podle irfanu je to png uložený s příponou jpg, takže se není co divit že to zbuchlo Vypádá to že tyto paskvily vyrábí gc.com při konverzi uploadovaných obrázků na jpg

[Sally&eL]

...aktuální verzi mám taky a klidně sem můžu příště přihodit vadný obrázek ...ale jak píše Parkis - vždy se jedná o špatnou příponu

[gord]

Jsou fotky, ktere to delaji stale (pokud vim, medwyn ma zasoubu nejmene dvou kesi, ktere si dal ignorovat). Skript s tim fakt udelat nic nemuze, ani se to nedozvi. Problem je v konfliktu graficka knihovna-obrazek. Skript zavola funkci z knihovny (v dobre vire) a ta funkce zhavaruje. To jen doplnuji vysvetleni, ktere podal HaLuMa.

[sobikovi]

Malý nápad pro případnou budoucí verzi makra nebo případně prosba o dodělání do toho současného... Bylo by možné při průchodu makra a nalezení keše se spoilerem i tagovat tuto keš v GG např. tagem Spoiler = Ano? Dalo by se to pak použít v nové šabloně pro export do gpx aspoň avizem, že keš má spoiler a kačer by se mohl když tak podívat třeba přes mobil atd. na obrázky na netu, pokud by neměl vše v POI....

[medwyn_cz]

Ukladat to do tagu je docela nevhodne. Takova informace se meni, zastarava. Zavisi na definici klicovych slov v nastaveni makra. Algoritmus zjistovani neni spolehlivy atd atd... Ja jsem proti. Ale to je tak to jedine, co s tim mohu delat :-)

[sobikovi]

Tak nevím, vyskočilo náhle okno s chybou.. asi vadný formát obrázku, ale jak to mám opravit a pustit dál? Když upravím stažený obrázek a pustím makro znovu, tak se stejně stáhne zase ten vadný a všechno to padne

Přiložené miniatury

• 

[medwyn_cz]

Normalka. Stava se to cim dal casteji. Je to chyba v knihovne, kterou pouziva GG na praci s obrazky. Respektive ten obrazek NENI JPG, ackoliv ma JPG priponu. Ve skutecnosti je to uvnitr PNG nebo neco jineho. Reseni je proste - smazat vadny gcimage tag z kese a smirit se s tim, ze u ni spoiler nepregenerujes. Zatim.

[klama]

Tento problem som pre mozigo nazval "falosnym" jpg, v mojom sw sa prejavil uz davno najma kvoli tomu, ze mozigo stahuje obrazky z webu a predefinovava ich na lokalne odkazy. Browser ktory pouzivam je samozrejme zalozeny na IE a ten sa chova tak, ze ten isty obrazok ak je na webe spracuje spravne ale ak je umiestneny lokalne tak ho nezobrazi...Samozrejme to plati eaj pre PDA a browser v nom.Asi to vyplyva z prehnanej bezpecnosti IE a ak obrazok nie je v deklarovanom formate (jpg), tak ho jednoducho nezobrazi...Mozille to je jedno a spracuje aj lokalny "falosny" jpg - hoci to je png obrazok. Viem ze sato stava tak, ak autor listingu doda obrazky ktore nezodpovedaju obmedzovacim kriteriam /velkost,rozmery/ tak ho server na gc.com spracuje sam ale tak, ze z neho akoze urobi jpg subor ale v skutocnosti to je png. Dalsi neprijemny dopad je ten, ze takyto obrazok ma aj cca 800kB ... Potom aj sw ktore v terene stahuju listing sa riadne nacakaju kym sa stiahne obrazok ktory ma 10x viac dat ako by mal ak by to bol spravny jpg. Zeby to bol zamer od gc.com? Preto v mozigo toto riesim prekonvertorovanim takychto obrazkov do skutocnych jpg suborov, na ine riesenie som neprisiel.

[HaLuMa]

No, vtipne je, ze v tom pluginu se pouzivaji funkce, kterym je naprosto jedno, jak se obrazek na vstupu jmenuje. Jmeno obrazku se na zpracovani ani nepredava, predavaji se rovnou jen binarni data toho obrazku, a je tak pouzit skutecne zjisteny format. A na konci se to prevede na JPEG, at to bylo cokoliv. Problem je patrne jen v tom, ze v tom pluginu se ponekud nestastnym zpusobem zjistuji rozmery puvodniho obrazku pres TImage, a tam to pravdepodobne zhavaruje. Takze staci pridelat funkci na zjisteni informaci o obrazku, cimz se bude moci cely Timage vynechat, a bude to samo o sobe tomuto problemu odolne.

[Sally&eL]

...normálně ten obrázek otevřu a uložím jako skutečný jpg - nic se znovu, při opětovném spuštění makra, již nestahuje

[gord]

medwyn_cz napsal/a:
Ukladat to do tagu je docela nevhodne.
Takova informace se meni, zastarava. Zavisi na definici klicovych slov v nastaveni makra. Algoritmus zjistovani neni spolehlivy atd atd...
Ja jsem proti. Ale to je tak to jedine, co s tim mohu delat :-)

V tom jsem s tebou zajedno.

Tag by mel byt nemenny (za normalnich okolnosti). V tomto pripade by zavisel na nastaveni klicovych slov, tedy na necem vnejsim a snadno zmenitelnym.

Ale pokud to, Sobiku, potrebujes, nic ti nebrani si tam doplnit ten jeden nebo 2 prikazy pro vytvoreni TAGu u kese (pozor, at opravdu udelas jen jeden, i kdyz je vic spoileru u jedne kese ;-) )

[gord]

HaLuMa napsal/a:
No, vtipne je, ze v tom pluginu se pouzivaji funkce, kterym je naprosto jedno, jak se obrazek na vstupu jmenuje. Jmeno obrazku se na zpracovani ani nepredava, predavaji se rovnou jen binarni data toho obrazku, a je tak pouzit skutecne zjisteny format. A na konci se to prevede na JPEG, at to bylo cokoliv.

Problem je patrne jen v tom, ze v tom pluginu se ponekud nestastnym zpusobem zjistuji rozmery puvodniho obrazku pres TImage, a tam to pravdepodobne zhavaruje.

Takze staci pridelat funkci na zjisteni informaci o obrazku, cimz se bude moci cely Timage vynechat, a bude to samo o sobe tomuto problemu odolne.

Znamenam si a az budu mit chvili, kouknu na to.

[pozorjed]

do testu nové verze bych navrhoval přidat i tuto keš GC2JVV2 nyní se stáhne soubor s názvem "GC2JVV2_FotohintmistoUlozeniKeseJeOznacenoModrouSipkou.Br.jpg" o velikosti 840287 B prohřešky, které je potřeba ošetřit: 1. přidávání tagu BR do názvu souboru, případně vynechat i tečky 2. název souboru klidně zkrátit na 32 znaků, plus případný numerický počet na 2 znaky, něco jako GC2JVV2_Fotohint01, GC2JVV2_Fotohint02, GC2JVV2_Fotohint03 3. na velikosti souboru skončí vytvoření zmenšené kopie 240x400 (poznámka, soubor má v hlavičce uvedeno PNG, ale přípona je JPG)

[pozorjed]

medwyn_cz napsal/a:
Reseni je proste - smazat vadny gcimage tag z kese a smirit se s tim, ze u ni spoiler nepregenerujes. Zatim.

no, než ručně mazat při postupných 10 chybách 10 jednotlivých keší, spíše ošetřit chybu a vytvoření spoilu přeskočit

[medwyn_cz]

Ja nerikam, ze to neni potreba opravit. Ale je to okamzite reseni incidentu. Bez zasahu do kodu makra

[Archi1]

sobikovi napsal/a:
Tak nevím, vyskočilo náhle okno s chybou.. asi vadný formát obrázku, ale jak to mám opravit a pustit dál? Když upravím stažený obrázek a pustím makro znovu, tak se stejně stáhne zase ten vadný a všechno to padne

Ahojky,
pri stahovaní spoileru mi to vyhodilo stejnou chybu jako Sobíkovi. Muzete poradit jak u dotycné kesky(GC2H3GM), ktera to delá, smažu vadny gcimage tag? Pokud smazu pres nastavení - konfiguraci GG tak gcimage tag vymažu u vsech kesí, ale to nechci. Díky za radu.

[medwyn_cz]

Uplne stejne jako jakykoliv jiny tag? V seznamu kesi kliknes pravym, zmenit tagy, oznacit vadny tag, smazat Jinak - v testovacich verzich geogetu a spoilermakra uz je toto vyreseno

[Archi1]

medwyn_cz napsal/a:
Uplne stejne jako jakykoliv jiny tag?
V seznamu kesi kliknes pravym, zmenit tagy, oznacit vadny tag, smazat

Jinak - v testovacich verzich geogetu a spoilermakra uz je toto vyreseno

Díky

[Sally&eL]

...najdi si tu fotku v offline adresáři, otevři si ji v nějakém prohlížeči (já používám třeba IrfanView) a pak to ulož jako JPG. Při opětovném spuštění Spoiler makra už ti to chybu nevypíše

[HaLuMa]

Dve poznamky k tem obrazkum: 1. novy Geoget uz tu pripadnou konverzi provede pri ukladani. Samotnemu Geogetu to sice bylo jedno, ale obcas se neco kolem vztekalo. Nicmene jiz ulozenych obrazku se to netyka. 2. na konverzi obrazku podle pripony lze napsat skript, Geoget ma na to funkci! Takze kdyz na to prijde, tu konverzi muze klidne delat i ten spilerovaci skript.