Laden...

Bildverarbeitung vielleicht doch in F#

Erstellt von EFK381 vor 13 Jahren Letzter Beitrag vor 13 Jahren 3.395 Views
E
EFK381 Themenstarter:in
92 Beiträge seit 2008
vor 13 Jahren
Bildverarbeitung vielleicht doch in F#

Hallo Leute!
Ich rätsel mal wieder ein bisschen an meinem neuen Projekt herum. Für eine Anwendung (und später vielleicht weitere) brauch ich ein kleines "Framework" mit einfachen Filtern zur Bildverarbeitung.

Die Projekte hier im Forum und auch zommi's klasse Idee hab ich gelesen, soweit alles gut. Nur ein Gedanke kreist mir noch im Hinterkopf herum: Überall liest man von Filtern als Funktion die Pixelwerte auf neue Werte abbilden etc. Vor allem in Büchern und an der Hochschule wird das Thema anscheinend gern derart formalisiert eingeführt. WENN sich Bildfilter so schön mathematisch formalisieren lassen, schreit das nicht nach einer funktionalen Sprache? Darum die Frage: wie siehts aus in F# mit Bildverarbeitung?

Hier im Forum gibts schon Vorteile von F# für mathematische Probleme, und JAck30lena schreibt mit Verweis auf inlining von besserer Performance...

Was mich irritiert (und warum ich eine F#-Frage HIER stelle): Warum taucht dieser Gedanke in all den anderen Diskussionen zur Bildverarbeitung nicht auf? Mache ich mir da was vor und der "Gewinn" insbesondere in Bezug auf Laufzeit ist garnicht da?

Zudem soll das entstandene Framework später natürlich in einer in C# geschriebenen Applikation seine Dienste tun, hat jemand ein paar Tips und Erfahrungen wie das dann genau mit der Sprachmischung abläuft? Vermutlich werd ich vom C#-Code nur auf die kompilierten F# Assemblies zugreifen können oder?

Vielen Dank für eure Hilfe!

1.361 Beiträge seit 2007
vor 13 Jahren

Hi EFK381,

ich selbst fange gerade erst an, etwas F# zu lernen.
C# war bisher general-purpose genug, damit ich nicht ausweichen musste.

Du hast schon recht mit deiner formalen Betrachtungsweise. Die ganze Filter-Theorie ist stark funktional. Aber deshalb würde ich nicht unbedingt alles funktional programmieren.
So wie manche Kompilerbauer sagen, dass jedes sinnvolle Programm nur ein Compiler ist - dennoch strukturier ich meine Programm nicht immer in Lexer, Parser, etc...

So, genug zum allgemeinen Gebrabbel 🙂

WENN sich Bildfilter so schön mathematisch formalisieren lassen, schreit das nicht nach einer funktionalen Sprache? Darum die Frage: wie siehts aus in F# mit Bildverarbeitung?

Wie du sagst, ist _ein _Bildfilter mit _einer _Funktion gleichzusetzen. Ein Invertier, Kontrasterhöher, etc... das sollte alles eine "funktionale Einheit" sein. Eingabebild, Ausgabebild, Seiteneffektfrei.
Aber diese abstrakte Sichtweise sagt nichts aus, wie diese "funktionalen Einheiten" intern arbeiten. Daher "schreit" die Implementierung meiner Meinung nach nicht soo sehr nach funktional. Auf der abstrakteren API-Ebene schon! Aber nicht darunter in der Implementierung.

Hier im Forum gibts schon das, und JAck30lena schreibt mit Verweis auf inlining von besserer Performance... Ich selbst bin ja auf der Suche nach möglichst performanten Bildverarbeitungs-Implementierung auf .NET-Basis. Für eine komfortable F#-Umsetzung fehlt es meines Wissens an den grundlegenden Datenstrukturen um effizient mit Bildern zu arbeiten. Man müsste also auch dort ordentlich Aufwand treiben.

Aber so wie die "simple" C#-Implementierung eines solchen Bildfilters nicht sonderlich schnell ist und viel Verbesserungspotential hat, so wird das bei F# auch sein. Nur dass dort wohl _andere _Probleme auftreten.

Aber wenn du dir mal Gedanken über eine F#-Implementierung machen willst - sehr gern! Mich würde das wirklich interessieren. 👍

Warum taucht dieser Gedanke in all den anderen Diskussionen zur Bildverarbeitung nicht auf? C# erzeugt IL-Code. F# erzeugt IL-Code. Mit dem richtigen Know-how wird man wohl (fast immer, bis auf TailRecursion und solche sachen) ein äquivalentes Programm schreiben können.
Da also C# fast so mächtig ist, wie IL selbst, gab es keinen Grund für mich, etwas anderes zu nehmen - mit allem anderen kann ich ja auch nicht mehr erreichen - nur der Weg wäre ein anderer - vielleicht ja ein besserer? Das vermag ich leider nicht zu sagen.

Mache ich mir da was vor und der "Gewinn" insbesondere in Bezug auf Laufzeit ist garnicht da?

Wie ich schon eben mit der IL-Gleich-Mächtigkeit angedeutet hab, bezweifle ich, dass es Probleme gibt, deren effizienteste F#-Implementierung schneller ist als die effizienteste C#-Implementierung !
(Zu sagen, welche dieser höchsteffizienten Lösungen einfacher zu finden ist und besser zu verstehen, wage ich bewusst nicht. Dafür habe ich zu wenig F#-Erfahrung)
Aber F# ist nicht pauschal performanter. Nur wird man bei passenden Problemen eventuell leichter zu einer performanten Lösung finden. Nun ist die große Frage: Gehört die Implementierung von Bildverarbeitungs-Filtern zu diesen passenden Problemen?

beste Grüße
zommi

E
EFK381 Themenstarter:in
92 Beiträge seit 2008
vor 13 Jahren

Danke für die ausführliche Antwort, auf soetwas hatte ich gehofft!

Wenn Du schon schreibst dass Du meinst Du seist Dir zu unsicher in F# um das anzugehen, dann sollte ich wohl erst recht die Finger davon lassen. 😉
Ich habe nämlich noch garkeine Kenntnisse in F# (jetzt mal abgesehen von ein bisschen rumspielen) und funktionale Entwicklung hab ich nur mal nen Semester in der Uni gehabt - Lisp...

Tja und mit meinen .NET Kenntnissen und dem Wissen über IL und Codeoptimierungen etc. stehe ich erst recht weit hinter dem was Du (zommi) so treibst... Eigentlich lautet die Frage also eher was ich als nächstes LERNEN möchte - weiter C# vertiefen und dabei in die von Dir und den angesprochenen Threads thematisierten Punkte der optimierung einarbeiten oder dazu noch F# neu lernen und darauf hoffen dass der Optimierungsteil (und der Einstieg) sich dadurch etwas leichter gestaltet...

Ich glaube es wird letzterer Ansatz, weil ich einfach F# lernen will. Ich halt Dich also auf dem laufenden zommi (wobei ich glaube dass es ne Weile dauert bis ich was gebaut habe was für Dich neu und Interessant sein könnte.)

Aber zum zweiten Teil - hat jemand Erfahrungen mit Entwicklungen in unterschiedlichen .NET Sprachen?

5.657 Beiträge seit 2006
vor 13 Jahren

Ich halt Dich also auf dem laufenden zommi (wobei ich glaube dass es ne Weile dauert bis ich was gebaut habe was für Dich neu und Interessant sein könnte.)

Das würde mich aber auch interessieren...!

Aber zum zweiten Teil - hat jemand Erfahrungen mit Entwicklungen in unterschiedlichen .NET Sprachen?

Eigentlich kein Problem. Man kann in einer Projektmappe mehrere Projekte in unterschiedlichen Sprachen einbinden, und ganz normal auf die Assemblys zugreifen. Das einzige, worauf man achten soll ist, daß man für öffentliche Member nur CLR-kompatible Datentypen verwendet. Besonders bei VisualBasic muß man da aufpassen, mit F# hab ich noch keine Erfahrungen gemacht.

Weeks of programming can save you hours of planning

E
EFK381 Themenstarter:in
92 Beiträge seit 2008
vor 13 Jahren

OK, dann mache ich mich jetzt einfach mal ans Werk! Ein Buch ist bestellt und hoffentlich morgen da und los geht's!

Da ich leider nur in meiner Freizeit entwickle wirds aber tatsächlich ein bisserl dauern bis ich was hab - ich sag Bescheid!
Wobei, ich werde dann ja nur von F# sprechen, kann ich das hier überhaupt berichten ohne verprügelt zu werden? Herbiv...? 😉

DANKE ihr beiden!

A
69 Beiträge seit 2010
vor 13 Jahren

Hier im Forum gibts schon das, und JAck30lena schreibt mit Verweis auf inlining von besserer Performance...

Das gilt vor allem für rekursive Methoden. Desto mehr Rekursion, desto größer der Gewinn.

Nur ist es bei der Bildverarbeitung eher selten der Fall, das man Pixelweise oder Blockweise rekursiv arbeitet, da eine Lineare vorgehensweise perfomanter ist. z.b. weil man durch die 2d Ausdehung bei z.b. Füllalgorithmen prinzipbedingt keinen Pixel doppelt bearbeitet. Klar kann man eine Liste der besuchten Pixel mitschleppen aber dann kann man gleich einen linearen Algorithmus verwenden. Außerdem ist der ständige Check, ob Pixel xy bereits besucht wurde performancefressender als die gleiche lineare Vorgehensweise, wo prinzipbedingt die abgelaufenen Pixel nicht nochmals überprüft werden müssen.

Eine bereits umfangreiche und schnelle Lib in C# gibt es hier: LowLevelGraphicsLibrary

Das einzige, worauf man achten soll ist, daß man für öffentliche Member nur CLR-kompatible Datentypen verwendet.

CLR kompatibel sind prinzipiell alle Datentypen. Egal ob C# F# VB.NET... sonst könnte man sie ja nicht verwenden. Ich vermute daher das du CLS-Complient meinst.

F# hat da ein paar Datentypen, die das meines wissens nicht sind. Aber das merkt man schnell, wenn man in der Assemblyinfo das entsprechende Attribut setzt. Dann meckert der Kompiler sofort.

Was dein Vorhaben betrifft, so wirst du dich bei einer Grafiklib in ein für C# untypisches Gebiet vorwagen müssen, wenn du perfomant sein möchtest: Pointer

Schau dir die oben verlinkte Lib an 😉

edit:

C# erzeugt IL-Code. F# erzeugt IL-Code. Mit dem richtigen Know-how wird man wohl (fast immer, bis auf TailRecursion und solche sachen) ein äquivalentes Programm schreiben können.

Der .NET x64 Jitter macht TailRecursion auch für C# MSIL.

E
EFK381 Themenstarter:in
92 Beiträge seit 2008
vor 13 Jahren

Hallo Arithmetika,
danke für die Hinweise! Die verlinkte LowLevelGraphicsLibrary kenne ich, an der kommt man ja nicht vorbei wenn man hier im Forum nach dem Thema sucht.
Wie ich oben geschrieben hab geht es mir aber irgendwie auch ein bisschen um das Lernen von F#.

Mit Pointern hab ich natürlich bisher noch nicht sooo viel zu tun gehabt (warum auch in .NET) aber da ich in C# auch schon den ein oder anderen Bildanalysecode geschrieben hab, musste ich zumindest schon so viel damit hantieren dass ich da eher weniger Probleme erwarte.

aber es gibt wohl genug andere Fragen die mich noch heimsuchen werden, da wende ich mich dann wieder an euch wenn ich nicht weiter weiß! 😉

5.657 Beiträge seit 2006
vor 13 Jahren

Ich vermute daher das du CLS-Complient meinst.

Genau, danke für den Hinweis!

Weeks of programming can save you hours of planning