Uni Gruppe

[Gregor]

unigruppe schrieb:

Konkret gings um die Erkennung von Buchstaben in einem Video.

Ok, das ist natürlich eine Aufgabe, bei der es nicht von Anfang an klar ist, wie man sich ihr am Besten nähert. Hört sich nach einem super interessanten Projekt an. Aber nur mal so nebenbei: 1. Warum in einem Video und nicht auf Bildern? 2. Warum Buchstaben und nicht Wörter?

unigruppe schrieb:

Als Vorschläge kamen da alle nur irgendwie erdenklichen Verfahren wie Bildpyramiden, Linienerkennung mit Hough, bis hin zu selbst ausgedachten Algorithmen wie "schauen ob an Stelle x1/y1 ein Pixel ist dann ists wohl ein Z sonst wenn an Stelle x2/y2 ein Pixel ist dass ists eben dies und jenes usw..."
Auf den Hinweis hin dass ein gewisses Rauschen vorhanden sein kann sodass man sich nicht auf einzelne Pixelwerte verlassen kann kamen dann immer nur Hinweise in Form von "Uniprojekt ... da machen wir uns halt perfekte Daten" bis hin zu "ja aber das kann schon funktionieren in diesem Spezialfall...".

Wenn von demjenigen Ideen mit Helligkeits- oder Farbwerten von Pixeln an bestimmten Stellen kamen, dann bin ich auf Deiner Seite. Da würde man keinen robusten Code rauskriegen, sondern nur einen unglaublich tiefen Entscheidungsbaum, der bei genau den Spezialfällen funktioniert, für den man ihn konstruiert hat. Ob Bildpyramiden und Houghtransformationen in dem Zusammenhang Sinn machen, ist aus meiner Sicht hingegen wieder eine andere Frage. Ich kann mir vorstellen, dass sie Teil eines Gesamtalgorithmus sind.

Wenn Du mich fragst, ist das Projekt allerdings durchaus komplex genug, dass man sich im Vorfeld ernsthafte Gedanken machen sollte, wie man es umsetzt. Das beinhaltet auch eine entsprechende Recherche über Ansätze in dem Bereich. Sowohl in Büchern, als auch in wissenschaftlichen Artikeln oder sonstigen Quellen. Ansonsten versucht man halt die Werkzeuge oder Algorithmen irgendwie zusammenzusetzen, mit denen man irgendwann mal in Berührung kam. Ich habe zum Beispiel mal etwas mit Skelettierung gemacht, deshalb würde ich in dem Zusammenhang als erstes ein Schwellwertbild oder ähnliches bauen und fröhlich rumskelettieren. Die Skelette kann man dann schon irgendwie irgendwelchen Buchstaben zuordnen. Andererseits habe ich vor längerer Zeit mal etwas über Fourierdeskriptoren gehört und wollte die immer schon einmal ausprobieren. Mir fallen also auf Anhieb 2 unterschiedliche Möglichkeiten ein, wie ich die relevanten Formen in den Bilddaten auf eine Form bringen könnte, die für eine Buchstabenerkennung eine nützlichere Darstellung liefern würde. Ob eine der Ideen jetzt zu prinzipiellen Problemen führt, sehe ich auf Anhieb nicht und ich denke, man sollte derartige Probleme durchaus im Vorfeld gut durchdiskutieren und auch die möglichen Workarounds um entsprechende Probleme. Jenseits davon wären beide Herangehensweisen sicherlich naiv: Es ist offensichtlich, dass das ein Themengebiet ist, in dem sich schon sehr viele Leute sehr viele Gedanken gemacht haben. Eine wissenschaftliche Arbeitsweise wäre, hier erst einmal zu recherchieren, welche Ansätze diese Leute gefunden haben. Durch so eine Recherche (von der ganzen Gruppe) würde auch ein gemeinsames grundlegendes Wissen entstehen, das für sinnvolle Diskussionen in dem Bereich notwendig ist.

[Xin]

unigruppe schrieb:

bin in einer Übung in einer Gruppenarbeit, im Gegensatz zu den anderen arbeite ich nebenbei als SW Entwickler, während die anderen eher dürftige Kenntnisse in der SW Entwicklung haben.
Soweit kein Problem. Nun haben wir da aber eine Person in der Gruppe, die meint, sie wisse alles besser, leider redet sie ziemlichen Blödsinn. Da haben wir eine Aufgabe XY - und schon sprudeln die Ideen aus ihr nur so raus "mmmh da könnten wir ja Algorithmus XY (Anm.: der allerdings absolut unpassend ist) verwenden". Oder noch besser, wenn die Person mit ihren eigenen, selbstgestrickten Algorithmen ankommt, die noch größerer Unfug sind.

