Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » Höhenlinien-Interpolation

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 < [ 2 ]
000
21.11.2015, 00:40 Uhr
Yadgar



Hi(gh)!

Ich habe ein Programm geschrieben, das aus Bitmaps (TGA-Format) mit aus eingescannten topographischen Karten extrahierten Höhenlinien 16-bit-Heightfields für POV-Ray erzeugen soll. POV-Ray interpretiert dabei nur die Rot- und Grünwerte, so dass sich 65536 Höhenstufen ergeben.

Das Programm liest zuerst eine TGA-Datei (unkomprimiert, 24-bit, Beginn oben links) ein und errechnet für jedes Pixel mit einem Blauwert von 0 einen Farbindex aus den Rot- und Grünwerten (Rot * 256 + Grün). Alle Pixel mit einem Blauwert größer als 0 (also der z. B. weiße Hintergrund zwischen den Höhenlinien) werden mit -1 kodiert. Diese Daten werden in einem zweidimensionalen vector-Array vom Typ int gespeichert.

Parallel dazu wird ein gleichgroßes zweidimensionales Array vom Typ bool erzeugt und mit Werten gefüllt: true für im Original vorhandene Höhenlinien-Pixel, false für noch zu interpolierende Pixel.

Danach beginnt vom Koordinatenursprung der Bilddatei (also oben links) aus für jedes noch nicht interpolierte (also mit -1 kodierte) Pixel die Abtastung nach vorhandenen Höhenlinienpixeln in der Nachbarschaft. Dies geschieht in acht Richtungen, jeweils paarweise nach Nord und Süd, Ost und West, Nordost und Südwest, Südost und Nordwest. Für jedes Richtungspaar wird die Zahl der Iterationen bis zum erstmaligen Auftreten eines bereits gesetzten Pixels (also mit Blauwert = 0) festgehalten, soweit in jeweils beiden Richtungen unterschiedliche (!) Farbindexwerte gefunden werden, wird für jedes Richtungspaar ein nach den jeweiligen Entfernungen zum nächsten Original-Höhenlinienpixel gewichteter Mittelwert gebildet.

Bei den beiden diagonalen Richtungspaaren werden zusätzlich noch in jeweils rückwärtiger Abtastrichtung mit je einer Seite angrenzende Pixel berücksichtigt

Aufgrund der vier Richtungspaare können sich bis zu vier solcher MIttelwerte ergeben, die in einem dynamischen Array gespeichert werden und anschließend wiederum arithmetisch gemittelt werden. Dieser Mittelwert wird auf Ganzzahlen gerundet und in das vector-Array mit den Farbindexwerten geschrieben.

Nach Abschluss der Interpolation werden die Farbindexwerte in BGR-Tripel zurückgerechnet und eine TGA-Datei mit den neuen Bilddaten geschrieben, der Dateiname erhält den Anhang "_interpolated".

Soweit die Theorie. Tatsächlich gibt es gegenwärtig hauptsächlich zwei Probleme: geschlossene Höhenlinien, innerhalb derer zu interpolierende Pixel nur gleichwertige Höhenlinienpixel als Nachbarn haben (also Bergkuppen und Senken) und Pixel, die nahe am Bildrand liegen.

Letztere bleiben weiß, wohingegen Pixeln innerhalb geschlossener Höhenlinien teilweise Farbwerte zugewiesen werden, die (im Falle von Bergkuppen; Senken habe ich noch nicht getestet) niedriger sind als die umgebende Höhenlinie. Um dieses Problem zu vermeiden, habe ich das zusätzliche Array mit den bool-Werten zur Kennzeichnung ursprünglich vorhandener Höhenlinien-Pixel eingeführt. Abgesehen davon, dass sich selbst auf diese Weise immer noch Fehlpixel innerhalb geschlossener Höhenlinien einschleichen, treten jetzt auch digital verlaufende Artefakte auf, die vorher (also ohne bool-vector) nicht vorhanden waren.

Zur Veranschaulichung:

Test-Bitmap 10 x 10, original
Test-Bitmap 10 x 10, interpoliert
Test-Bitmap 157 x 115, original
Test-Bitmap 157 x 115, interpoliert
(mit rechter Maustaste anklicken und dann speichern - andernfalls wird möglicherweise ein Fehler angezeigt!)

