Ultraweitwinkel für Nikon DX

Wer schon mal mit mir fotografieren war, der kennt meinen Ausruf “Jetzt ein Weitwinkel haben”. Mit Weitwinkel meine ich in dem Fall nicht die 18mm, die mein Kitobjektiv schafft – ich meine richtig weit 🙂 Bekannt als “Super”- oder “Ultraweitwinkel”, und im DX-Bereich bis runter auf 8mm erhältlich (an FX dann entsprechend länger). Jetzt ist es so weit: Ich will mir ein solches UWW kaufen – im Folgenden mein Entscheidungsprozess. Man liest relativ häufig die Frage “dieses oder jenes Objektiv”, vielleicht hilft dieser Post ja bei der Entscheidung 🙂

Meine Voraussetzungen:

  • ein Zoom soll es sein, keine Festbrennweite (damit auch kein Fisheye, aber das wäre mir eh zu speziell… witzig, aber zu speziell. Zumindest bis auf Weiteres ;-))
  • ein Gebrauchtes soll es werden. Das ist nicht nur günstiger, sondern auch wertbeständiger, wenn ich es wieder verkaufe

Wenn man sich umguckt in Foren oder bei beliebigen Experten, dann landet man schnell bei drei Optionen:

  1. Möglichst weitwinklig. Das bedeutet heute (Stand: Juli 2013) das SIGMA 8-16mm, dem einzigen 8mm
  2. Möglichst flexibel einsetzbar. Das bedeutet wohl das Nikon 10-24mm, da es den größten Bereich abdeckt
  3. Was dazwischen: Kleinerer abgedeckter Bereich als das Nikon und/oder noch länger als 10mm “am unteren Ende” oder oder oder…

Erste Gedanken zu jedem Punkt:

  1. Das SIGMA hat eine so konvexe Linse, dass man keine Filter draufschrauben kann. An sich schon fast ein No-Go, in Verbindung mit “nur” 16mm am oberen Ende das Ausschlusskriterium. Schade um die 2mm nach unten, aber das macht insgesamt einfach keinen Sinn
  2. Das 10-24 ist eigentlich zu teuer. Laut Gebrauchtpreisliste kostet es aktuell durchschnittlich 570 Euro – wohlgemerkt: Gebraucht. Bei Amazon kann man auch mal 650 dafür ausgeben^^ Schade, denn der abgedeckte Bereich ist interessant, und es ist wohl wirklich gut!
  3. 10mm sollte es “unten” schon haben. Die Dinger sind zu teuer, um eines für “nur” 12 oder 14mm zu kaufen. Damit scheidet immerhin ein Teil der Option 3 aus.

Also: Tendenziell Option 3. Anbieten würde sich zum Beispiel das SIGMA 10-20 4.0-5.6; häufig ein Preis-/Leistungssieger. Interessanterweise wird es häufig sogar besser (=schärfer, kontrastreicher) als sein Nachfolger eingeschätzt, dem 10-20 3.5. Der abgedeckte Bereich ist dann auch nicht soo weit weg vom Nikon…

Soweit zum Entscheidungsprozess. Was nun? Man sollte wohl dazu sagen, dass es in dem bereits verlinkten DSLR Forum einen Unterbereich “Biete Nikon” gibt, in dem es oft sehr gute Angebote gibt. “Man kennt sich”, insofern ist das Forum vertrauenswürdig und eher freundschaftspreisig als Ebay oder Amazon. Wenn man ein wenig guckt. 🙂 Das habe ich getan, und es hat sich, so nach zwei, drei Wochen, tatsächlich ein 10-20er SIGMA gefunden, sogar das mit der 4.0-5.6er Blende! Für 290€ inkl Versand, was relativ genau dem Gebrauchtlistenpreis von 285€ (+Versand) entspricht.

Erste Testaufnahmen sind sehr zufriedenstellend. Warum jetzt “erste” Testaufnahmen? Weil sich just drei Tage nach Erhalt des SIGMAs ein 10-24er Nikon gefunden hat, und das für vergleichsweise unschlagbare 490€ inklusive Versand. Nun fragt man sich: Sind die “fehlenden” 4mm den doch deutlichen Aufpreis wert? Ist vielleicht die Bildqualität so viel besser, die Verzerrung so viel geringer? 490€ kann man doch nicht ernsthaft für ein Objektiv bezahlen wollen?

Das soll und wird aber Thema eines weiteren Posts sein, denn: Ich habe zugeschlagen, und jetzt tatsächlich zwei UWW 🙂 Eines von beiden wird natürlich kurzfristig wieder verkauft; ich gehe davon aus, dass das (quasi) ohne Verlust möglich ist. Jetzt gilt es zu entscheiden, welches.

 

UPDATE

Es ist das Nikon geworden, klar 🙂 Ursprünglich hatte ich einen umfangreichen Test vor, insbesondere im Hinblick auf Verzerrungen. Dafür hatte ich das Kachelmuster in der Küche mit beiden Objektiven auf verschiedenen Brennweiten fotografiert – nur, um festzustellen, dass das SIGMA im direkten Vergleich an den Rändern echt unscharf wird.

Magnolia CMS: Advanced Templating

Über das offensichtliche Templating hinaus geht zum Beispiel das Beerben von Dialogen oder das Verschachteln von Komponenten:

Vererbung von Dialogen

Vererbung ist recht simpel, wenn man ein paar Dinge weiß (wie immer bei Magnolia). So beerbt man zum Beispiel keine Komponenten. Komponenten haben immer einen “dialog”, einen “renderType”, ein “templateScript” und einen “title”, aber kein “extends” – anders als Pages! Man kann allerdings Dialoge beerben, und einer Komponente einen solchen Dialog zuweisen. Im Template-Script dieser Komponente kann man dann auf die Werte “beider” Dialoge zugreifen.

Desweiteren muss man wissen, und das ist der eigentliche Clou, dass das “extends”-Property eines Dialoges relativ verlinkt – also anders als bei der Verlinkung von bsplw. Pages mit ihren Komponenten. Das sieht korrekterweise dann so aus:

Im Beispiel oben übernimmt “largeTeaser” die “actions” und alles aus “form” von “teaser”.

 

Verschachteln von Komponenten

Was ich gerne haben möchte, ist Folgendes: Eine “smallTeaser”-Komponente, die aus genau zwei kleinen Teasern besteht. Nicht mehr (sollte das nötig sein, könnte man der Seite eine weitere “smallTeaser”-Komponente hinzufügen), aber auch nicht weniger (denn dann entsteht ein “Loch” im Layout, es müssen immer genau zwei kleine Teaser nebeneinander sitzen).

Vorweg: Das geht nicht.

Was man nur machen kann, ist folgendes: Eine “smallTeasers”-Komponente definieren, die in Form einer Liste maximal zwei kleine Teaser enthält. Das funktioniert analog zu Areas mittels “availableComponents”:

Die erwähnten “Löcher” im Layout bleiben damit explizit möglich; man kann auch nur einen kleinen Teaser einsetzen. Außerdem denke man an komplexere Komponenten, die aus einem Teaser, einem einleitenden Text+Headline, einem wasweißich bestehen. Es ist (offenbar) nicht möglich, das mittels verschachtelten Komponenten abzubilden. Man hätte immer eine Liste von bis zu (nicht genau) drei Elementen, die eine beliebige Kombination der genannten wären. Auch drei mal Teaser ohne Einleitung wären möglich. So nützen einem verschachtelte Komponenten nichts 🙁

Achso, das obligatorische “muss man wissen”: Unter den “availableComponents” darf nicht mehr als eine Komponente mit derselben ID liegen! Dann stürzt alles mit der äußerst hilfreichen Fehlermeldung “An error occurred while executing action [addComponent]” ab 🙂 Das muss man immer mittels Listen lösen.

HTH

Magnolia CMS: Templating

Voraussetzung: Entsprechende Templates in der Struktur Seite (“Page”) -> Bereich (bsplw. für Teaser, “Area”) -> Komponenten (die Teaser in diesem Beispiel, “Components”) -> Eingabemaske (für die Daten des Teasers, “Dialog”). Details zum Aufsetzen und Verknüpfen dieser Templates im letzten Post. Jedem Template außer dem Dialog wird mit dem Attribut “TemplateScript” ein Skript im Dateisystem zugeordnet (Dateiendung .ftl).

Nun sollen diese Skripte gefüllt werden. Wieder glänzt die “Dokumentation” nicht mit Details. Im Gegenteil: Ganze Bereiche werden verschwiegen, wichtige Details sind irreführend bis falsch, der Rest ist fragmentiert. Aber der Reihe nach. Im Folgenden benutze ich übrigens Freemarker, nicht JSP.

Das Page-Skript enthält eine komplette HTML-Seite. Ich hätte das gerne anders gemacht, zum Beispiel würde ich den <head> gerne auslagern, aber das ist eine extra Baustelle, die auch nicht offensichtlich dokumentiert ist. Deshalb: In diesem Beispiel ist die Page eine HTML-Seite, mit <body>, <head> und allem drum und dran. In das Skript muss im <head> ein Tag eingefügt werden, um das “Edit”-Panel zu aktivieren:

Im Body markiere ich den Teaser-Bereich mit

wobei “teasers” der Name des zugehörigen Content Knotens der Areas ist, siehe hier. Die Seite kann nun editiert werden; als editierbare Elemente wird der Teaser-Bereich angeboten. Dorthinein können die im Bereich erlaubten Komponenten (“availableComponents”) gesetzt werden. Per default, d.h. ohne jedes Skript, zeigt eine Area diese Komponenten dann an. Will man manuell eingreifen, etwa für umschliessendes HTML, dann kann man das Area-Skript wie folgt nachbauen:

Die Komponenten schließlich sind stark mit ihrem “Dialog” (ihrer Eingabemaske) verknüpft, und hier beginnt die Magie. Es gibt tatsächlich kein funktionierendes Beispiel, wie man bsplw. ein Bild aus der Asset-Verwaltung im Dialog auswählen, und im Skript verlinken kann. Der Didaktik wegen erst der Dialog (Klick für große Ansicht):

Im Detail:

  • Der Dialog wird in Magnolia 5 nicht mehr direkt in Tabs unterteilt, wie die Doku hier nahelegt. Stattdessen werden “actions” (Speichern, Abbrechen, etc.) und die eigentliche Eingabemaske (“form”) unterschieden (Quelle). Das hatte ich hier schon bemängelt 🙂
  • Die “actions” sind ziemlich Copy&Paste
  • Das Formular wird dann in Tabs unterteilt, es muss immer mindestens einen Tab geben.
  • “headline”, “copy” und “button” (im Sinne von Buttontext) sind bei mir vom Typ TextFieldDefinition. Gut zu wissen: “rows” beschränkt die Zeilenanzahl nicht, es erweitert nur das Eingabefeld in der Maske. Es sind trotzdem mehr als “rows” Zeilen möglich!
  • “bgImage” schließlich ist vom Typ LinkFieldDefinition:
    • “contentPreviewDefinition” sorgt für die Vorschau des ausgewählten Bildes; dazu wird die “contentPreviewClass” auf info.magnolia.dam.asset.field.DamFilePreviewComponent gesetzt.
    • “appName” ist analog zur Doku “assets”, “class” ist ebenfalls analog zur Doku, “label” ist Freitext
    • “targetWorkspace” hat sich in Magnolia 5 ebenfalls geändert; statt “dms” muss es “dam” sein! Andererseits hatte es bei mir auch keine Auswirkungen, wenn ich das einfach weglasse^^
    • “identifierToPathConverter” hatte bei mir keine sinnvollen Auswirkungen, so wurde zum Beispiel nie der Pfad zur Datei ausgegeben, vgl. unten

So, nun hat man Texte und ein Bild im Dialog der Komponente – wie spricht man diese im Skript der Komponente an? Die Texte sind einfach:

Das Bild dagegen würde mit

nur den Pfad des Objekts in der Asset-Verwaltung ausgeben, etwa /myTeasers/teaser_1. Das wäre nicht mal eine URL zu der Grafik dahinter, wenn hier ein “.jpg” dranhinge. Stattdessen muss man den “Content” zu diesem Pfad erst auslesen, und dann in einen “Link” konvertieren:

Hier ist interessant, dass “cmsfn” vom Typ TemplatingFunctions im Template-Skript zur Verfügung steht. Muss man wissen 🙂 Was jetzt vielleicht noch so verfügbar ist, weiß ich nicht, aber für Hinweise bin ich dankbar!

HTH

Magnolia CMS: Templates mit custom Komponenten und Dialogen

Magnolia ist ein CMS, und vor nicht allzu langer Zeit in Version 5 erschienen. Wesentliche Neuerung: Das Backend ist jetzt touch-optimiert. Denn, seien wir ehrlich: Wer pflegt seine Inhalte nicht über das iPhone… das war Sarkasmus.

Wie auch immer, mit dem Umbau des Backends hat sich offenbar auch einiges an der Erstellung und Verknüpfung von Templates und deren Bestandteile geändert – was zum Teil auch (noch) nicht korrekt in der “Doku” erklärt wird. Die Anführungszeichen um “Doku” deshalb, weil es sich um ein Freitext-Wiki handelt, was das Nachschlagen mühsam macht. Hier deshalb die gebündelte Kurzform:

Anlegen von Seiten-Templates funktioniert tatsächlich nach Doku:

Verwendete Komponenten werden in der Seite im Knoten “areas” der Page referenziert, allerdings nicht (genau) wie in der Doku angegeben mittels “<module name>:<relative path to component>“: “module name” ist, wie auf dem ersten Screenshot von oben zu vermuten, tatsächlich “templating”, allerdings muss man in dem “relative path to component” das “templates” weglassen! Der relative Pfad lautet also nur “components/largeTeaser“:

Die Komponente selbst ist korrekt in der Doku beschrieben. Hier die Attribute; das templateScript liegt parallel zum Script der Page, siehe oben:

Den zugehörigen Dialog zu verlinken (Attribut “dialog“), weicht dann am stärksten von der Doku ab. Obwohl es in der Doku zu Magnolia 5 “Templating in Magnolia 5.0 works the same way as it did in 4.5” heißt (Stand: Anfang Juli 2013), muss man den Dialog in “actions” und “form” aufteilen, wie hier im Wiki beschrieben. Die Beschreibung in der (4.5er?) Doku funktioniert nicht mehr. Ein weiteres Manko der “Doku” von Magnolia: Es ist nicht offensichtlich, wann man Wiki und wann Doku verwendet 🙁

Außerdem muss man die Dialoge direkt im Modul ablegen, nicht unter “templates”. Verknüpfung dann über “templating:largeTeaser“, hier lässt man also auch das “dialogs” im Pfad weg: