Az

Schriftart wählen

Schriftgröße wählen

Zeilenabstand wählen

Schnellzugriff Verlauf Funktionen
19
© Uwe Ohse
19
* ** *** **** Diashow
Klicken Sie auf das Bild, um Bedienelemente einzublenden! Dies verschwindet nach 10 Sekunden und wird noch mal angezeigt. !
Nur das Bild zeigen.
X

Bedienungshinweise

Navigationshilfen
... werden sichtbar, wenn Sie mit der Maus in die oberen 300 oder unteren 50 Pixel gehen.
Oben:
Oben finden Sie Vorschaubilder zur Navigation. Oben links und rechts in den Ecken können Sie die Vorschaubilder seitenweise überspringen.
Unten, von links nach rechts.
Start/Stop der Diashow, An den Anfang / Bild zurück / Bild vor / An das Ende.
Optionen zur Vergrößerung und Verkleinerung der Bilder (Skalierung).
Die Einstellung der Pausendauer.
i blendet den Bildtitel ein.
b Bildseite einblenden.
ESC Beenden der Diashow.
Skalierung:
Ja: Das Bild wird so angepaßt, daß es noch auf den Bildschirm paßt - bei Bedarf wird es vergrößert oder verkleinert.
Kleiner: Das Bild wird so angepaßt, daß es noch auf den Bildschirm paßt. Dabei wird es nur verkleinert, nie vergrößert.
2x: Das Bild maximal auf die zweifache Fläche vergrößert, nie aber verkleinert.
Nie: Das Bild wird exakt in den Maßen dargestellt, für die es gedacht ist. Übergroße Bilder werden angeschnitten.
Tastatur:
Leertaste: Start/Stop. Links / Rechts: Zurück und Vor. Pos1 bzw. Home / Rechts: Erstes / Letztes.
Tab: Geht die Skalierungsoptionen durch. Punkt: Blendet den Bildtitel aus. Minus: Verläßt die Diashow.
X
i ? Bildseite Ende Start/Stop <<< < > >>> Skalieren: Ja Kleiner Nur 2x Nie. Pause (5Sek.)
Frame Schließen
Vollbild
©...

Farbanalyse

Hilfe

Diese Seite überflutet Dich, wenn alles klappt, mit einer Vielzahl von Darstellungen der Farben des Bildes.

Durch Ziehen der grauen Kästchen kann man die untereinander sortieren (die Sortierung wird auch beim nächsten Laden der Seite beachtet).

Histogramme
Das klassische Histogramm gibt es in mehreren verschiedenen Versionen: RGB, HSL, und die sechs Kanäle jeweils einzeln.
Dekonstruktionen
Das sind Darstellungen, bei denen ein Kanal einzeln gezeigt wird (R/G/B, H/S/L und Y/Cb/Cr). Blaue Pixel zeigen Null- und rote Pixel Maximalwerte (255).
Dazu kommen noch drei Darstellungen, die die Pixel mit dem Wert ihres minimalem / mittlerem und maximalem RGB-Kanals zeigen.
Wellenformen
Wellenformen repräsentieren auf einer Achse eine Achse des Bildes, und auf der anderen Achsel die Verteilung der Pixel auf der anderen Achse an.
Alle Beschreibungen dafür sind wahnsinnig kompliziert und überflüssig, nachdem man die erste Wellenformdarstellung eines Bildes mit größeren Farbflächen gesehen hat.
Vektor-Scope
Vektor-Scope zeigen die Farbe des Bildes im Verhältnis zu Sättigung und/oder Helligkeit an.

Ein Wort der Warnung: Keine dieser Darstellungen sagt irgendetwas über die Qualität eines Bildes aus. Sie sagen gerade mal etwas über Farbverteilungen.
Es gibt weder ein "richtiges" Histogramm noch ein Falsches (High Key / Low Key), und das gilt auch für alle anderen Darstellungen.
Es gibt nicht mal "richtige" Farben.

RGB-Histogramm

Dies ist das klassische Histogramm über die Rot-, Grün- und Blaukanäle. Alle Kanäle werden unabhängig voneinander normiert (die Maxima sind alle gleich hoch), und die Darstellung ist linear.

RGB-Histogramm

Ein Histogramm, das mit Rot den Farbtonkanal (H aus HSL), mit Grün die Sättigung (S), und mit Blau die Helligkeit (L) zeigt.
Alle Kanäle sind unabhängig normiert (die Maxima sind immer gleich hoch), und die Darstellung ist linear.

Rotkanal

Zeigt den Rotkanal des Bildes als Graustufenbild (der Rotkanal wird dabei in die beiden anderen Kanäle kopiert). Blaue Pixel haben einen Rotwert von 0, blaue Pixel einen von 255 (beide zeigen also Extremwerte an, die bei größeren Flächen Unter- oder Überbelichtungen sein könnten).

Rotkanal

Zeigt den Grünkanal des Bildes als Graustufenbild (der Grünkanal wird dabei in die beiden anderen Kanäle kopiert). Blaue Pixel haben einen Grünwert von 0, blaue Pixel einen von 255 (beide zeigen also Extremwerte an, die bei größeren Flächen Unter- oder Überbelichtungen sein könnten).

Blaukanal

Zeigt den Blaukanal des Bildes als Graustufenbild (der Blaukanal wird dabei in die beiden anderen Kanäle kopiert). Blaue Pixel haben einen Blauwert von 0, blaue Pixel einen von 255 (beide zeigen also Extremwerte an, die bei größeren Flächen Unter- oder Überbelichtungen sein könnten).

Hue-Kanal (Farbwinkel auf dem Farbkreis)

Zeigt den Farbwinkel des Bildes als Graustufenbild (der Winkel wird dabei auf einen Maximalwert von 255 umgerechnet und in die drei Farbkanäle geschrieben).
Dafür werden die Pixel von RGB nach HSL konvertiert.

Sättigung

Zeigt die Sättigung des Bildes als Graustufenbild (die Sättigung wird dabei in die beiden anderen Kanäle kopiert). Blaue Pixel haben eine Sättigung von 0, blaue Pixel eine von 255 (beide zeigen also Extremwerte an, die bei größeren Flächen Unter- oder Überbelichtungen sein könnten).
Dafür werden die Pixel von RGB nach HSL konvertiert.

Relative Helligung (L)

Zeigt die Helligkeit des Bildes als Graustufenbild (die Helligkeit wird dabei in die beiden anderen Kanäle kopiert).
Blaue Pixel haben eine Helligkeit von 0, blaue Pixel eine von 255 (beide zeigen also Extremwerte an, die bei größeren Flächen Unter- oder Überbelichtungen sein könnten).

Dafür werden die Pixel von RGB nach HSL konvertiert.

Y-Kanal (YCbCr)

Zeigt die Grundhelligkeit der Pixel als Graustufenbild.
Dafür werden die Pixel von RGB nach YCbCr konvertiert.
Diese Information mag hilfreich sein, weil JPEG intern YCbCr verwendet.

Cb-Kanal (YCbCr)

Zeigt die Blau-Gelb-Farbkomponente der Pixel als Graustufenbild. Blau wird als Dunkler, und Gelb als heller Pixel gezeigt.
Dafür werden die Pixel von RGB nach YCbCr konvertiert.
Diese Information mag hilfreich sein, weil JPEG intern YCbCr verwendet.

Cb-Kanal (YCbCr)

Zeigt die Rot-Grün-Farbkomponente der Pixel als Graustufenbild. Rot wird als Dunkler, und Grün als heller Pixel gezeigt.
Dafür werden die Pixel von RGB nach YCbCr konvertiert.
Diese Information mag hilfreich sein, weil JPEG intern YCbCr verwendet.

Minimalkanal

Hier bleiben die Farbkanäle erhalten, die die kleinsten RGB-Werte haben.

Mittelkanal

Hier bleibt der Farbkanal erhalten, deren Wert zwischen denen den beiden Anderen liegt (RGB).

Maximalkanal

Hier bleiben die Farbkanäle erhalten, die die größten RGB-Werte haben.

Wellenform: RGB

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse zeigt die Intensitäten der drei RGB-Kanäle. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellen die RGB-Farbkanäle im räumlichen Kontext dar.

Wellenform: R

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse zeigt die Intensität des Rot-Kanals. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellt den Rot-Kanal im räumlichen Kontext dar.

Wellenform: G

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse zeigt die Intensität des Grün-Kanals. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellt den Grün-Kanal im räumlichen Kontext dar.

Wellenform: B

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse zeigt die Intensität des Blau-Kanals. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellt den Blau-Kanal im räumlichen Kontext dar.

Wellenform: HSL

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse zeigt die Intensitäten der drei HSL-Kanäle. Der H-Kanal (Farbwinkel, Hue) des Bildes wird auf dem Rotkanal abgebildet, die Sättigung auf dem Grün- und die Helligkeit auf dem Blaukanal.

Dieses Wellenformdiagramm stellt Farbwinkel, Sättigung und Helligkeit im räumlichen Kontext dar.

Wellenform: H

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse repräsentiert den H-Kanal (Farbwinkel, Hue, im HSV-Farbraum) des Bildes. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diesen Farbwinkel haben.

Dieses Wellenformdiagramm stellt den Farbwinkel im räumlichen Kontext dar.

Wellenform: G

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse repräsentiert die Sättigung (im HSV-Farbraum) des Bildes. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diesen Farbwinkel haben.

Dieses Wellenformdiagramm stellt die Sättigung im räumlichen Kontext dar.

Wellenform: B

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse repräsentiert die Sättigung (im HSV-Farbraum) des Bildes. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diesen Farbwinkel haben.

Dieses Wellenformdiagramm stellt die Helligkeit im räumlichen Kontext dar.

Vertikale Wellenform: RGB

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse zeigt die Intensitäten der drei RGB-Kanäle. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellt die RGB-Kanäle im räumlichen Kontext dar.

Vertikale Wellenform: R

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse zeigt die Intensität des Rot-Kanals. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellt den Rot-Kanal im räumlichen Kontext dar.

Vertikale Wellenform: G

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse zeigt die Intensität des Grün-Kanals. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellt den Grün-Kanal im räumlichen Kontext dar.

Vertikale Wellenform: B

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse zeigt die Intensität des Blau-Kanals. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellt den Blau-Kanal im räumlichen Kontext dar.

Vertikale Wellenform: HSL

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse zeigt die Intensitäten der drei HSL-Kanäle. Der H-Kanal (Farbwinkel, Hue) des Bildes wird auf dem Rotkanal abgebildet, die Sättigung auf dem Grün- und die Helligkeit auf dem Blaukanal.

Dieses Wellenformdiagramm stellt Farbwinkel, Sättigung und Helligkeit im räumlichen Kontext dar.

Vertikale Wellenform: Hue/Farbwinkel

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse repräsentiert den H-Kanal (Farbwinkel, Hue, im HSV-Farbraum) des Bildes. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diesen Farbwinkel haben.

Dieses Wellenformdiagramm stellt den Farbwinkel im räumlichen Kontext dar.

Vertikale Wellenform: Sättigung

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse repräsentiert die Sättigung (im HSV-Farbraum) des Bildes. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diesen Farbwinkel haben.

Dieses Wellenformdiagramm stellt die Sättigung im räumlichen Kontext dar.

Vertikale Wellenform: L

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse repräsentiert die Sättigung (im HSV-Farbraum) des Bildes. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diesen Farbwinkel haben.

Dieses Wellenformdiagramm stellt die Helligkeit im räumlichen Kontext dar.

Vektor-Scope: Geo

Diese Darstellung zeigt die Chromazität.

Die Distanz vom Zentrum der Graphik repräsentiert den "Abstand" der Sättigung und Helligkeit vom hellsten Weißton. Die Helligkeit gibt die Anzahl der Pixel wieder. Der Abstand wird hier als Wurzel der Summe der Quadrate von Sättigung und Helligkeit berechnet.

Vektor-Scope: Luminanz

Diese Darstellung zeigt die Chromazität.

Die Distanz vom Zentrum der Graphik repräsentiert die Helligkeit der Bildpixel, und die Helligkeit der Graphik die Anzahl der Bildpixel mit der Helligkeit und dem Farbton.

Vektor-Scope: Sättigung

Diese Darstellung zeigt die Chromazität.

Die Distanz vom Zentrum der Graphik repräsentiert die Sättigung der Bildpixel, und die Helligkeit der Graphik die Anzahl der Bildpixel mit der Sättigung und dem Farbton.
  • Hintergrundfarbe ändern
  • Kontextmenü-Emulation abschalten
https://naturfotografen-forum.de/data/o/271/1355049/thumb.jpghttps://naturfotografen-forum.de/data/o/271/1355049/image.jpg
Eingestellt:
Aufgenommen: 2016-08-30
UO ©
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 Bild: Lächelndes Gesicht

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


Amerikanischer Flusskrebs

Amerikanischer Flusskrebs. Im Halbdunkel hätte ich den beinahe übersehen.


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).




Blatt unter Wasser


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 Bild: Lächelndes Gesicht


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.



Ganz so war es nicht. Ich habe nur etwas mit der HDR-Funktion der FZ300 herum gespielt, und das ist eines der wenigen tauglichen Resultate, wenn es auch nicht das wieder gibt, was ich gesehen habe.


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).



Wenn man keinen Fisch findet…



Es sieht nur so aus, als läge der Karpfen herum.

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.

Schleie

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? Bild: Lächelndes Gesicht


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.

Aal
Aal mit Karpfen darunter.

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.

Aal
Noch ein Aal.

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

Aal
Und noch einer.

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.

2 Aale

Zwei Aale, denn plötzlich schwamm Aal #2 unter #3 durch.

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.

Flip

Flip, 10.4.2016 - 19.11.2016.

Danke.

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

Technik:
IDer Hecht:

Olympus XZ-1, 6mm (entsprechend 28mm Kleinbild)
1/60 Sek., f/1.8, ISO 200
Belichtungsautomatik, Automatischer Weißabgleich

Die anderen Bilder: Panasonic FZ 300, und die XZ-1.

Fotografischer Anspruch: Fortgeschritten ?
Dokumentarischer Anspruch: Ja ?
Größe 715.0 kB 1250 x 938 Pixel.
Attachments:P1020752-900.JPG (218 KB),P1030274-900.JPG (184 KB),P1030319-900.JPG (471 KB),P8240485-900.JPG (325 KB),P8270750-900.JPG (359 KB),P8270891-900.JPG (397 KB),P8270978-900.JPG (472 KB),P8281140-900.JPG (339 KB),P8281341-900.JPG (253 KB),P8301757-900.JPG (380 KB),P8311834-900.JPG (366 KB),P9113508-900.JPG (249 KB),P9133918-900.JPG (247 KB),P9154382-900.JPG (295 KB),P9154439-900.JPG (295 KB),P9154448-900.JPG (304 KB),P9154466-900.JPG (304 KB)
Platzierungen:
Beste Tophit-Platzierung: 21 Zeigen
Teilnehmer Unterwasserbild des Monats Januar 2017
Ansichten: 187 durch Benutzer624 durch Gäste
Rubrik
Adventskalender:
Rubrik
Unter Wasser:
Serie
Hechte:
Hier war ein gelöschtes oder deaktiviertes, oder für Sie unlesbares Objekt.