Dropping some Roskilde Festival 2025 names. Kind of a mix of "must-sees", "why not give them a change" and "some of it for fun?".

I have been to almost every Roskilde Festival since 1989. And in the 90s and 00s it was insane how many names I wanted to see (and how many I was forced to skip). Of course I'm not in the main target group of the festival any more, and there's not nearly as many artists I absolutely have to hear. But I'm still able to set a bit more than just a handful of marks in schedule. And it is going to be a fun festival again this year🙂...

It is just a very quick and rough videos list for now. But I hope/plan/expect to update this post in the coming days and weeks...

Magdalena Bay

Wet Leg

Yeule

Nine Inch Nails

Beth Gibbons

FKA Twigs

Fay Webster

Fontaines D.C.

Wisp

Lambrini Girls

Beabadoobee

Astrid Sonne

Emma Sehested Høeg

Jessica Pratt

Bright Eyes

The Raveonettes

Mø

Molina

Deb Foam

Geordie Greep

Lola Young

Karoline Funder

Øyunn

Olivia Rodrigo

Doechii

Snow Strippers

Tyla

Charli XCX

Dayyani

Arca

Deftones

Jamie XX

rf25 festival music roskildefestival orangefeeling

How many people have a homepage/blog instead of just sharing what they want to share (and possibly a bit more than that ;-)), on social media? How many of these people are last.fm users? How many of these are nerdy enough to think it is fun sharing their last.fm "scrobbles" on their homepage/blog and are technically able to add a bit of "custom content" to their website? And of these, how many will stumble upon a post on this blog? Oh well, not going to think too much about those details now ;-) ...

It has already been sitting in the side-column of rockland.dk in several months, and now I finally feel my Tracks widget is ready for an announcement here. It is a webpage-widget to show "scrobbles" from a last.fm account. And a widget that should be easy to integrate on any webpage if you are able to include a script on the page and insert a single html-element where you want the widget to be on your page.

The widget can be configured to work in several ways. In the simplest setups it will communicate directly with last.fm (with the audioscrobbler 2.0 api). This should be easy to get working for most. But for advanced users, the widget also has an option to use "a custom api address" which makes it possible to use a "throttling proxy-api" in front of the audioscrobbler api.

Something rather unique for this widget, is that it features "album-headers" in the tracklists. Something that disappeared from last.fm many years ago when people started streaming playlists instead of listening to their albums. But as primarily an album listener myself (also when I'm streaming), I have missed them. So the Tracks widget analyzes the scrobbled data to identify albums and insert the "headers" when more than one song from same album is played successively. But if you don't like those headers, they can also be disabled.

Try the widget with your own (or any) last.fm user, read more about widget modes, configuration options and how to use it, on the demo-site I have created for it:

https://lastfm-widgets.deno.dev

It is of course open source and free to use. Sourcecode for widget, an example proxy-api and for the above linked demo-page is all to be found on github:

https://github.com/StigNygaard/lastfm-widgets

For those interested in some technology details... The widget is a webcomponent implementing a shadow-DOM to isolate its content from script and styling on the page it is inserted into. The example "proxy-api" is implemented in Deno (serverside javascript/typescript) and are also running on the demo-site. The proxy-api is not only used by the widget on the demo-site, but also by the widget here on rockland.dk. And actually the entire github repository is a Deno Deploy project, so any changes added to main-branch of the repository (widget, demo or proxy-api code) are immediately deployed to the demo-site. It is the first time I try playing a bit with Deno (or serverside javascript in general), and thus also my first experiments with Deno Deploy. But I don't think it will be the last...

This curly purple "thing" was an installation at the Copenhagen Light Festival, held back in February. The real name of the lightwork by Hans E Madsen & Frederik Dahl Hougs was "Pressure", and changing colors and impulses should symbol something about "digital stress". Well, I just think it was nice :-) Standing at the waterfront of Copenhagen Harbour on the quay next to Christian IV's Bridge, you also had view back towards Børsen and Christiansborg as depicted here. There's a couple of more shots from the light festival on my Flickr.

Btw., if you do an image-search on "Curly Purple" you pretty much only get some hairstyle shots. I wonder if it is possible to "interrupt" that search? :-)

Meta: Copenhagen Light Festival 2021, February 14th 2021 19:05. Canon EOS 7D Mark II on tripod, EF-S 15-85mm @ 15mm, f/5.6, 1 sec., 100 ISO.