Der Programmcode

Wahrscheinlich werde ich das bool-Array wieder zurücknehmen; allerdings stellt sich für mich auf jeden Fall die Frage, wie ich einen Algorithmus finde, der zuverlässig erkennt, ob sich ein Pixel innerhalb einer geschlossenen Höhenlinie befindet... könnt Ihr mir da weiterhelfen?

Bis bald im Khyberspace!

Yadgar
--
Flagmaker - ein Programmier-Blog

Dieser Post wurde am 21.11.2015 um 00:43 Uhr von Yadgar editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
21.11.2015, 14:12 Uhr
Yadgar



Hi(gh)!


Zitat von Yadgar:
treten jetzt auch digital verlaufende Artefakte auf


Diagonal natürlich, nicht digital...

Bis bald im Khyberspace!

Yadgar
--
Flagmaker - ein Programmier-Blog
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
21.11.2015, 18:14 Uhr
ao

(Operator)


Dazu fällt mir nur ein Wort ein: Hä?

Tut mir leid, aber da ich nicht weiß, was Heightfields und Povray sind, verstehe ich nicht, welches Problem du hier eigentlich lösen willst.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
21.11.2015, 20:04 Uhr
Hans
Library Walker
(Operator)


Hi,

Zitat von ao:
Tut mir leid, aber da ich nicht weiß, was Heightfields und Povray sind, verstehe ich nicht, welches Problem du hier eigentlich lösen willst.

@ao:
Ein Heightfield (auch Heightmap genannt) ist ein zweidimensionales Array, dessen Inhalte als Punkte in einer Ebene (Landschaft) gedeutet werden. Meisst integer, es können aber auch floatingpoint-Zahlen sein. Die Array-indizes entsprechen dabei den x-y-Koordinaten in der Ebene oder auch Längen- und Breitenangaben einer realen Umgebung (wobei die Abstände zwischen den einzelnen Punkten an anderer Stelle definiert sind). Die Zahlen selber geben dabei an, wie hoch (niedrig) der entsprechende Punkt über (unter) dem Nullniveau liegt.

Povray (auch POV-Ray) ist ein Raytracing Programm.

@Yadgar:
Konkret kann ich Dir auch nicht helfen, aber gemäss meines Nicknames hab ich einen Buchtip für Dich:
Hanan Samet, Applikations of Spatial Data Struktures (Computer Graphics, Image Processing, and GIS)
Verlag: Addison-Wesley Publishing Company, Massachusetts (u.a.), 1990
ISBN: 0-201-50300-X

Oder auch:
Hanan Samet, The design and analysis of spatial data structures,
Addison-Wesley, Reading, Mass. [u.a.], 1990
ISBN: 0-201-50255-0

Ich weis nicht, ob Dir das hilft oder was genau die Unterschiede zwischen den Büchern sind. Jedenfalls aber behandeln sie Probleme wie Deines hier und die Lösungen dazu. Die Bücher stammen von einem Geografen, weil man in der geografischen Softwareentwicklung auf ähnliche Probleme trifft. - Und soweit ich weis, gibt es sie nur in Englisch.


Hans
--
Man muss nicht alles wissen, aber man sollte wissen, wo es steht. Zum Beispiel hier: Nachdenkseiten oder Infoportal Globalisierung.

Dieser Post wurde am 21.11.2015 um 20:07 Uhr von Hans editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
21.11.2015, 23:54 Uhr
Yadgar



Hi(gh)!


Zitat von Hans:

@Yadgar:
Konkret kann ich Dir auch nicht helfen, aber gemäss meines Nicknames hab ich einen Buchtip für Dich:
Hanan Samet, Applikations of Spatial Data Struktures (Computer Graphics, Image Processing, and GIS)
Verlag: Addison-Wesley Publishing Company, Massachusetts (u.a.), 1990
ISBN: 0-201-50300-X

Oder auch:
Hanan Samet, The design and analysis of spatial data structures,
Addison-Wesley, Reading, Mass. [u.a.], 1990
ISBN: 0-201-50255-0



Hanan Samet, der Name klingt arabisch - dies zur der bis zum Erbrechen in den Onlinezeitungs-Leserkommentarspalten und natürlich auf den "politisch unkorrekten" Blogs (uärgl!) durchgehechelten Latrinenparole, derzufolge Menschen aus arabischen Ländern (sogenannte "Musels") geistig minderbemittelte Kamelf**** und Inzestzombies sein sollen, die zu keinerlei höheren intellektuellen Leistungen imstande seien... danke für den Tipp! Werde ich mir auf jeden Fall ansehen!

Stellt sich nur die Frage, ob ich die beiden Bücher ohne ein vorheriges Informatikstudium überhaupt verstehe - ich habe hier den "Rembold" stehen, "Einführung in die Informatik für Naturwissenschaftler und Ingenieure" - könnte mir das bei meinem Vorhaben nützen?

Bis bald im Khyberspace!

Yadgar
--
Flagmaker - ein Programmier-Blog
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
22.11.2015, 06:22 Uhr
Hans
Library Walker
(Operator)


Hi,

was die Bücher angeht: Wenn Du mit den Inhalten nicht klar kommst, ist wahrscheinlich eher ein Studium von Algorithmen und Datenstrukturen zu empfehlen, weil es dabei ja um spezielle Algorithmen und Datenstrukturen geht.
Dazu finde ich das Buch "Algorithmen in XXX" von Robert Sedgewick, ganz brauchbar. XXX kann dabei C, C++ oder Java sein. Eine alte Auflage aus den 90er Jahren war auch in Pascal, aber die neueren Auflagen davon behandeln die Themen AFAIK in C++ und/oder Java.
Ein weiteres Buch ist von Thomas H. Cormen und anderen: "Algorithmen - Eine Einführung". Darin hab ich aber nicht viel gelesen, von daher kann ich es nicht wirklich beurteilen.
Schliesslich fällt mir noch der Klassiker zu dem Themenkomplex ein: von Niklas Wirth mit eben dem Titel: "Algorithmen und Datenstrukturen". Der benutzt aber seine selbst entwickelten Programmiersprachen Pascal und Modula, um den Stoff zu demonstrieren. Von C und seinen Verwandten hält er nicht sehr viel.
Ausserdem gibt es noch viele andere Titel zu dem Themenbereich, so dass ich Dich da an die Bibliothek Deines Vertrauens verweisen muss. Denn wie immer bei Computerbüchern: Erst ein Exemplar aus der Bibliothek holen um zu sehen, wie man damit klar kommt. Danach erst kaufen.

Was den Rembold angeht: der ist gut, den hab ich auch im Regal stehen, nützt in diesem Fall aber eher weniger, weil es um ganz spezielle Probleme geht. Wenn Du für Deinen derzeitigen Problembereich noch irgendwas allgemeiner gehaltenes suchst, würde ich eher bei Geografiebüchern gucken, wobei da entweder die allgemeinen Übersichten in Frage kommen oder jene, die sich mit Kartografie und dem drumherum befassen. Oder, von der Grafik-/Bildverarbeitung kommend, entsprechende Titel dazu, etwa "Computergraphik und Bildverarbeitung" von Achim Janser und anderen.

Von mathematischer kommt man von Vektoralgebra und Matrizen früher oder später zu entsprechender Analysis, also Vektoranalysis. Aber da stellt sich dann doch erst mal die Frage, ob man das wirklich braucht. - Du willst ja schliesslich kein Gradnetz eines seltsam geformten Kometen erstellen...

Soweit mal dazu.
Hans
--
Man muss nicht alles wissen, aber man sollte wissen, wo es steht. Zum Beispiel hier: Nachdenkseiten oder Infoportal Globalisierung.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
17.12.2015, 00:49 Uhr
Yadgar



Hi(gh)!

Ich habe mir den [url="http://www.rock-o-data.de/khyberspace/map2hf.cc"]Code[/url] noch einmal angesehen und in verschiedenen Varianten getestet...

Variante 1 - Abtastung nur in Nord-Süd- und Ost-West-Richtung, kein zusätzliches Array für ursprünglich vorhandene (true) und nicht vorhandene (false) Pixel



Ach, was ist das ein elender Murks - ich schaffe es ja nicht einmal, hier einen Link auf meine Codedatei zu posten! Ab mir mir [ZENSIERT] [ZENSIERT], [ZENSIERT] [ZENSIERT] [ZENSIERT] [ZENSIERT] [ZENSIERT] [ZENSIERT] [ZENSIERT] [ZENSIERT] [ZENSIERT] [ZENSIERT]!

[ZENSIERT]!!!!!



Dann pixele ich eben bis ans Ende meiner Tage manuell an meinen Afghanistan-Heightfields weiter, bei 8 Stunden täglich bin ich schon 2098 mit dem ganzen Land in 1:100000 fertig! Toll, was?
--
Flagmaker - ein Programmier-Blog

Dieser Post wurde am 17.12.2015 um 01:17 Uhr von Yadgar editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
007
22.12.2015, 23:08 Uhr
Yadgar



Hi(gh)!

Neuer Post, neues Glück...

Also: hier der Code...

...und hier die Testdatei: aus einer topographischen Karte von Kabul und Umgebung extrahierte Höhenlinien (40-m-Intervall), hier der Speicherplatzersparnis halber als PNG-Datei, muss natürlich vorher nach TGA umgewandelt werden!

Programmlauf 1: Abtastung nur nach Norden und Süden sowie Osten und Westen, keine vorherige Speicherung ursprünglich bereits gesetzter Pixel in einem separaten Array.

Programmlauf 2: Abtastung wie Programmlauf 1, vorher aber Speicherung aller ursprünglich vorhandenen Höhenpixel in einem bool-Array (als true, die übrigen als false), so dass auch beim Abtasten die im Laufe des Abtastprozesses neu gesetzten Pixel nicht berücksichtigt werden.

Programmlauf 3:
Abtastung nach Norden und Süden, Osten und Westen, Nordosten und Südwesten, Südosten und Nordwesten, vorher Speicherung aller ursprünglich vorhandenen Höhenpixel in einem bool-Array.

Programmlauf 4: Abtastung wie Programmlauf 3, aber kein zusätzliches bool-Array.

Programmlauf 5: wie Programmlauf 4, aber zusätzlich noch Abtastung in Richtungen 22,3° und 202,3°.

Hier zum Vergleich das nordöstliche (ungefähr) Viertel der Karte, in 616 Arbeitsstunden von Hand vervollständigt (von Oktober 2004 bis Februar 2007!), die Blauanteile habe ich zur besseren optischen Unterscheidbarkeit der Grünstufen dazugenommen, sie wirken sich nicht auf die Höhenwerte aus...

Mir ist das alles ein Rätsel... was mache ich falsch?

Bis bald im Khyberspace!

Yadgar
--
Flagmaker - ein Programmier-Blog

Dieser Post wurde am 22.12.2015 um 23:39 Uhr von Yadgar editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
008
23.12.2015, 12:04 Uhr
ao

(Operator)


Ich nehme an, mit "was mache ich falsch" ist gemeint "wo kommen die Artefakte her, diese senkrechten und diagonalen Linien".

Tut mir leid, aber ich verstehe nicht, was der Code macht und ich habe nicht die Zeit, mich da durchzuwühlen. Deshalb werde ich den nicht auseinandernehmen und debuggen.

Ich würde dir den Rat geben, mal nachzulesen, nach welchen Algorithmen andere Geo-Informationssysteme solche Bilder aufbereiten. Du bist doch bestimmt nicht der erste, der sowas macht. Diese Sucherei und Mittelung in 8 scharf definierten Richtungen scheint mir suboptimal und nur dann erfolgversprechend, wenn die Geländegestalt bestimmte Eigenschaften hat.

Und ich würde mal einen anderen Ansatz vorschlagen, nämlich aus dem Höhenlinien-Netz ein Gradienten-Netz berechnen (Gradient = Richtung und Betrag der stärksten Steigung bzw. des stärksten Gefälles). Und dabei die Richtung nicht in 45-Grad-Stufen bestimmen, sondern exakt: In welchen Richtungen sind die kürzesten Abstände zur nächsten Höhenlinie oberhalb und unterhalb?

Und wenn du dann noch ausnutzt, dass Niveaulinien und Gradientenlinien in jedem Punkt senkrecht aufeinander stehen (das ist per Definition so), dann müsstest du eigentlich genug Daten zusammenhaben, um das Gelände zu interpolieren.

Zum Interpolieren selber: Kein irgendwie gewichtetes Mittel aus mehreren Himmelsrichtungen, sondern Spline-Interpolation entlang der Gradientenlinien. Das gibt schöne differenzierbare Kurven.

Problematisch sind natürlich immer noch die Randbereiche des Bildes und Kuppen und Senken. Im Randbereich bist du definitiv dann, wenn der nächstliegende Höhenlinienpunkt ein Randpunkt ist. Dann kannst du nämlich nicht wissen, welchen Verlauf die Höhenlinie jenseits des Randes nimmt und ob es dort Höhenlinienpunkte gibt, die noch näher liegen. In diesem Fall ist eine Gradientenbestimmung nicht sinnvoll.

Randbereiche musst du aussparen bzw. mehrere Quellbilder so kombinieren, dass diese Bereiche mitten ins Bild zu liegen kommen. Es wäre also sinnvoll, die Berechnung so zu modifizieren, dass sie nicht immer ein ganzes Bild bearbeitet, sondern dass du den Bereich, der bearbeitet werden soll, spezifizieren kannst.

Bei Kuppen und Senken musst du es irgendwie hinkriegen, dass du Daten über den Gipfel bzw. Sohlenpunkt entweder explizit hinzufügst oder sinnvolle Annahmen darüber machst. Aus dem Gradientenfeld müsstest du zumindest eindeutig sagen können, ob es sich um eine Kuppe oder Senke handelt (steigt oder fällt das Gelände nach innen hin?).

Dieser Post wurde am 23.12.2015 um 12:08 Uhr von ao editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
009
27.12.2015, 14:19 Uhr
Yadgar




Zitat von ao:

Ich würde dir den Rat geben, mal nachzulesen, nach welchen Algorithmen andere Geo-Informationssysteme solche Bilder aufbereiten. Du bist doch bestimmt nicht der erste, der sowas macht. Diese Sucherei und Mittelung in 8 scharf definierten Richtungen scheint mir suboptimal und nur dann erfolgversprechend, wenn die Geländegestalt bestimmte Eigenschaften hat.

Und ich würde mal einen anderen Ansatz vorschlagen, nämlich aus dem Höhenlinien-Netz ein Gradienten-Netz berechnen (Gradient = Richtung und Betrag der stärksten Steigung bzw. des stärksten Gefälles). Und dabei die Richtung nicht in 45-Grad-Stufen bestimmen, sondern exakt: In welchen Richtungen sind die kürzesten Abstände zur nächsten Höhenlinie oberhalb und unterhalb?

Und wenn du dann noch ausnutzt, dass Niveaulinien und Gradientenlinien in jedem Punkt senkrecht aufeinander stehen (das ist per Definition so), dann müsstest du eigentlich genug Daten zusammenhaben, um das Gelände zu interpolieren.

Zum Interpolieren selber: Kein irgendwie gewichtetes Mittel aus mehreren Himmelsrichtungen, sondern Spline-Interpolation entlang der Gradientenlinien. Das gibt schöne differenzierbare Kurven.



Höhere Mathematik... bis ich die verstanden habe, gehen wohl noch ein paar Jahre ins Land! Da hilft wohl nur gründlichstes Selbststudium, erstmal nur die mathematische Theorie, und ich gehe davon aus, dass es dazu schon gedruckte (teure!) Literatur sein muss, sowas liegt wohl kaum einfach so für lau im Internet rum...

Bis bald im Khyberspace!

Yadgar

P. S. Was schaffe ich wohl eher: virtuelles Afghanistan in POV-Ray (oder Blender) mit allem Tschingbumm - oder doch eine Reise (idealerweise per Fahrrad) ins reale Afghanistan, und zwar ohne Taliban, Terror und Tretminen?
--
Flagmaker - ein Programmier-Blog
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 < [ 2 ]     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: