hi pathaway-experten.
unterstützt pathaway in seinem .prc container (oder irgendwie anders) das verwenden von truecolor-formaten mit lossy compression? meine ortofotos werden immer irgendwie in 8bit gequetscht, dabei werden sie verunstaltet und der platzverbrauch auf der sd-card verdreifacht sich :-/.
joe.
Hi,
mit welchen Optionen exportierst Du das?
hab alle optionen probiert... ein 2000x2000 ortofoto (im original 1MB jpeg datei) wird als .prc gnadenlos aufgebläht. bei truecolor auf 7MB, bei 8bit immerhin auf 2MB (inkl verunstaltung). sowohl beim export via ttqv als auch via OziMapConverter.
hat niemand eine doku zum .prc format? das ist scheinbar nur ein container für geo-koordinaten und für ein bmp. bmps sind logischerweise nicht wirklich geeignet für ortofotos :(.
was hats eigentlich mit der .pwm datei auf sich?
joe.
Hi Joe,
kannst Du mir das (für ttqv) kalibrierte Ortofoto mal zuschicken, damit ich selber damit rumspielen kann? Das ist einfacher als die Kristallkugel zu bemühen 
Ok, die Kugel ist gerollt.
8 Bit, no dither => 2940kb, schlecht lesbar
8bit, mit dither => 3668kb, gut lesbar
65000 Farben ==> 7632kb, gut lesbar
Ergo: ich würde in den Apfel beissen und die hier mittlere Einstellung nehmen.
Auf die Frage mit dem PWM-file hab ich aber keine Antwort.
Aber frag doch mal im Forum von ttqv nach, da werden Sie vielleicht geholfen.
ja genau... aber ist das nicht etwas frustig? aus 1MB src werden 3.7MB pathaway map?? dieser apfel schmeckt mir gar nicht... und das wo's bei den PDAs doch auf jedes byte ankommt. für mich machts schon einen unterschied, nur bayern oder halt bayern, tirol und südtirol dabei zu haben :-).
wie wärs mit einer gemeinschaftlichen lossy-compression-petition an scott von pathaway? auf einzel-requests hin scheint wenig zu passieren, aber jpegs laden ist ja nun heutzutage wahrlich kein kunststück mehr. das problem ist vielleicht eher, daß die amis keine so hübsch geschummerten karten haben bzw keine ortofotos benutzen. dann macht jpeg natürlich wenig sinn und man bekommt auch mit 32 farben recht kleine karten. ich kenn das leider aus eigener erfahrung als programmierer... wenn man ein feature nicht selbst braucht, hat man auch keinen bock es einzubauen :-).
joe.
Hallo Joe,
ZitatOriginal von joeuser
ja genau... aber ist das nicht etwas frustig? aus 1MB src werden 3.7MB pathaway map?? dieser apfel schmeckt mir gar nicht... und das wo's bei den PDAs doch auf jedes byte ankommt. für mich machts schon einen unterschied, nur bayern oder halt bayern, tirol und südtirol dabei zu haben :-).
wie wärs mit einer gemeinschaftlichen lossy-compression-petition an scott von pathaway? auf einzel-requests hin scheint wenig zu passieren, aber jpegs laden ist ja nun heutzutage wahrlich kein kunststück mehr. das problem ist vielleicht eher, daß die amis keine so hübsch geschummerten karten haben bzw keine ortofotos benutzen. dann macht jpeg natürlich wenig sinn und man bekommt auch mit 32 farben recht kleine karten. ich kenn das leider aus eigener erfahrung als programmierer... wenn man ein feature nicht selbst braucht, hat man auch keinen bock es einzubauen :-).
Ich hatte Dir bereits im TTQV-Forum geantwortet.
Du schreibst, dass es beim PDA auf jedes Byte ankommt. Meinst Du damit die Speicherkarte (SD o.ä.) oder vielleicht doch eher den Arbeitsspeicher?
Was nutzt es, platzsparend eine JPG auf Speicherkarte abzulegen, wenn Du sie zum Verwenden in den Arbeitsspeicher auspacken musst? Und das ist - wie ich im anderen Forum bereits schrieb - auch beim PC so: Ausgepackt hast Du wieder die gleiche Größe wie die zugehörige nicht komprimierte BMP-Datei.
Es nutzt Dir wenig, wenn PathAway das JPG-Format unterstützt, wenn Dir anschließend beim Verwenden der Speicher platzt.
SD-Karten sind nicht mehr teuer. Ich habe gerade eine 2 GB Ultra II von SanDisk für 46,99 (Otto Versand) gekauft. Da kriegst Du eine Menge Orthofotos drauf. Deshalb würde ich keinen weiteren Gedanken an JPG etc. verschwenden.
Gruß
Werner
logisch gehts hier um die sd-karte, worum sonst? meine hat 4gb (zur zeit 92E bei litec). na und? ist das ein grund, deswegen faktor 3 platz zu verschwenden beim grafikformat? klar... man könnte ja auch noch drei von den dingern kaufen... aber das kann doch keine ernsthafte argumentation sein oder?.
really... was pathaway dann im speicher des pda draus macht ist doch sowas von egal. meinetwegen soll er das ding halt in 8bit dithern direkt beim laden, wenn das handling von 16bit gfx im speicher wirklich so katastrophal schwierig sein sollte oder sonstwie nicht ins programmkonzept passt. ist aber imho eher ein non-issue bei aktuellen pdas, der resco picture viewer zum bleistift zeigt hier riesige jpegs blitzschnell an, zoomen und scrollen geht auch ohne merkliche verzögerung.
geht mir halt um die maximale ausnutzung meiner resourcen, und da ist ein faktor 3 schon schmerzlich. besonders wenn es routinen zum laden (und meinetwegen auch dithern) von jpegs zu dutzenden an jeder ecke im web for free zu haben gibt :-).
klar, wenn man immer nur am wochenende unterwegs ist oder nur tagestouren vom hotel aus macht, dann juckt einen das alles nicht. zu hause gibts ja den notebook, der hat alles vorrätig. aber fahr du mal nen monat mit dem radl von nizza über die berge nach münchen... dann würdest du dir auch wünschen, der faktor drei würde zum faktor eins.
ok... enough ranting. schlußendlich muß ich sowieso scott von der sinnhaftigkeit der lossy compression überzeugen, nicht euch :-).
joe.
Joe,
schau Dir mal Glopus an. Der Glopus MapManager macht aus großen Jpeg viele kleine, mit Kalibrierung, da ist die Verschwendung viel geringer. Und Glopus am PDA zeigt die dann schnittfrei an.
zitat von www.glopus.de:
"Wenn man kalibriertes Kartenmaterial z.B. Landkarten, Sattelitenaufnahme o.ä. in Form von Bildern im bmp, jpg, png oder gif Format hinterlegt hat, kann man sehr viele Informationen erhalten...
...Beim Zoomen und Verschieben sucht Glopus immer die optimalen Karten für die Anzeige und fügt gegebenenfalls mehrere Einzelkarten zu einer Ansicht zusammen. Dabei ist es kein Problem, wenn man vom Zielgebiet, verglichen mit den umliegenden Karten, Pixelkarten mit einem kleineren Maßstab hat. Eine für den PocketPC optimierte Render Engine errechnet aus dem vorhandenen Kartenmaterial immer eine optimale Karte. Diese kann auch gedreht und perspektivisch dargestellt werden."
das hört sich schon mal absolut genial an. hab ich mir vielleicht das falsche programm gekauft? die shareware-leute zeigen den kommerzis halt mal wieder wo's lang geht :-). danke für den tip, werd's gleich mal testen...
joe.
also die map-loading/render-engine von glopus ist genial... sowas wünsch ich mir für pathaway auch :-).
gibt es irgendwo ein tool um *.cal oder *.map nach *.kal zu übersetzen?
Hi,
Peter (der Autor) arbeitet daran, daß der GMM das TTQV cal format versteht und nach KAL umsetzen kann. Rat mal, wer danach gefragt hat
uhm... ich hoffe nicht nur GMM. GlopusPPC sollte selbst einfach *.map oder *.cal oder *.pwm lesen können. am liebsten auch gleich noch *.prc (sind auch nur ein paar tags für kalibirierung und ein embedded BMP). idealerweise auch noch ozf2. dann könnte man zum bleistift problemlos die gleiche kartendatenbasis auf der sd-card für ozice/pathaway/glopus benutzen. aber ich glaub das wär jetzt bei
http://www.pocketnavigation.net/board/board.php?boardid=96
besser aufgehoben.
Derzeit nur GMM. Ist doch kein Problem, Du kannst doch beide Kalibrierungsdateien drauf lassen, die sind ja nicht groß.
Zum Thema Container: Kannst Du die prc Datenstruktur beschreiben?
ja naja... mich nervts eh schon wenn man jeweils eine grafik-datei und eine cal-datei pro karte braucht... ist halt etwas unschöner zu handlen beim kopieren/sortieren/etcpp. je weniger desto besser, ideal wäre nur die grafik-datei mit embedded calibration, halt als exif-tags bei jpegs zum bleistift. da sollte mal jemand einen offenen standard dafür erfinden und nicht jeder sein eignes format basteln 
zum prc container... die korrekte doku kriegt man bestimmt nur von scott/pathaway oder tom/ttqv, oder doch eher überhaupt nicht. wird schon seinen grund haben, daß alle mit ihren proprietären formaten rumbasteln. ozfx3 ist ja in dieser hinsicht besonders krass und übel verschlüsselt.
prc hat ein paar 4-byte-tags, zB TLLG, TLLT, BRLG, BRLT gefolgt von jeweils sechs bytes, das sind sicher irgendwie topleft longitude, latitude, bottomright longitude und latitude. dahinter kommt dann wohl der bmp kram. hab allerdings jetzt noch nicht weiter geschaut, nachdem ich mit der platzverschwendung ja ein problem hatte. man kann die dinger sogar mit einem normalen ZIP noch 20% kleiner kriegen :-).