Try my 16-photos virtual tour in Copenhagen Street Food market and recreational area, Reffen on Refshaleøen. I spent a great deal of my time at Reffen this summer and brought my VR 360° camera a couple of times. Photos are all from a few days in August.

The tour/photos are hosted on my new account at RoundMe.com. Later I will post some of the photos on Flickr too, however Flickr doesn't offer creating tours or other of the more advanced 360-panorama features utilized here. You can also see the tour with a VR headset, f.ex. with Google Cardboard. There's an app for RoundMe, but it hasn't been updated in a long time, and it looks like the smartphone optimized website works just as well, if not better. In my short experience also with phone placed in a VR headset.

The photos are some of my first shots with the Xphase Pro S which I purchased last year to replace my Panono (Yes, I've been a bit slow getting started with the new cam). I expect to write more about the Xphase in another post, but in short it offers even better quality and resolution than the Panono, but workflow tend to become rather cumbersome.

Some "snapshots" from the tour:

Go ahead, take the tour! :-)

When I first released a beta-version of xIFr back in July 2019, I didn't announce it here, because I expected to follow up with "final" version shortly after. However, I first found I needed a little break from coding, and after that unexpected events was stealing my spare time and energy for some time. But now, half a year later, I'm finally ready to "officially" announce my browser extension:...

xIFr 1.0

xIFr is a webbrowser extension to view Exif and other meta data in image files. It's far from the first Exif viewer made for Firefox or other desktop webbrowsers, and xIFr is also a "fork" of one of the other add-ons already available. But I felt I could make something that worked better than the existing offers.

Most current Exif reader addons operates in one of two ways. The first kind opens a window with Exif data from an image, launched by right clicking directly on the image (<img> html element) on the webpage. The second kind can be executed "globally" for the webpage (eventually from a toolbar button) and will display Exif data for found images inline on the webpage. The problem with the first kind is that on modern webpages you can rarely right-click directly on an image element. Very often images is "shielded" behind a layer, or image is actually a background property of another kind of html element. The second kind will maybe work more often. But it will also sometimes break the page it is running on, because it directly modifies it to display the meta data of the photos.

xIFr is a variation of the first kind. But thanks to a new API feature introduced in Firefox 63, I have been able to construct it so you can bring up the browser's contextmenu to launch it, by right-clicking pretty much anywhere on a webpage. xIFr will usually guess which image you were thinking of no matter if you actually was clicking directly on an image element, or you were clicking on a layer over it. And it can also find images that aren't actual image elements on webpages, but are background property of another kind of element. Technically xIFr is searching up and down the DOM tree looking for the likely wanted image close to the element your right-click was registered on. I call the feature for "Deep Search"...

Yes, xIFr is "guessing". But it rarely goes wrong, and is in my opinion much more useful and versatile than other Exif readers I have tried. Besides that, it is also among the best looking ;-)

Currently the only "browser addon store" xIFr is available to install from is Mozilla Firefox Addons. In principle xIFr is a "cross browser compatible" WebExtension, also compatible with f.ex. Google Chrome, Opera and the new Chromium based Edge. But at this time only Firefox offers the API-feature used to make the "Deep Search" functionality, so when installed in other browsers, xIFr can only be launched when you can right-click directly on an image element. But if you want to try it in Chrome or another desktop webbrowser, there's usually a Developer-feature in browsers making it possible to install an add-on directly from the local filesystem. Download the extension (zip-file) from GitHub if you want to install it in your browser this way.

Update, April 2020: I have created a little Introduction page to quickly try the features of xIFr, and maybe compare it with other Exif reader browser extensions.

I recently stumbled upon a little demo showing how simple it is to construct an "adaptive layout image wall" using CSS Flexbox. And I thought it would be fun to combine the techniques with a feed from my own Flickr gallery...

Unlike the demo on CSS-tricks, which dynamically adapts itself to screen/browser dimensions or column width, my blog has the advantage (and disadvantage) to be fixed width. So I have further simplified the CSS-code in my "Flickr Wall" below, which displays latest additions to my "FlickrBadge album" on Flickr.
Update March 2021: My blog used to have a fixed width layout, but I have now made column-width "slightly responsive". But still I do not find it necessary to add any of the viewport optimizations from css-tricks post.

Feeds from Flickr is generally not only available in the usual RSS and Atom formats, but among other formats also available in JSON and JSONP format. For the pure-frontend implementation here, JSONP was the natural choice to avoid cross-origin errors. Complete source-code (CSS, Javascript and HTML) for my implementation follows below the wall...

CSS:

<style>
ul#fwall {
  display: flex;
  flex-wrap: wrap;
  padding: 0;
  list-style-type: none;
}
ul#fwall li {
  height: 195px;
  flex-grow: 1;
  margin: 0; /* To reset value set in my global stylesheet */
}
ul#fwall li:last-child {
  flex-grow: 10;
}
ul#fwall img {
  max-height: 100%;
  min-width: 100%;
  object-fit: cover;
  vertical-align: bottom;
}
</style>

Javascript:

<script>
let fwitems = null;
function flickrWall() {
  if (fwitems) {
    let fwall = document.getElementById('fwall');
    fwitems.forEach(function(item) {
      let elem = document.createElement('li');
      let link = document.createElement('a');
      link.setAttribute('href', item.link.replace('/in/set-369431','')); // Remove the "/in/set-369431" because I want links to be in "photostream context", not in "album context".
      link.setAttribute('title', item.title);
      elem.appendChild(link);
      let image = document.createElement('img');
      image.setAttribute('src', item.media.m.replace('_m.','.')); // Default photos in feed are 240px wide XXXX_m.jpg photos, but I want the 500px wide XXXX.jpg photos.
      image.setAttribute('alt', ' [Image: ' + item.title + '] ');
      image.setAttribute('loading', 'lazy');
      link.appendChild(image);
      fwall.appendChild(elem);
    });
    fwall.appendChild(document.createElement('li')); // End with an empty item.
  }
}
function jsonFlickrFeed(photos) { // Function to be called from JSONP feed (https://www.flickr.com/services/feeds/photoset.gne?nsid=10259776@N00&set=369431&lang=en-us&format=json&nojsoncallback=0)
  fwitems = photos.items;
  window.addEventListener('DOMContentLoaded', flickrWall, false);
}
</script>
<script defer src="https://www.flickr.com/services/feeds/photoset.gne?nsid=10259776@N00&set=369431&lang=en-us&format=json&nojsoncallback=0"></script>

HTML:

<ul id="fwall">
  <!-- Photos will be inserted here -->
</ul>

PS: I have noticed that some very aggressive privacy blockers (read: Ghostery) might block reading the JSONP feed. If that happens, there's no delicious photos to be seen...

Update January 2021: I have made different wall implementation with adaptive width showing new additions to a Flickr group, on my otherwise pretty dead Planet 7D site.

Hvordan stemte de siddende danske medlemmer af Europa Parlamentet om de nye EU Copyright Direktiver (Artikel 13/17 og artikel 11/15)?

Følgende oversigt fra SaveYourInternet viser hvordan, og det er faktisk et sørgeligt syn:

Dog befriende at se 74-årige Margrete Auken som en der i mine øjne ser ud til at have modenhed og overblik på IT-området.

Selvom de kommende medlemmer ikke kommer til at stemme om samme artikler igen, kunne det nu være rart nok at kende alles holdninger på området. Er der nogen der har spurgt de nye kandidater?

Update: Hvis man tjekker de andre lande, så danner der sig i øvrigt et billede af "parti-politik", idet medlemmer af Greens/EFA og GUE/NGL oftest har stemt imod de nye copyright direktiver (I de par lande jeg tjekkede i hvert fald).

Jeg har skiftet webhotel. Det er billigere end det gamle, men det er egentlig ikke årsagen. Årsagen var nye muligheder for teknisk opsætning der skal sikre bedre "renommé" og sikkerhed for rockland.dk som webside og min email adresse i særdeleshed.

Hjemmesiden...

Det eneste du nok umiddelbart kan se der er nyt, er at rockland.dk har fået hængelås i browserens adresselinje som viser der køres krypteret https protokol. Indtil få år siden kostede det ikke bare penge, men var også en ret besværlig proces at installere og opsætte sikker https kryptering på et website. Men med introduktionen af Let's Encrypt kom der ikke bare en gratis mulighed, men også en meget lettere proces. I mit nye webhotel er det bare er et simpelt valg i konfiguration at understøtte https med et Let's Encrypt certifikat. Og der bestilles og installeres automatisk et nyt certifikat når det gamle er ved at udløbe, både på PHP- og ASP-webhoteller.

Nu har du ikke brug for at logge ind på Rockland for at kommentere, eller kan foretage dig andet "følsomt" her på siden. Så strengt taget kan man sige kryptering ikke er særlig nødvendigt her. Men browser fabrikanterne tænder flere og flere "advarselslamper" i deres browsere når der surferes over ukrypteret forbindelse. Og det er nu rart at det ikke ser ud som om det er farligt at komme forbi rockland.dk :-)

Men det vigtigste i skiftet var nu i virkeligheden også de nye muligheder i email opsætning...

Email-adressen - DKIM, SPF og DMARC...

Så længe jeg har haft mobiltelefon, har jeg haft det samme mobilnummer. Og det er planen at det skal være konstant for livet. Jeg har derfor også fra starten været forsigtig med at smide mig omkring med det. Stort set alle webshop spørger f.eks. i dag om et telefonnummer når man bestiller, men de får ikke mit mobilnummer. Det omtrent værste jeg kan forestille mig, er hvis jeg en dag skulle begynde at modtage spam pr. sms. Så jeg gider ikke have mit nummer registreret alle mulige steder hvorfra det kunne blive misbrugt eller lækket. Og er det ude tilstrækkelig mange steder, sker det sidste med sikkerhed på et tidspunkt.

Helt så forsigtig var jeg desværre ikke med min email-adresse i starten. Udover at det var cool med eget domæne til sin hjemmeside, var formålet med anskaffelsen af domænet rockland.dk i 1999, at få en fast email-adresse for livet. En email-adresse der var uafhængig af af et aktuelt uddannelsessted, en bestemt arbejdsplads, en bestemt internet udbyder, eller bare en bestemt mail-service på nettet. Ergo, eget domæne var nødvendigt.

Men jeg var jeg ikke så tilbageholdende med at skilte med min email i starten. Og den kom hurtigt til at stå public og i klar tekst i mine indlæg på usenet og forums, i kommentarer til artikler og på alle mulige net-profiler. Desuden har jeg nok heller ikke i starten været særlig ukritisk med hvad jeg abonnerede på af nyhedsmails, eller tilmeldte mig af konkurrencer på alverdens sites, etc. Resultatet har selvfølgelig været spam. Masser af SPAM. Men det er nu ikke det værste.

Det værste er, at jeg efterhånden erfarede at min egne emails oftere og oftere blev fanget i spam-filtrene. Selv venner jeg havde skrevet med mange gange, kunne tilsidst risikere at skulle kigge i spam-mappen for at finde mine emails. Nu er det omtrent ligeså let at forfalske en afsender på en email, som det er at skrive falsk afsender på god gammeldags analog brevpost. Og det var tydeligt nogen misbrugte min email-adresse (eller i hvert fald mit domæne), så dårligt ry som mine emails efterhånden havde fået. Jeg mener, så "spammy" er jeg da normalt ikke selv?...

Så noget måtte ske for at genoprette tilliden til min email-adresse, og teknologier som DKIM, SPF og DMARC skulle gerne være svaret derpå. Nu vil jeg ikke komme ind på tekniske detaljer omkring disse teknologier - well, tildels fordi jeg heller ikke er helt skarp på detaljerne. Men det korte og det lange er, at modtagende mailsystemer kan verificere at emails som er afsendt med min email-adresse som angivet afsender, også er afsendt fra min mail-konto. Og med fuld DMARC opsætning kan jeg forhindre emails der misbruger mit domæne som afsender-adresse, i at nå frem til deres modtager.

På mit nye webhotel hos UnoEuro er det rimelig let at sætte support for SPF, DKIM og DMARC op. I hvert fald så længe alle ens emails bliver sendt igennem deres systemer. Man skal pille lidt ved noget DNS opsætning, hvilket man selv kan direkte fra sit "kontrolpanel". SPF og DKIM er rimelig ligetil at aktivere. For DMARC skal man først finde ud af hvilken politik man vil føre overfor emails der ikke kan valideres. Det letteste er at oprette en konto på et site som dmarcian og så lade dens DMARC Record Wizard generere din DMARC DNS record. Dmarcian vil så konstruere en record på baggrund af en wizard, og med opsætning så din mail-statistik sendes til en dmarcian email tilknyttet din konto for opsamling af data og generering af overblik som vist herover. Som en der er rimelig uvidende omkring opsætning af DNS-records, skulle jeg lige have bekræftet af UnoEuro's support, at det var i orden at fjerne eksisterende _dmarc.rockland.dk/CNAME record i min opsætning, for at gøre plads til den nye _dmarc.rockland.dk/TXT record jeg havde genereret på dmarcian. Man da jeg først havde fået at bekræftet at det var vejen frem, var første version af DMARC opsætning også klar.

Det er normalt at starte med en "blød" DMARC opsætning hvor man kun samler statistik om emails, og så senere konfigurere det så ukendte mails klassificeres som spam, og til sidst når man føler sig rimelig sikker på at alle ens egne mails er korrekt signeret, kan man sætte det op så ukendte emails helt afvises af mail-systemerne og aldrig kommer frem til deres modtager. De fleste privat-personer afsender nok kun emails igennem deres email-klient, men virksomheder kan have mange systemer der sender mails på firmaets vegne som man måske ikke har helt overblik over. I mit tilfælde havde jeg også en NAS som udsender en email ved "system-events", som jeg lige skulle have konfigureret til at bruge rigtige konto og mail-server, for at sikre at beskederne ikke blev behandlet som ukendte emails.

Som mail-klient bruger jeg i øvrigt gmail. Den kan sagtens sættes op til at bruge tredjeparts mail servere og konti til at hente og sende emails. Det har jeg nu gjort i mange år med 3 forskellige webhoteller. Det fungerer fint, og er dejlig fleksibelt.

For at DMARC opsætning skal have effekt, kræves selvfølgelig at modtagende mailsystemer understøtter teknologierne. Når det gælder "outbound support" lader det faktisk til at være en overraskende lille klub rockland.dk nu er medlem af. Men når det gælder "inbound support" er det mit indtryk at stort set alle mailsystemer og services har support for teknologierne, inkl. selvfølgelig de populære webmail-services Google, Yahoo og Microsoft tilbyder [Update: Microsoft dog ikke 100%]. Så jeg forventer at mails der misbruger mit domæne som afsender, vil blive afvist i langt de fleste tilfælde, og aldrig nå nogen modtager. Og jeg sover nu lidt mere forvisset om at mine egne emails når frem og ikke ender i spam-filtre :-)

Update: Cirka ét år efter jeg konfigurerede DMARC for mit domæne, stoppede misbrug af mit domæne som afsender-adresse for emails nærmest fra den ene dag til den anden. Min konklusion er at der kun var en enkelt spammer som bare brugte mail-servere spredt over hele Verdenen til udsendelse af spam. Og da vedkommende registrerede at mails med email angivet på rockland.dk som afsender ikke nåede frem til modtagerne, blev rockland.dk fjernet fra listen af domæner misbrugt til afsender.

PS. Lidt tips til at analysere mail headers og autenticiteten af emails.

Jeg kunne ikke forestille mig det kunne ske. Jeg ignorerede det totalt. Blandede mig udenom, vendte blikket den anden vej, og forsøgte at tænke på noget andet hver gang emnet blev nævnt. For jeg blev så deprimeret, frustreret og sur hver gang emnet var i mine tanker. Jeg stak fingere i ørerne, sang tralala - tralala - tralala, og gentog for mig selv at det-kan-ikke-ske, det-kan-ikke-ske, det-kan-ikke-ske... Men det skete.

Demokrati er vel grundlæggende godt, men det er en dag som i dag jeg bliver i tvivl. Jeg har længe tænkt at vores politikere ikke skulle have lov at tage beslutninger der vedrører det moderne informationssamfund. De har simpelthen ikke den krævede viden, forståelse og indsigt i området. I dag står den tanke kraftigere end nogensinde. Og nej, jeg er hamrende ligeglad med Google og Facebook. De er ganske ubetydelige i det store (informationssamfunds-)billede. Men der er nok kun dem politikerne har tænkt på.

Ok, vi må vente op til et par år til at se hvordan artiklerne implementeres i praktisk lovgivning. Og det kan vel i praksis ikke gå så galt som de scenarier jeg ser i mit hoved. Eller kan det?

Jeg er ikke den bedste til at stå tidligt op. Og da slet ikke når jeg har fri. Så det er ikke så ofte jeg ligefrem kommer ud på en morgen fototur, selvom det som regel er en meget god oplevelse når man for en gangs skyld kommer afsted.

Billedet her er fra en morgentur i Dyrehaven tilbage i slutningen af september i 2015, og er "fundet" i forbindelse med mit "2018 catching up" projekt. Jeg postede allerede et par stykker af scenariet på Flickr tilbage i 2015, men af en eller anden grund ikke alle dem der fortjente at komme ud. Og dette er måske endda det bedste i hele serien?

Jeg har husker tydeligt morgenen og situationen. Jeg ser det flotte modlys sceneri fra god afstand, og forlader stien for bevæge til et træ som jeg kan støtte mig op af imens jeg tager billeder på (hvad jeg syntes var) meget god og diskret afstand. Jeg tænker at det er et drømme setup jeg er havnet i, og følger mig ganske heldig imens jeg skyder løs. Jeg når både at nyde sceneriet og tage en del billeder, men der går ikke så længe før en mand kommer over til mig, og præsenterer sig som "parkbetjent" (eller sådan noget lignende). Han spørger høfligt, om ikke jeg vil fortrække og gå tilbage til stien. Det er ikke fordi der er nogen regler om at man skal blive på stierne, og normalt vil de ikke sige noget. Men lige netop på denne tid af året kan dyrene være mere stressede, og han så helst jeg gik tilbage til stien. Jeg må indrømme at jeg var lidt uforstående, da jeg synes jeg allerede stod på meget stor afstand [Teknik: 300mm tele på et 1.6x aps-c kamera, dvs. ækvivalent til 480mm brændvidde på 35mm fullframe kamera - og dertil er billederne beskåret lidt]. Så vidt jeg kan se på Google Maps har jeg stået på mindst 100 meters afstand til dyrene. Men det er jo ikke mig der er eksperten, og jeg følger selvfølgelig med ham tilbage til stien.

Jeg oplever måske aldrig et lignende scenarie igen. Hvis jeg var på morgentur jævnligt, måske. Men det kommer jeg jo ikke :-) Jeg har dog tjekket lokationen et par gange siden, og det er et sted hvor der er en tendens til flot smådiset modlys om morgenen. Men chancen for at dyrene så også lige står der når man er forbi igen... Men jeg nåede da heldigvis at få et par gode billeder i den tid jeg stod der, selvom jeg helst ville have været blevet stående helt til lyset eller dyrene forsvandt igen.

Catching up - Nytårsfortsæt uge 41-52 (2018)

Jeg har fejlet. Jeg kæmpede mig igennem 51 uger, hvoraf de sidste nogle gange var lidt en kamp. Men da jeg kun manglede uge 52 var jeg sikker på at årets nytårsfortsæt var i hus. Jeg havde ferie, tid, planer og motivation for at dyrke lidt stemningsfuld natfotografgering i byen i dagene op til nytår. Og det var så planen lige indtil en virus slog kløerne i mig, og jeg måtte tilbringe årets sidste dage i sygesengen med 40 i feber. Men hvis vi ignorerer at jeg principielt har fejlet mit fortsæt i årets aller sidste uge, og ser det i lidt større perspektiv:

• Glasset halvt fyldt: Jeg fik klargjort og postet en del billeder. Her i blandt fra et roadtrip til Bretagne & Normandiet og tur til Venezuela, som begge var i 2010 og var ture med mange gode minder og billeder jeg længe har ønsket at få ud.
• Glasset halvt tomt: Jeg havde nok troet og håbet jeg ville nå en del mere. Og imens jeg godt nok har spist i den ene ende af køen, er køen vokset i den anden ende med billeder fra Newfoundland og Lissabon. Så godt nok er køen lidt mindre nu end for et år siden, men selv hvis jeg fremad fortsatte med at poste med samme tempo som jeg gjorde i 2018, ville det stadig tage mange år at indhente det tabte.

Det har overhovedet ikke været overvejet at fortsætte mit "catching up" projekt ind i 2019. Jeg trænger til at trække stikket lidt på den front et stykke tid. Men jeg skal da have mere af det gamle ud, og for 2019 er målet nok at ende året i "status quo"; Dvs. med lige så meget ud som der er kommet ind, så køen i hvert fald ikke vokser. Nej, jeg når nok ikke til bunds i mine billeder, før en gang når jeg går på pension...

2018 Catching Up nytårsfortsæt - Alle "etaperne":

• Uge 41-52 - Rette tid og sted...
• Uge 31-40 - Når farverne går op...
• Uge 21-30 - Canaima
• Uge 11-20 - 24 timer ved Le Mont Saint-Michel...
• Uge 1-10 - Cambridge Circus, London 2009