Farbanalyse

Hallo,

ich war hier dieses Jahr weit weniger aktiv als ich es mir vorgenommen hatte, und sicher auch als es gut gewesen wäre.

Das hat ein paar Gründe, und keinen richtig Schönen. Das Hauptproblem ist einfach "Zeit". 8 Stunden Arbeitszeit plus X, plus 1 Stunde Pause, plus meist so zwischen 2 und 3 Stunden unterwegs (unter 2 Stunden geht es äußerst selten) - danach geht nicht mehr viel, zumal Staus unheimlich anstrengend sind.

Dann steht erst mal abschalten an. Na gut, das könnte ich im Forum, aber wenn ich mich erst mal daran setze, fallen mir gleich die 2 bis 3 größeren Baustellen ein, um die ich mich kümmern müsste, und die mit Abschalten völlig inkompatibel sind. Und die Sachen wurmen mich zu sehr, als dass ich sie ignorieren könnte

Ich denke, der Zustand wird sich ändern. Ich hoffe zum Besseren.

---

Sonst hatte ich mir für jedes Jahr vorgenommen, bestimmte Änderungen am Forum zu machen. Oft passte das, manchmal nicht. Für 2016 hatte ich nichts, was einerseits realistisch, andererseits auch etwas unbefriedigend war (es ist allerdings noch unbefriedigender, wenn man nur halb fertig wird).

Für 2017 habe ich habe ich noch keine fertige Liste, aber viele Ideen - das ist schon mal ein Fortschritt.

Ein guter Anfang wäre vermutlich, das ganze Ajax-Gehampel mal neu zu machen. Es wäre viel gewonnen, wenn Fehlermeldungen zuverlässig da ankommen, wo ich sie haben möchte, und nicht irgendwo unter gehen, wo ich nicht mal eine Chance hatte, einen Blick darauf zu werfen - oder Du.

Ganz grundsätzlich finde ich den Umgang mit Fehlermeldungen in der modernen EDV eher unbefriedigend. Damit meine ich nicht nur die Frage, ob und wie man dem Benutzer Fehlermeldungen präsentiert, die möglicherweise in der falschen Sprache kommen und ohnehin schwer verständlich sind, wenn man nicht weiß, was los ist (wobei ich ja lieber eine Fehlermeldung in chinesisch (ich kann kein Chinesisch) hätte als gar keine - google hilft auch bei Chinesisch mittlerweile). Nein, in erster Linie geht es mir um darum, dass Fehlermeldungen überhaupt ankommen, und in zweiter Linie darum, dass ich sie der richtigen Ursache zuordnen kann.

Der Javascript-Code im Forum ist, wenn ich ehrlich bin, gerade mal in der Hälfte der Fälle in der Lage, Fehlermeldungen sinnvoll durchzureichen (zum Glück in den häufiger auftretenden Fällen). Das sind zu einem Drittel die benutzten Libraries schuld, die teilweise sehr "optimistisch" programmiert wurden ("hier wird schon nichts passieren"), ein anderes Drittel schiebe ich auf Dokumentationsprobleme (wenn man nicht nachlesen kann, _wie_ ein Fehler gemeldet wird, ist es schwer, den sauber abzufangen), und das letzte Drittel nehme ich auf meine Kappe - unter anderem bin ich einfach zu blöde, in einer Kette von promises Fehler korrekt zu handhaben (ich vertrete übrigens die Minderheitsmeinung, dass promises für alles gemacht worden sind, nur nicht für Fehlerbehandlung).

Ein weiteres Ziel? Vielleicht den BBCode-Krempel zu entsorgen. Wenn ich mich im nächsten Adventskalendertürchen nicht wieder damit herum schlagen müsste, wäre schon viel gewonnen.

BBCode war ganz nett, zu der entsprechenden Zeit - und als einfache Textauszeichnungssprache ist es auch weiter tauglich. Nur sobald man etwas Komplizierteres tun will (wie ich gerade jetzt), wird es hässlich. Na gut, es ist nicht _so_ schlimm. Oder besser, es wäre nicht so schlimm, wenn denn das Ganze einer inneren Logik folgen würde. Aber mittlerweile ist hier die dritte BBCode-Engine am Werk, und alle drei haben leicht unterschiedliche Ideen davon, wie man bestimmte Konstrukte in HTML umsetzt - was dafür sorgt, dass alte, mittelalte und neuere Texte mit denselben BBCode-Konstrukten darin jeweils anders angezeigt werden.

Den Schaden habe ich bisher mit etwas CSS und viel Gefrickel in PHP minimiert, aber da mir der Zustand der verwendeten BBCode-Library nicht gefällt (die wird, um es mit einem griffigen Wort zu sagen, saumäßig gepflegt), wird da mittelfristig ein Ersatz fällig - und damit kommt vermutlich der vierte BBCode-Interpreter, der wieder andere Ideen davon hat, an welcher Stelle Abstände zu sein haben, und welche Elemente als Block-Level-HTML umgesetzt werden, und welche als Inlines.

An der Stelle wäre ein sauberer Neuanfang nett.

Nachtrag: Wann die derzeitig verwendete Engine Leerzeilen ein baut, gehorcht keiner Logik, die ich entdecken kann.

Eine der Baustellen betrifft zwei Zusatzfunktionen, "FX" (direkt unter dem Bild zu finden) und "erweiterter Bildupload". Beide haben gemeinsam, dass sie WebGL nutzen.
WebGL bietet Bildmanipulation direkt im Browser (und noch mehr), und ist eigentlich eine gute Idee. Aber leider nur eigentlich. An und für sich ist WebGL nicht mehr als eine Schnittstelle zum sowieso überall verfügbaren OpenGL, und _sollte_ demnach überall verfügbar sein (sogar auf Smartphones und Tablets).
Nun ja, theoretisch ist es auf 90% der Browser verfügbar. Praktisch?

Praktisch ziehen wir mal von 90% so ungefähr 40% ab, weil auf den Computern die passenden Treiber nicht installiert sind (und auf den Android-Geräten schon gar nicht), und kommen auf realistischere 50%. Damit könnte ich leben, zumal da keine wirklich lebenswichtigen Funktionen dran hängen.

Weit weniger gefällt mir, dass oft WebGL verfügbar ist, aber die Resultate unbefriedigend sind. Mit den Fällen, in denen die Schärfe nach dem Verkleinern nicht "stimmt", konnte ich noch ganz gut leben - zu zwei Dritteln lag es einfach daran, dass der Benutzer das Nachschärfen großzügig übersprungen hat - oder die Kompressionsqualität zu schlecht wählte. Das andere Drittel konnte ich mir nie erklären, zumal die betroffenen Benutzer oft selbst feststellen, dass es mal klappte, und mal nicht. Das schiebt man dann als Entwickler gerne auf die Benutzer. "Kann ich nicht nachvollziehen, kann eigentlich auch nicht sein, muss am Benutzer liegen." Das sollte ich noch mal überdenken.

Aber in den letzten Monaten kamen noch andere Probleme.

• Bei einigen Leuten funktionierte WebGL, und dann plötzlich nicht mehr - um nach ein paar Tagen oder dem nächsten Reboot wieder zu funktionieren. Das hab' ich eine Weile auf die Programmierung des Forums geschoben, schon weil die Betroffenen solche Probleme nur im Forum hatten, aber das lag einfach daran, dass sie WebGL nur im Kontext des Forums nutzen. Das Phänomen tritt auch auf, wenn einer der Betroffenen ein Weile WebGL-Demos laufen lässt.
• Kennt jemand diese Fehlermeldung: ".Offscreen-For-WebGL-0x559da80578a0]GL ERROR :GL_INVALID_OPERATION : glReadPixels: format and type incompatible with the current read framebuffer"? Nein?
  
  Die muss man auch nicht kennen. Die sagt einfach, dass die glReadPixels-Funktion sich weigert, die Bilddaten auszulesen. Warum? Format und Typ sind inkompatibel mit dem Ziel der Operation. Warum? Keine Ahnung. Sollte ich das wissen? Vielleicht, aber wie? Anhand dieses traurigen Versuches einer Fehlermeldung?
  
  Der Code hat Jahre funktioniert. Seit ein paar Wochen oder Monaten tut er es nicht mehr. Nebenbei bemerkt: RGBA, UNSIGNED_BYTE, Uint8Array - da sollte INVALID_OPERATION laut Dokumentation gar nicht vorkommen können.
  
  Das passiert übrigens nicht bei jedem Browser, speziell nicht bei jedem Firefox 50. Reproduzierbarkeit wäre schön.
  
  Update: Das ist wohl etwas, was sich mit Ubuntu 16.10 eingeschlichen hat (laut Ingo [aber ich hab' auch Meldungen, dass das unter Windows auch vor käme]).
• Eine ganz andere Sache ist die Bildqualität. Die ist _teilweise_ wirklich gut. Aber eben nicht überall.
  
  Das habe ich lange auf Treiberprobleme geschoben. Aber leider war es das nicht - mein Chrome hier erzeugt, neben normalerweise recht guten Verkleinerungen, richtig üblen Schrott, wenn ich ihm ein hoch skaliertes Bild hinwerfe (80 Megapixel) - oder ein (künstlich) verrauschtes Bild. Wobei das große Bild vom nächsten Browser dann sauber verarbeitet wurde.

Eine viel zu lange Zeit habe ich gehofft, dass die Verfügbarkeit größer würde - aber das ist nicht passiert. Darauf zu hoffen, dass die Probleme irgendwann noch mal gelöst werden, sollte ich besser nicht versuchen (zumal der Fokus bei der Entwicklung wohl auf WebGL 2 liegt, und an Version 1 nichts mehr gemacht wird).
Für FX ist mir das im Moment egal - aber der erweiterte Upload kann so nicht bleiben. Aber bleiben muss er, so viel ist auch klar.

WebGL? Davon kann ich nur von abraten.

Randnotiz: mittlerweile gibt es halbwegs vernünftig aussehende Javascript-Libraries, die man statt dessen verwenden könnte (caman beispielsweise). 2017…

Oh, liebe WebGL-Entwickler, eines muss ich noch los werden: eure Version 2.0 kann so gut werden, wie sie will, aber die Erfahrungen mit Version 1 wird dafür sorgen, dass ich die Finger von WebGL lasse, bis ich vom Gegenteil überzeugt werde.

Und noch eine Randnotiz, diesmal an die lieben Entwickler von Webbrowsern: Im Laufe der letzten 10 Jahre haben Ingo und ich 22 Bugreports für eure Produkte geschrieben. Zugegeben, dass waren keine großen Sicherheitslücken, sondern meist Features, die in grenzwertigen Fällen nicht vernünftig (oder auch gar nicht) funktionierten. 21 davon sind noch offen - oder zwar im Bugreport-System geschlossen, aber eindeutig immer noch nicht gelöst. Vielleicht guckt ihr euch mal bei den PHP-Leuten ab, wie man das _noch_ schlechter machen kann ("Ja, das ist ein Fehler. Aber keiner, den wir, nachdem wir das jetzt ein Jahr liegen lassen haben, noch für das nächste Release flicken werden. Ich schließe den Bug jetzt mal. Wenn es immer noch wichtig ist, schreib' einen neuen Bugreport". Ja, danke. Vielen Dank. Ich mag euch auch. NICHT. Schlimmer waren nur noch die Leute, die bei Python für das Gemurkse mit Datenbankschnittstellen zuständig waren - aber die Geschichte kann ich nicht erzählen, ohne mich zu übergeben. Kurzform: "Oh, wir unterschlagen Fehlermeldungen? Nein, wir optimieren Rückmeldungen.").

---

Vielleicht noch etwas zur Forumstechnik: Ich habe dieses Jahr, mal wieder, den Server gewechselt (der Alte war wieder zwei Jahre alt, und ich werde Hardware gerne los, bevor sie ihr Alter durch Ausfälle unter Beweis stellt - ok, das gilt so nur für's Forum, meine Maschinen zuhause dürfen ruhig alt werden, da ärgere ich mich im Zweifelsfall ja nur selbst).

Seitdem sind die Performanceprobleme, na ja, nicht ganz weg, aber weit weniger spürbar. Ich verstehe nur nicht richtig, warum das so ist. Aber beschweren will ich mich nicht

---

Ein kleiner Einschub: Meine Suche nach einer Bilddatenbank geht weiter.
Ich hab' einen halbgaren, nicht ganz fertigen, und vor allem wenig getesteten Patch für geeqie, der dafür sorgen soll, dass die Metadaten auch noch in eine zentrale Datenbank gehen. Der Patch liegt hier seit anderthalb Jahren herum, und ich tue nichts mehr dran. Das liegt hauptsächlich daran, dass meine Vorstellungen sich immer weiter davon entfernt haben, mit den Interna von geeqie zu harmonieren. Ein Punkt ist die verzeichnisbasierte Arbeitsweise von geeqie, ein Anderer das überkomplizierte Handling von Metadaten insgesamt in geeqie.

Übrigens ist geeqie innendrin fast überall überkompliziert - der Versuch, die Programminterna von externen APIs durch eigene Wrapper abzuschirmen, ist für meinen Geschmack nach hinten los gegangen, und macht den Code übertrieben kompliziert. Trotzdem ist es für die Entwickler sehr aufwändig, mit den Änderungen in den Gnome/Gtk-Libraries mitzuhalten (nicht dass ich solche Probleme nicht auch kennen würde).

Das ist insofern relevant, als dass ich keine großen Probleme mehr sehe, was die eigentliche Datenhaltung betrifft. Aber geeqies Benutzerinterface ist in der jetzigen Form wenig geeignet, wirklich große Mengen Schlagwörter einzugeben und zu verwalten, und um das komplett neu zu machen, müsste ich mich mit einer bastardisierten GTK-Schnittstelle herum ärgern, die weder auf dem aktuellen Stand von GTK noch wirklich in sich logisch ist. Nein, lieber nicht.

Also habe ich mal wieder nach einer vernünftigen Bilddatenbank gesucht, mit so schönen Suchbegriffen wie "photo organizator", "digital asset management", "image database", und so weiter.

Was soll ich sagen? Ich bin nicht wirklich begeistert.

• Die Sache mit den Zeichensätzen geht immer noch gelegentlich schief - schreiben wir wirklich 2016?
• Wenn eine Software meint, sie müsste bei jedem Start das komplette NAS (im Moment 1,5 Terabyte Bilder) nach neuen Dateien absuchen, und mich zwischen 1 und 2 Minuten warten läßt, bevor sie startet, dann ist die nichts für mich, ganz egal, wie toll das Handling von Metadaten ist.
• Wenn die Autoren einer Bilddatenbank schon wissen, dass ihre Datenbank (im Gegensatz zu den Bildern) nicht auf einem Netzwerklaufwerk liegen darf (vermutlich wegen des Lockings der sqlite-Datenbank), warum in aller Welt erlauben sie dann nicht wenigstens, dass man auch MySQL/MariaDB oder Postgresql nehmen kann?
• XMP-Sidecars sind ein offenbar unlösbares Problem. Jedenfalls für die meisten Programme.
• Sidecars (IMG_0123.JPG und IMG_0123.CR2 oder so zusammen zu verwalten) ist wohl auch gerade üblich.
• Das schöne an Standards ist, dass sich jeder einen aussuchen kann, der er kreativ so umsetzt, dass er Standards einhält, ohne irgendwie mit anderen Programmen zusammenarbeiten zu können. Mit der Einführung von XMP hätte IPTC schlicht und einfach verboten werden müssen (über Exif verliere ich an dieser Stelle bewusst kein Wort).
• Wie viel Prozent der Programme tun wohl etwas Sinnvolles, wenn man das Verzeichnis 20161218-unsortiert in 20161218-anderername umbenennt? Im Moment ist mein Eindruck, dass genau 0% der Programme damit perfekt umgehen können.
• Oh, und last, but not least: Wenn man mal den Fehler macht, ein halbes Dutzend verschiedener Bilddatenbanken auf sein NAS los zu lassen, hat man hinterher mehr als ein halbes Dutzend Thumbnails oder Vorschaubilder auf dem NAS oder auch der lokalen Festplatte verstreut. Wirklich klasse - ich meine, Plattenplatz ist ja wertlos. NICHT.
• Ok, nun wirklich der letzte Punkt: Geht das mit dem Anlegen der Vorschaubilder nicht vielleicht etwas intelligenter? Wie wäre es damit, die im Hintergrund anzulegen und bis das fertig ist Vorschaubilder anzulegen, wenn sie gebraucht werden? 1,5 Tage darauf zu warten, dass die Bilddatenbanksoftware Vorschaubilder anlegt, bevor man sinnvoll testen kann, ob sie mit der Datenmenge umgehen kann, ist etwas unbefriedigend.

Photostation, die zum QNAP NAS gehörende Fotoverwaltungs/Darstellungs-Saftware, ist ganz nett. Doch, wirklich. Aber leider hält sie Metadaten in einer eigenen Datenbank, und nur dort. Sie exportiert die nicht mal auch nur in die Nähe der Bilder. Durchgefallen.

Sachdienliche Hinweise nehme ich gerne entgegen. Anforderungskatalog: Siehe oben. Absolut notwendiges Feature: ich will sämtliche Metadaten entweder in die Bilder oder in Sidecars exportieren können.

---

Ende Technik, und nun zur Fotografie.

Es lief ganz anders als geplant. _Eigentlich_ war mindestens ein Trip nach Helgoland geplant, dazu Madeira, vielleicht etwas Ostseeküste, und natürlich Gänse, Kröten, Molche, und ganz viel Fisch in den lokalen Seen.

Die Gänse fielen flach, weil ich gerade Anderes zu tun hatte. Die Kröten und Frühblüher fielen dem gebrochenen Zeh zum Opfer (nicht nachahmenswert). Der Helgoland-Trip fiel aus (Zeh, Zeitprobleme, und dann war da noch der junge Kater).

Der Fisch? Der war bestimmt die ganze Zeit da, aber die Sicht in den Seen war übel, und wurde erst im August brauchbar. Dann war gelegentlich nichts los (Fische sind beweglich, und nicht immer da, wo sie gefälligst sein sollten), und echte Highlights waren selten (sonst wären sie ja keine).

Karpfen gab's, wie immer, in Massen - wobei auch die es fertig bringen, sich rar zu machen.

Schwamm auch, aber der See hatte deutlich mehr Wasser als in den Vorjahren, und der Baum, an dem die Schwämme sitzen, lag etwa einen Meter tiefer. Für den Zweck, Schwämme zu fotografieren, war das nicht ganz optimal.

Das erste Highlight war die Schleie. Schleie? Wie lang war das her, dass ich meine letzte Schleie im Üttelsheimer See gesehen habe? Das musste ich glatt nachsehen - es waren 12 Jahre. 12 Jahre, in denen ich speziell im Sommer oft im Wasser war, und weite Teile der Seeufer abgesucht habe, aber keine Schleie sah.

Dieses Jahr sah ich einmal eine - mitten unter den Karpfen. Dusel. Einfach nur Dusel.

Schildkröten gab es auch. Dieses Jahr waren sie scheu, und unter Wasser habe ich nicht eine gesehen. Das Bild oben war eine interessante Geduldsübung - wird mir schneller kalt als die Frontlinse trocken wird?

---

Und dann kam der letzte Tag im Ütti. Die Sicht hatte längst nachgelassen, die Abende waren kürzer geworden, und die Temperatur gesunken - und die Wettervorhersage machte es wahrscheinlich, dass die Saison zu Ende ging. Die Bilder der Karpfen wurden nur noch selten scharf, und nach einiger Zeit hatte ich keine Lust mehr, und schwamm weiter. Der Plan war, auf die andere Seite der Insel zum Schwamm zu schwimmen, und dann im See durch den Flachbereich zu streifen, wo man manchmal Glück hat, und an einer Stelle mit relativ guter Sicht nach Jungfisch-Schwärmen Ausschau zu halten (da _könnte_ man Erfolg haben, aber wahrscheinlich ist es nicht).

Nun, es kam anders - 30 Meter nach den Karpfen, am nächsten Baum, hing etwas über dem Ast.

Genau, Aal. Ein Aal in der Größe braucht sich keine Gedanken um Reiher und Kormorane machen. Die haben ihre Chance verpasst.
Aal. Schön. Bleiben? Nee, um den Baum rum, vielleicht kann ich doch ein Bild von vorne machen.

Na, der Tag ist auf jeden Fall schon mal gerettet. Aber weiter.

Noch ein Aal? Das könnte der Erste sein, der das Lager gewechselt hat. Also zurück. Nein, tatsächlich drei Aale.

Drei Aale in einem gefallenem Baum? Dusel^3. Ich habe schon öfters schlafende Aale gesehen, aber die waren alle alleine und schliefen auch deutlich tiefer. Fast schon gesellig schlafende Aale in Griffweite von der Oberfläche waren mir neu.

Der Kopf von Nummer 1 lag übrigens in Algen. Keine Chance, da ran zu kommen. Der von Nummer 3 lag etwas tiefer, als mir lieb war, mehr Licht hätte ich halt besser gefunden, aber man nimmt, was man bekommt.

Der See hat so um die 23 Hektar Fläche, ich bin seit 2001 dort unterwegs, und immer noch überraschen mich der See und seine Tiere.
Dass ich etwas noch nie gesehen habe, heißt also gar nichts.

---

Eigentlich hatten wir ja einen Urlaub auf Madeira geplant. Aber dann kam der junge Kater zu uns, und das Tier mit 5 Monaten für ein paar Wochen in eine Tierpension zu geben, brachten wir dann doch nicht über uns. Also haben wir umdisponiert, und sind in die Eifel gefahren. Mit Kater.

Was soll ich sagen? Er hat offenbar es genossen - und wir auch.

Dass Katzen mehr orts- als personengebunden sind, stimmt jedenfalls nicht immer. Wir waren 4 Tage an einem Ort, 11 am nächsten, und Flip hat jeweils nicht mal einen Tag gefremdelt, sondern sehr schnell angefangen, die Gegend zu erkunden.

An einem Tag gingen wir los, um hoch auf den Hügel (den mit Wollseifen) zu gehen. Nun, wer kam hinterher? Der Kater. Na gut, an der nächsten Ecke dreht er bestimmt um. Nein. Am Beginn des Feldwegs, wo er nur durch einen Garten zurück laufen muss, um zur Unterkunft zu kommen? Nein. Am Ende des Feldwegs? Nein. Aber wenigstens etwas später? Nein.

Der kleine Kerl kam mit. Keine 6 Monate alt, 200 Höhenmeter, bestimmt 6 Kilometer, und getragen zu werden wollte er nicht, weder auf den Armen noch im Rucksack. Nein, Seine Katzigkeit beliebte zu laufen - auf den eigenen Pfoten, und kreuz und quer.

Das hat wenig mit Naturfotografie zu tun? Das ist auf der einen Seite richtig. Auf der anderen Seite ist viel vom dem, was wir sicher zu wissen glauben, nicht immer richtig. Verhaltensweisen, die 90% einer Population fremd sind, mögen für die anderen 10% normal sein. Und das hat wieder jede Menge mit Naturfotografie zu tun.

Ich wünsche euch, dass ihr 2018 auf 2017 zurück blicken, und an gute Zeiten zurück denken könnt. Und ich wünsche euch frohe Weihnachten, und einen guten Rutsch.

Gruß, Uwe