Als ich das Studium begann hatte ich 13 Jahre Programmiererfahrung. Dass ich nicht vollkommen unfähig bin, haben mir Profs zusätzlich zum Diplom bescheinigt, also gehe ich mal davon aus, dass sich die Situation mit meinem Studium vergleichen lässt.

Ich finde solche Leute erstmal interessant.
Man selbst hat schon den Durchblick, weil man über einige Erfahrungen verfügt und weiß wie der Hase läuft und so läuft man eben dem Hasen hinterher, weil man die Erfahrung hat, genau dem Hasen hinterherzulaufen, der einen ans Ziel bringt.

Manchmal übersieht man aber, dass man sich selbst Schienen gebaut hat und gar nicht mehr bereit ist, sich komplett andere Denkansätze anzueignen. Hase voraus, passt schon.

Eine Diskussion kann also durchaus interessant und inspirierend sein, selbst dann, wenn man zum Schluss kommt, dass Du den optimalen Hasen schon kennst. Auch dann, wenn man das dem Gegenüber nicht vermitteln kann, Du hast für Dich in Frage gestellt, ob Du den optimalen Weg hast und konntest das bestätigen.

unigruppe schrieb:

Dann sage ich der Person, nein, so kann das nicht funktionieren. Und dann hat man schon die Diskussion. Ewige Diskussionen, die zu nichts führen.

Eine Diskussion, die zu nichts führt, bedeutet auch, dass die Leute die Möglichkeiten einer inspirierenden Diskussion nicht ausschöpfen. Eine Diskussion kann auch dann fruchtbar sein, ohne dass jemand seine Meinung ändern muss. Außerdem, was genau erwartest Du vom Studium? Ist das nicht mehr als nur ein Stück Papier?
Du studierst. Du sagst, Du hast schon Erfahrung. Warum studierst Du dann?
Das meiste, was ich im Studium gelernt hatte, hatte nichts mit dem Thema zu tun, über das gerade gesprochen wurde. Es waren alternative Denkansätze, Bruchkanten, wo einer einfach mal die selbstgebauten Denk-Schienen verlässt und komplett querschoss. Einfach mal die Erkenntnis, dass man gedanklich auch mal vom Zug abspringen darf und die Frage stellen darf, ob man an der Stelle eigentlich alles so akzeptieren muss, wie einem das vorgekaut wurde oder ob da vielleicht ein paar Stellhebel unbeachtet geblieben sind.
Vielleicht erreicht der Kommilitone ja kein Ergebnis für das jeweilige Problem, aber eventuell inspirieren seine Denkansätze Dich, die Denk-Richtung auf einen anderen Startpunkt zu setzen, so dass Du eine neue Perspektive auf ein anderes Problem erhältst, das Dich mehr interessiert.
Das zumindest waren die größten Erkenntnisse im Studium: Querverbindungen ziehen.

unigruppe schrieb:

Da die anderen noch nicht so erfahren sind wissen sie nicht wirklich wem sie sich anschließen sollen und finden manche Ideen von der Person manchmal ganz gut, obwohl mir ganz klar ist dass die Methoden in der Praxis nicht funktionieren können.

Die anderen respektieren Dich trotz Deiner Erfahrung nicht so sehr, dass sie Dir blind hinterherlaufen und die Nervensäge aus der Gruppe ausschließen?

Notfalls lerne zu erklären, was Dir eigentlich klar ist, wenn Du studierst, was Du liebst. Lerne lehren und lerne Geduld, bis Du lehren kannst.

unigruppe schrieb:

In der Arbeit ist das einfacher. Da ist schnell mal klar wer wenig Ahnung hat und dementsprechend braucht man sich gegen Leute nicht durchsetzen die nur heiße Luft von sich geben.

Stimmt, die werden schnell wegbefördert.

unigruppe schrieb:

Wie vorgehen? Ich bin echt erstaunt über die Unfähigkeit mancher Studenten und mit welcher Sicherheit sie gleichzeitig Müll von sich geben.
Natürlich kann ich das so direkt nicht sagen.

Da war ich deutlicher. Zumindest bei Fächern, die ich weder liebte, noch lehren wollte, sondern die ich eigentlich nur abhaken wollte. Und es gab Fächer, wo ich mir nicht reinreden lassen wollte, die mir wichtig waren.
Bei Studenten, die ich einfach nur mitschleifen sollte, habe ich meine eigene Lerngruppe gebildet, notfalls als Ein-Personen-Gruppe. Das war einfacher und effizienter, als mehreren zu erklären, was ich nun vorhabe und darüber zu diskutieren, ob das eine gute Idee ist.

Dass das, was ich mache nicht möglich ist, haben mir erfahrene Leute auch oft genug erklärt - die Signatur kommt nicht von ungefähr - aber ich habe immer zur versprochenen Zeit geliefert. Auch das habe ich mir schriftlich geben lassen.

Um nicht Standard zu sein, solltest Du Dich mit allem beschäftigen, die nicht Standard sind. Wenn Du nach Gold suchst, ist da viel Dreck dabei, aber Gold beim Juwelier zu finden ist nur Standard.
Wenn so jemand einen falschen Startpunkt für seine Denkrichtung wählt, kann sein Vorgehen für Dich trotzdem Inspiration sein, wenn Du mit seinem Vorgehen, Deine Denk-Schienen durchbrechen kannst und damit Deine Ziele schneller erreichst.
Das wäre doch ein Grund für ein Studium.

Mein Verständnis für Computerhardware hat mal ein 8jähriger massiv erweitert, der auf ein Mainboard sah und darin einen Stadtplan entdeckte mit Straßen, Häusern, Wassertürmen und Fabrikhallen. Hatte ich nie gesehen, ich wusste ja, wie's funktioniert.

Entscheide, wo Du inspiriert werden möchtest, wo Du inspirieren möchtest und wo Du einfach nur in Ruhe dein Ding durchziehen willst. In einer Lerngruppe solltest Du nicht nur Dein Ding durchziehen, sondern auch der Gruppe zuliebe Dich der Diskussion stellen. Und wenn Du sie nicht brauchst und auch nicht willst, dass sie Dir widerspricht, dann mach Deinen Kram alleine.

Edit: Zu einigen der komischen Leute aus dem Studium habe ich noch gelegentlichen Kontakt. Kürzlich rief einer zu meinem Geburtstag an und lud mich ein. Er konstruiert jetzt Weltraum-Satelitten. Kein Standard-Job. Der Kontakt zu den Standard-Leuten ist größtenteils eingeschlafen. Mit denen kann man sich ja nur über Dinge unterhalten, die man auch in Büchern lesen kann.
Vielleicht gibst Du Deinem Querdenker auch noch ein paar Chancen, Dich zu inspirieren.

[cooky451]

volkard schrieb:

Du wirst die Arbeit für alle Teilgruppen machen, das ist nämlich einfacher, als ihnen alles beizubringen, was auch halt nicht Dein Job ist.

Jap, das ist mehr oder weniger was ich in allen Software/Programmier-Fächern mit Gruppenarbeiten mache. Die Gruppenarbeit einfach alleine zu machen spart Zeit, ist weniger stressig, und gibt am Ende eine bessere Note weil alles einheitlich ist und keine Bugs hat.

[n3wbie]

cooky451 schrieb:

volkard schrieb:

Du wirst die Arbeit für alle Teilgruppen machen, das ist nämlich einfacher, als ihnen alles beizubringen, was auch halt nicht Dein Job ist.

Jap, das ist mehr oder weniger was ich in allen Software/Programmier-Fächern mit Gruppenarbeiten mache. Die Gruppenarbeit einfach alleine zu machen spart Zeit, ist weniger stressig, und gibt am Ende eine bessere Note weil alles einheitlich ist und keine Bugs hat

Mit der Denkweise wirst du noch früh genug fallen. Wenn du mal mit 100 Entwicklern an einem Projekt arbeitest, dann bist du auf einmal überfordert, weil du es nie gelernt hast. Wenn du mal mit 2 Mitarbeitern in einem Kraftakt ein Projekt was normal 2 Wochen dauern würde in einer Schaffen sollst, dann läufst du auf.
Wenn dann auch noch Entwickler aus anderen Ländern kommen wird es noch mal komplizierter.
Teamwork ist nicht zu unterschätzen. Bei mir ist das runtertippen von Code geschätzt weniger als 1/3 der Arbeitszeit, vielleicht sogar nur 1/4 bis 1/5.

Bevor jetzt wieder einige schreien wie dämlich das ist, und dass es auch kleine Firmen gibt - ja das ist nicht allgemeingültig.

Auch ist das nicht speziell auf dich bezogen. Es betrifft alle, die der Meinung sind, Alleingang ist besser als Konfliktlösung.

Xin schrieb:

Eine Diskussion kann also durchaus interessant und inspirierend sein, selbst dann, wenn man zum Schluss kommt, dass Du den optimalen Hasen schon kennst. Auch dann, wenn man das dem Gegenüber nicht vermitteln kann, Du hast für Dich in Frage gestellt, ob Du den optimalen Weg hast und konntest das bestätigen.

Da möchte ich voll und ganz zustimmen. Nur weil man etwas schon immer gemacht hat, heißt es nicht, dass man es immer richtig/perfekt gemacht hat.

Xin schrieb:

Dass das, was ich mache nicht möglich ist, haben mir erfahrene Leute auch oft genug erklärt - die Signatur kommt nicht von ungefähr [...]

Das kenne ich auch sehr gut. Alle sagen immer "Das geht nicht". Und dann kam einer, der wusste das nicht, und hat es einfach gemacht. Auch ich ertappe mich oft dabei zu sagen "Das geht nicht" oder "Das ist doof" weil ich meine oft verwandte Lösung kenne, und deren Vorteile für meinen Code.

[volkard]

n3wbie schrieb:

Bla bla … mit 100 Entwicklern … Teamwork ist nicht zu unterschätzen.

Im Unternehmen können die anderen zum Programmieren Eingeteilten aber auch proggern, und wenns noch so wenig wäre, das ist der Unterschied, das ist ein gewaltiger Unterschied. Im Uni-Projekt kommen Zusammensetzungen vor, wo man echt allein ist. Wir reden hier davon, daß man alleine wirklich viel schneller ist und daß *keine* hilfreichen Ideen zum Programm zu erwarten sind.
Freu Dich einfach, daß Du es noch nicht erleben mußtest (oder von einem Profi durchgeschleppt wurdest).
Als ich dran war, gab es in der Gruppe noch einen zweiten guten Progger und natürlich haben wir beiden im Team gearbeitet. Macht viel mehr Spaß, man inspiriert sich gegenseitig und so.
Und bis auf zwei hatten alle anderen auch sinnvolle Tätigkeiten gefunden, Grafiken, Sound, Webseite,…
unigruppe wird sich auch mächtig freuen, daß Teammitglieder für ordentliche Testdaten und Testhardware sorgen, ein Handbuch und Onlinehilfe schreiben, den Prof belabern, wie gut das Produkt ist, und es wird schon allerhand tolle Sachen geben, die dem Team einfallen, und die auch gleich angepackt werden können (weil vom Proggern entlastet). Aber vom Code dürfen sie die Finger lassen, das wäre ein feiner Zug. Und der Prof muss gar nicht so genau wissen, wer was machte.

edit: "Schrifterkennung in Videobildern. Diplomarbeit" epb.bibl.fh-koeln.de/files/185/Naether_Axel.pdf

[Mechanics]

War in meiner Projektgrupper auch so ähnlich, nur nicht auf einem so hohem Niveau. War schon ein umfangreiches Projekt, nichts mit selber machen. Waren (fast) alle auch gar nicht mal so schlecht. Aber wo es am Anfang um die allgemeine Architektur ging, hat es mich voll genervt. Ich hatte gleich eine Vorstellung, wie man das machen könnte. Vielleicht nicht die beste Vorstellung und nicht die einzige, aber eine ganz brauchbare. Kommt aber jeder daher, der nur "programmieren" gelernt hat und noch null Ahnung von Softwarearchitektur hat mit irgendwelchen Ideen und Kleinigkeiten daher...
Eine nützliche Erfahrung ist sowas aber schon, da muss ich n3wbie durchaus Recht geben. Auch in der Arbeit bin ich mit den Kollegen nicht immer einer Meinung, irgendwie muss man sich mit sowas arrangieren.

Bei deinem konkreten Problem hast du jetzt aber auch keine eigenen Vorschläge gebracht. Ich hätte keine Ahnung, wie ich sowas angehen würde (würde ich wohl nicht). Pixel an Position x/y prüfen ist natürlich Quatsch. Bildpyramiden und Hough Transformation hört sich aber schon nicht verkehrt an, da würde ich nicht ausschließen, dass man damit was erreichen könnte. Zumindest könnte das Teil der Lösung sein, vielleicht mit irgendwelchen Vorverarbeitungsschritten. Ich gehe aber fest davon aus, dass es hier auch geeignetere/besser untersuchte Methoden gibt.
Da müsste man viel mehr recherchieren. Schafft man aber nicht unbedingt. Wir recherchieren ziemlich viel in der Arbeit, jahrelang. Da werden zu bestimmten Themen zig Papers, Diplom- und Doktorarbeiten gelesen. Muss man aber alles ausprobieren. Viele der Papers sind meist noch weit von der Realität entfernt. Und mit den eigenen Daten und Eigenheiten stellt sich dann vielleicht raus, dass die Ansätze gar nicht passen.
Was wäre also dein Vorschlag, der sicher funktionieren würde?

[mutant]

Alleine ist man beim Programmieren meistens schneller als im Team. Leider wissen das die Chefs nicht.

[Marthog]

n3wbie schrieb:

Mit der Denkweise wirst du noch früh genug fallen. Wenn du mal mit 100 Entwicklern an einem Projekt arbeitest, dann bist du auf einmal überfordert, weil du es nie gelernt hast. Wenn du mal mit 2 Mitarbeitern in einem Kraftakt ein Projekt was normal 2 Wochen dauern würde in einer Schaffen sollst, dann läufst du auf.

Es geht an der Uni nicht anders. Nach regulaerem, empfohlenem Plan hat man bei uns eine grosse Projektarbeit im 4. Semester. Bis dahin hat man aber lediglich die Vorlesungen "Programmieren" und "Algorithmen und Datenstrukturen". Die Programmierenklausur besteht hauptsachlich aus Umrechnen in Binaerzahlen, damit rechnen (z.b. binaere Multiplikation), Syntaxfehler in Java-code finden und ein paar allgemeine Fragen zu Java beantworten und zu einem UML-Diagram die Klassen und Funktionssignaturen aufschreiben.
In AuD musste man kaum selber programmieren, sondern hauptsaechlich per Hand bestimmte, auswendig lernbare Such- und Sortieralgorithmen anwenden, per Hand Suchbaeume zeichnen und eine Laufzeitabschaetzung machen.
Wenn man dann in der Vorlesung nicht viel aufpasst, nur das noetigste macht und gerade so durch die Pruefungen kommt, kann man ausser der Syntax und ein paar vorgegebene Algorithmen kaum etwas. Das Hauptproblem ist eh der Ansatz, wie man reale Probleme in Code umsetzt und danach vernuenftiges Projektmanagement. Wenn man von beidem kaum etwas kann und erst recht keine praktische Erfahrung hat, dann wird das nichts. Dann ist der Aufwand, den anderen zu erklaeren, was man da gerade macht, bestimmt doppelt oder dreifach so gross, wie den Code selbst zu schreiben. Zudem muss man auch als Programmierer selber ein bisschen herumprobieren und wenn dann immer einer fragt, was man da macht, kommt man zu gar nichts.

[Gast]

Manchmal ist es gut, wenn man so etwas wie einen Projektleiter hat. Der am Ende des Tages entscheidet, wohin die Reise gehen soll. Man kann zwar diskutieren, aber irgendwann muss man auch mal eine Entscheidung treffen. Und wenn ihr mit der Diskussion nicht zu einer Entscheidung kommt, dann hilft meistens eine Entscheidung von Außen.

Falls ihr einen Projektleiter habt: 30 Minuten in der Gruppe diskutieren und dann abstimmen. Bei der Abstimmung so Konkret wir möglich sein. Z.b. "Implementieren wie Algorithmus A oder B?"

[volkard]

ProgChild schrieb:

Manchmal ist es gut, wenn man so etwas wie einen Projektleiter hat.

Immer ist es gut!
Naja, manchmal nicht, aber daß man einen Prof84 https://www.google.de/search?q=prof84+site%3Awww.c-plusplus.net über sich hat, ist ja selten.

ProgChild schrieb:

Der am Ende des Tages entscheidet, wohin die Reise gehen soll. Man kann zwar diskutieren, aber irgendwann muss man auch mal eine Entscheidung treffen. Und wenn ihr mit der Diskussion nicht zu einer Entscheidung kommt, dann hilft meistens eine Entscheidung von Außen.

Oder würfeln. Alle sechs Wege könnten gehen. Zwei davon gehen wirklich. Man kanns nu nicht schon wissen. Also ja, der RedProgger weiß es, aber dem glaubt ja keiner. Das ist er gewohnt. Also Abstimmung oder Chefentscheidung STATT RUMWARTEN. Dann kann und wird man noch sehen, daß ein anderer Weg besser gewesen wäre und je besser man getroffen hat und je früher man den Fehlweg sieht, desto billiger wirds (oder bei gegebener Zeit wie hier deste besser wirds).

ProgChild schrieb:

Falls ihr einen Projektleiter habt: 30 Minuten in der Gruppe diskutieren und dann abstimmen. Bei der Abstimmung so Konkret wir möglich sein. Z.b. "Implementieren wie Algorithmus A oder B?"

Der Projektleiter wäre der TO oder die Person, habe ich das Gefühl, und man hat sich noch nicht drauf geeinigt. Der TO würde sofort jeden Anspruch droppen, wenn die Person sich aus der inneren Technik raushalten würde, nehme ich an.