Einfluß von Zoomgrad und Format auf Qualität

    Was ich noch feststellen konnte, dass nicht alle Kacheln davon betroffen sind. Von 25 Kacheln vielleicht mal 4 oder 5 Stück.


    Sobald ich wieder daheim bin werde ich sie dir zuschicken.


    lg


    Danjel

    Frage zu PNGOut.


    Auf Grund dieser Beiträge habe ich mir auch einmal das Programm heruntergeladen.


    Kleinere Dateien lassen sich einwandfrei weiter komprimieren.


    Nehme ich aber größere PNG-Files (hier ca. 19 - 21 Mb) bricht das Programm nach kurzer Zeit ab. Ist das normal, oder liegt es an der Art der Datei.
    Ich habe nichts im Internet hierüber gefunden.


    Gruß Heinz

    Ja, bei mir bleibt das auch stehen bei 20MB-Files. Da das Freeware ohne Source ist, lässt sich da auch weiter nichts ausrichten.


    Gut, ich hab PNGOUT anfangs hier mit etwas Euphorie angekündigt, als meine große Top25-Kartensammlung um etwa 20% schrumpfte. Allerdings war das Material nur im Default-Kompressionsgrad 6 von Irfanview abgespeichert. Nimmt man dort den Grad 9, sind die Zugewinne von pngout mit etwa 3% eher bescheiden. Und das bei extrem langer Rechenzeit (tausende Kacheln). Der Aufwand lohnt sich da fast nicht mehr.


    Alternativen wären "pngcrush" mit der brustalstmöglichen Kompression "-brute" ;D Aber das bewegt sich zum Grad 9 auch wieder nur im einstelligen Prozentbereich an Platzersparnis, bei extremer Rechenzeit für die Kombinatorik.


    Allerdings habe ich von den hier berichteten Bildstörungen noch nichts bemerkt.

    Hallo,
    und vielen Dank für die Info's.


    Bei einen verbleibenden Rest von 3 % lohnt sich der Aufwand der doppelten Bearbeitung nicht.


    Ich lass das Programm mal auf dem Computer, nimmt ja nicht viel Platz in Anspruch.


    Gruß Heinz

    Kacheln wurden geschickt...


    Ich hab nochmals versucht die original Kacheln mit pngout zu komprimieren. Leider hat er wieder die Kachel verunstaltet.


    lg


    Danjel

    Gut, dann häng deine Original- und komprimierte Kachel mal als Anhang dran, damit wir das checken können. Ich hab schon tausende Kacheln damit komprimiert und noch keine Bildstörung gesehen.

    frank334
    Ich habe jetzt Irfanview installiert, und gleich einmal einen Kompressionsversuch mit Grad 9 versucht.
    Die vorliegende *.jpg hat eine Größe von 145 Mb. Ausgang war eine mit tif eingescannte 1:25000 Karte von einer Mittelmeerinsel mit 450 Mb.


    Nach der Kompression hatte ich eine Png mit 220 Mb. Eine gleichzeitige Komprimierung mit OziExplorer ergab eine *.ozfx3 mit 54 Mb.
    Kann das angehen?


    Ist es eigentlich möglich aus der vorliegenden Karte (Größe etwa 8 x 10 km) mit dem GlopusMapManager in Kacheln aufzuteilen. Ich habe mit der Suchfunktion nichts gefunden. Wenn ja, gibt es einen workaround.


    Gruß Heinz

    Zitat

    Original von guardiadimori
    Ist es eigentlich möglich aus der vorliegenden Karte (Größe etwa 8 x 10 km) mit dem GlopusMapManager in Kacheln aufzuteilen. Ich habe mit der Suchfunktion nichts gefunden. Wenn ja, gibt es einen workaround.


    Hi,


    im GMM rechts, etwa in der Mitte, Reiter 'Teilen'


    Gruß
    H.-J.

    Bitte keine Supportanfragen per PN oder Mail, dafür ist das Forum da.


    Sind angekommen, danke. Alle 4 Bilder zeigen in 3 verschiedenen Bildprogrammen an ab einer bestimmten Zeile Fehler. Ich habe mir daher gar nicht erst die Mühe gemacht, das mit Glopus oder GMM zu testen. Da ist das Bild kaputt oder benutzt keine standardisierte Kompression.


    Es ist ganz schlecht ein Bild mit jpg zu packen und dann nach png zu konvertieren, da hat png ganz schlechte Karten. Interessant wäre, ob das original Bild Farbverläufe oder eher Farbflächen zeigt. Im ersten Fall sollte man bei JPG bleiben und kann da evtl. noch mit der Kompression spielen. Viele Karten sind aber eher mit wenig Farben gezeichnet und da kann man viel Platz sparen, wenn man mit einem Programm die Anzahl der Farben der eingescannten tiff Datei reduziert. Achtung kein Dithern erlauben!
    Allerdings habe ich dabei schon sehr schlechte Erfahrung sogar mit "Profiprogrammen" gemacht, da die "berechnete" Palette bei der Farbreduktion sehr ungünstig war.
    Theoretisch könnte das der GMM (da habe ich extra eine Routine zur Palettenoptimierung geschrieben), nur habe ich den nicht für so große Karten entwickelt und ich unterstütze auch kein tif. Schade, dass dein Original so groß ist. Ich hätte gerne mal getestet, wie weit ich das Bildchen für Glopus bei guter Qualität kleinquetschen kann. :)


    Das erste Problem ist JPG. Bei Topo-Karten ist das sinnlos und du hast damit Bildinformation vernichtet, die eine spätere PNG-Kompression deutlich erschwert (die berüchtigten DCT-Blockartefakte). Zumindest gilt das für ideale Topo-Karten von digitaler CD-Vorlage. Bei gescannten Karten relativiert sich das wieder etwas.


    Weiterhin spielt die Farbreduktion eine Rolle. Bei identischen Ausgangsbedingungen komprimiert *.ozfx3 schlechter als PNG: bei mir in einer Top50 Testkachel 1200kB für OZFX3 und nur 744 kB für pngout-PNG! Manche Ozi-User vergleichen gerne Äpfel mit Birnen, wenn sie qualitativ minderwertigere 16-Farben-Karten mit 256-Farben GIF's vergleichen. Reduziere doch mal die PNG-Karte auf die gleiche Farbanzahl wie die Ozi-Karte. Noch schlechter ist das Ozi-Format im Vergleich zu JPEG bei Satellitenfotos, Qualität und Kompression mieserabel: bei vergleichbarer Qualität: 5.7 MB JPEG vs. 45 MB OZFX3. Es hängt halt vom Material ab, nicht jedes Kompressionsverfahren ist für alles geeignet. Auch PNG ist nicht das Nonplusultra. Die FAX G4-Kompression von TIFF kann bei gescannten S/W-Seiten nochmal auf die Hälfte von PNG reduzieren (muss in IrfanView in den Optionen eingestellt werden). Das Wunder dabei ist die Lauflängenkodierung (RLE), die bei solchen großflächigen S/W-Strukturen optimal zuschlagen kann. Ich dachte, auch Ozi würde RLE benutzen, aber nach der Testkachel zu urteilen war's das nicht, oder schlecht implementiert. Bei Topo-Material ist RLE gegenüber der inflate-PNG-Kompression überlegen. Aber nur bei Idealkarten aus digitalen Quellen. Ein Papierscan mit minimalsten Farbverläufen würde die ganze RLE-Überlegenheit wieder zunichte machen, es sei denn das wird wieder ausgebügelt, wie bei Reduktion auf 1-Farb S/W.

    Erstmal danke,
    ich habe mit IrfanView die Tiff Ausgangsdatei in BMP gewandelt. Hierbei alles bei den Standardeinstellungen belassen, und damit wurde die Datenmenge von von fast 500 Mb auf 270 Mb reduziert -oh Wunder, keine Ahnung warum.
    Als nächsten Schritt die Farbtiefe von 256 auf 16 reduziert. Dies ergab eine bmp Datei mit 48 Mb.
    Bei der Wandlung in das png Format hatte ich eine Größe von 19 Mb.


    Gefallen hat mir die Karte allerdings nicht mehr. Mit den Farbänderungen (z.B. die Straßen waren nicht mehr rot sondern rotbraun) könnte ich noch leben. Aber die Grundfarbe Weiß war jetzt Hellbeige.


    Die erzeugte png Karte lies sich nicht in Glopus laden. Gibt es eine max Größe?


    Mit der weiter oben angeführten Beschreibung der Kachelerzeugung komme ich auch nicht so recht klar. Bei Auswahl der Karte und Einstellung unter Teilen (1000 x1000 Überlappung 10) erzeugt GMM nur eine Kachel (Nord/Ost Ecke).


    Wie schon mal erwähnt, beschäftige ich mich mit den Rasterkartenprogrammen erst seit ca. 3 Wochen. Mit Ozi gab es bisher nur kleine Probleme dank der Handbücher.

    frank334: die OZFX3 sind bei mir immer größer als die Ausgangskarte. Das liegt m.W. daran, das dort 2 Zoomstufen gespeichert werden (je nachdem was man beim img2ozf eingestellt hat).


    guardiadimori: ich hab in Glopus bislang nur 1,5 MB große Karten geladen. Eine 6 MB großes jpg wollte nicht, Du mußt hier auf jeden Fall ein paar Kacheln generieren. Die Größe der Kachelselbst ist dabei egal, wichtiger ist die resultierende Dateigröße.

    Ok, das würde etwa die 1/3 Übergröße versus PNG erklären. Nur die 45 MB Ozi OZFX3 vs. 6 MB JPEG-Foto (Qualitätsgrad 40) können keine Zoom-Extras sein. Das ist einfach nur schlecht komprimiert. Es ist auch unmöglich, das ein Bildkompressionsverfahren für alle möglichen Bildtypen gut ist. Für Sat-Fotos ist ECW (JPEG2000) wohl das Beste derzeit.

    Zitat

    Original von fortwienix
    Die Größe der Kachelselbst ist dabei egal, wichtiger ist die resultierende Dateigröße.


    Das ist doch Humbug !!!!!


    (Mit einer Ausnahme das die 6MB-JPG und die Ausgepackte nicht mehr zusammen in den Speicher passen).


    Entscheident ist einzig und allein die Pixelzahl und die Farbtiefe !!!


    Weil alle Karten im Speicher ausgepackt werden egal in welchem Format sie vorliegen!! haben sie alle im Speicher bei gleichen Pix und Farbtiefe die selbe Größe.


    Je nach PDA-Model (freier Speicher) gibts da gewisse größen Beschränkungen das Maximum dürfte sich so im Raum 2000*2000Pix*32Bit bewegen , wobei da es schon Probleme mit wieteren laufenden Programmen geben kann!


    Max Sinnvoll dürfte sich der Bereich um 1000-1300Pix*8Bit sein um schnelles Nachladen und noch Speicher für andere Porgramme zu haben.

    Regioausflug.de Wandertourenplaner für Odenwald, Rhön, Mittelrhein und Taunus!!!!


    Ein Stau ist nur hinten blöd - vorne gehts !!!!