Daniel Pietzsch

Posts

Webmentions

This site can now receive Webmentions. Either directly or via Twitter (with Bridgy’s help).

Webmentions are a standard and open way to send and receive common social-media reactions like “comments”, “likes” or “replies” via and on any site.

For this site here, I’m using Aaron Parecki’s webmention.io service to collect incoming reactions and Aaron Gustafson’s Jekyll plugin to cache and display them on this site. Thank you very much, Aarons!

For now, I’m only displaying new Webmentions whenever this site is re-build. That only happens irregularly and is far from real-time, but it is good enough as a first step. Though I still plan to utilise the plugin’s JS additions to display any Webmentions that queued up after the last rebuilt. Also, I currently only display “likes” and “replies”, simply because I didn’t get around to styling the other types, yet. So: still some things to do.

But for now: can someone please send a Webmention already!?



Guitar Gear Excitement

So, for Christmas I spoiled myself and bought new electric guitar gear:

I was looking for something more convenient to play through than always having to hook up the guitars to a computer via an audio interface, start the software, and connect to speakers. There was just too much friction involved in that process and I ended playing unplugged or not at all. And with this great sounding, portable, battery-powered amp, I simply need to plug in and turn it on.

And ever since doing the research for those two things, I got properly excited about guitar gear for the first time ever. Especially effects pedals have sparked my curiosity.

I have been playing guitar for a long time, but when it came to gear, I was never really all that interested: I had a two-channel amplifier and one main guitar, and that was it. It worked and it was all I needed.

But currently it’s a very different story: I read and watch a lot, I already have a full wish list of guitar pedals set up on the Music Store site and my favourite new Youtube channels are That Pedal Show, The JHS Show, Rig Rundown and Anderton’s TV.

I’m already so far into this as to having recently purchased my first two pedals:

Those two will hopefully inspire me to play even more. But I’m sure they will, as the Katana and the looper already did. New gear = new possibilities = new inspiration.

And now excuse me as I need to get back to my Strat knock-off to try and play some Jack White tunes through that new fuzz pedal.

My strat-like guitar on a sofa, connected per cable to the mini looper pedal and the Boss Katana Mini amplifier.
A sunday afternoon setup on the sofa shortly after christmas 2019.

Last week I discovered Royal Blood and was blown away! Just check out this festival gig:

They’re only a duo – a drummer and a bassist (!) – but produce an impressive (and innovative) sound. Have not seen anything quite like it. It’s like The White Stripes meet Muse and it’s brilliant!



New camera: the Yashica FR1

Last year, I acquired a few new cameras. One of them was a Yashica FR1 (or FRI, as it’s often written as) with a selection of lenses. It was a random opportunity. And I took it. Here are some first images taken with the 24mm lens I bought with it.

Self-portrait in a mirror, holding the Yashica FR1 to my eye. A pronounced all-white strip is on the right quarter of the image.
That's actually no light leak: it's simply the last shot of the roll.

Ever since my Nikon FE stopped working a while back, I was keen to get a SLR camera again. I actually wanted another Nikon – preferably a FM – so I could keep using the two lenses I have for the system. But since the Yashica came with lenses, I figured this could be my SLR for now.

The lenses I acquired with it are:

  • A 24mm ƒ/2.8,
  • a 28mm ƒ/2.8,
  • a 50mm ƒ/1.7,
  • a 135mm ƒ/2.8,
  • and a 70-210mm ƒ/4-5.6.

That’s pretty much every focal length I do not have for my Leica.

Zoe inside our campervan on the ladder that connects to the overhead bed.
24mm is great for the tight interior of the camper.

I find it practical to have a SLR as a secondary camera system, because both the cameras and lenses are (usually) significantly cheaper than for the Leica M system. And that makes it much more reasonable to try a different focal length or take the camera to places I deem unsafe for my Leica – like a swimming pool or the beach for example.

Zoe sitting at the beach, smiling and looking down into her glass of fruit with a spoon in her hand.
Getting close with a wide lens at the beach – a place I wouldn't take the Leica. Simply too much sand and water involved, plus I need to be able to leave the camera abandoned without constant worry.

I only shot a single roll with the Yashica this summer, but I very much enjoyed the experience – in particular the much wider field of view of that 24mm lens (normally I shoot with a 35mm focal length on my Leica). The camera allowed me to take photos I couldn’t or wouldn’t take with the Leica. Either because it’s simply a different focal length, the subject is too close – an SLR allows you to focus much closer – or it’s a location I don’t feel comfortable bringing my precious rangefinder.

Zoe inside a swimming pool, looking into an installed bucket play thingy.
Another place I don't feel comfortable taking my most expensive camera to.

The very wide angle is great when used in narrow spaces like our camper for example. And it also makes it much easier to include myself in the frame.

Holding my beer, saying cheers to Nicole at our camping table.
A cheeky afternoon beer. Super wide-angle for maximum being-in-the-moment photography.
Nicole and Zoe reading a book together inside the camper in the evening.

As is apparent from these sample images, though, I still need to fix the light leaks this camera has. I did shoot a test roll without any such issues when I got the camera, but the one roll I shot during summer – from which these sample images are taken – did have a significant amount of light streaks on its negatives. Fair enough, considering the camera was much more outside, not seldom in direct sunlight.

Our camper parked near a lake. We have our table and chairs next to it. It's sunny.
Zoe knee-deep in a lake, looking back at the camera.
A pretty extreme case of light leakage.
Bare feet in a clear lake.

Another problem my model has, is that the frame counter does not work; leaving you wondering how many images you’ve already taken with it.

A book in my lap.

Despite these minor annoyances, I’m happy I bought this camera. While this Yashica does feel a little cheaper than my old Nikon FE – i.e. lighter, more plastic-y, and less smooth in operation – it really does the job and was a pleasure to take pictures with. And the images from that 24mm lens look great to me, too.

Zoe in bathrobe in front of our oven, looking at the pizza that's baking inside.
Almost Pizza time.
Zoe in the bathroom, photographed via a reflection in the mirror, that also contains the camera itself and my two hands.
Much easier to include oneself with a lens this wide.

While my Leica M4-2 and a 35mm lens will certainly keep being my main setup, this Yashica SLR is a great way to occasionally spice up my images with a different field of view and have a different shooting experience.



Dark mode

While this site is new and super-simple, I thought I add an automatic “dark mode” real quick.

With “automatic” I mean, when your operating system is configured to prefer a dark appearance, this website will follow suit. There’s currently no other way to toggle this.

And I’m using CSS variables to implement this. I’ve used different approaches before, but this time I wanted to try this seemingly popular solution.

Basically what I did was putting all my colour definitions into one CSS variable each and declare those within the :root selector:

:root {
  color-scheme: light dark;
  --background-color: #F9F9F9;
  --header-background-color: white;
  --text-color: #222;
  /* etc. */
}

Then, you can overwrite the variables’ values further done in the file for when the OS prefers a dark colour scheme:

@media (prefers-color-scheme: dark) {
  :root {
    --background-color: #222;
    --header-background-color: #111;
    --text-color: #dddddd;
    /* etc. */
  }
}

CSS Variables enjoy good support right now, but I still decided to offer a fallback for browsers that do not support them. That way my default (bright) theme will render properly in all browsers. So, all CSS rules that use variables will always have a fallback. Like so:

background-color: #F9F9F9;
background-color: var(--background-color);

To get rid of the duplicate variable declarations, I use SCSS variables to only define them once. For the final CSS file, those SCSS variables will of course be replaced and converted into actual values during the “build” step of this site. So a complete source example actually looks something like this:

/* SCSS variable definitions */
$background-color: #F9F9F9;
/* ... */

/* CSS variable definitions */
/* Using the SCSS variables as the source */
:root {
  color-scheme: light dark;
  --background-color: #{$background-color};
  /* ... */

  /* CSS variable definitions for dark mode */
  @media (prefers-color-scheme: dark) {
    --background-color: #222;
    /* ... */
  }
}

/* Usage with a fallback. */
body {
  background-color: $background-color; /* using the SCSS variable as a fallback, which will get replaced for the final CSS stylesheet */
  background-color: var(--background-color);
  /* ... */
}

Using CSS variables of course means that browsers without support won’t be able to “see” the dark site. But as far as I know, operating systems that offer “Dark Mode” are so up-to-date right now, that their (default) browsers will, too. So, there’s really nothing to lose here. Until I maybe add another option to toggle dark mode manually. But that’s a topic for another day.



Responsive images

I have now added the ability to display responsive images on this site.

And just as with my photo journal, I’m using the fantastic jekyll-responsive-image plugin1 to do so.

What I did differently this time, though, is that I can use the standard markdown syntax for images, instead of using the custom liquid tag. There are a few reasons for why I wanted it this way:

  • Markdown syntax is nicer and more convenient to write,
  • I will have less Markdown source files be “littered” with liquid syntax,
  • it hides the complexity that comes with responsive images, and
  • it will enable me to use more standard tooling that only works with the Markdown syntax, while still enabling me to create posts with responsive images.

Replacing Liquid syntax with Markdown

In order for this to work, I can run some code in a pre-render hook that replaces the standard markdown syntax with said custom liquid tag before Jekyll actually converts the file to HTML.

This pre-render hook needs to basically translate the Markdown image syntax to the liquid tag that the jekyll-responsive-image plugin expects. E.g., I want to replace syntax like this (in standard markdown notation):

![alt text](image.jpeg "The title for this image")

…with something like this (which will be the source Jekyll uses to convert to HTML):

{% responsive_image path: image.jpeg alt: "alt text" title: "The title for this image" %}

The Regular Expression

And in order to do so, I need to parse all those different parts of the markdown syntax – image path, alt text, and title text – so I can reuse them when it comes to constructing the liquid syntax. Here’s the regular expression I found to be working – with alt- and title-attributes both being optional:

^\!\[(?<alt>.+)?\]\((?<path>\S+) ?"?(?<title>.*?)"?\)

The Prerender Hook

Here’s the complete code from the pre-render hook2, that does its thing each time right before a markdown file is converted to HTML3:

Jekyll::Hooks.register [:pages, :posts], :pre_render do |post, payload|
  document_extension = post.extname.tr('.', '')
  # Only process if we deal with a markdown file
  if payload['site']['markdown_ext'].include? document_extension
    new_content = post.content.gsub(/^\!\[(?<alt>.+)?\]\((?<path>\S+) ?"?(?<title>.*?)"?\)/, '{% responsive_image path: \k<path> alt: "\k<alt>" title: "\k<title>" %}')
    post.content = new_content
  end
end

An example

In addition to serving the original file, I decided to generate five smaller versions: 320, 640, 960, 1280, and 1920 pixels wide respectively.

And here’s the first responsive image in a blog post:

Zoe and some rubble
  1. My own fork, though, to be precise. 

  2. Thanks to David Jacquel for the original version

  3. And of course, I ran into problems while writing this very article: Since the hook simply processes the whole document – without paying any attention to markdown-specifics, it would have also replaced the standard-markdown-image-syntax code example above. To circumvent the problem, I added the ^ to the regular expression, so that the hook only replaces those occurrences that start at the beginning of a new line. Because then I could use Markdown’s indent-four-spaces-for-code-markup syntax (i.e. not at the start of a new line), which was not replaced – and instead renders the example above, as intended . 


Hosting on GitLab Pages

This site is currently hosted and deployed using GitLab Pages. I say “currently”, because I’m not sure, yet, if this is feasible in the long term. My main concerns are storage space, server location and configurability (in that order).

But for now I’m very pleased with this setup. Actually in fact, I feel almost naughty for leveraging their automation pipeline for free and have this site built and deployed automatically. And to be honest, the less configurability has rather been a feature than a shortcoming so far, too. Because I currently don’t need to worry about server maintenance and settings at all.

Here’s a random and probably incomplete list of pros I noticed while configuring my GitLab Pages setup:

  • Good documentation
  • HTTP/2
  • Reasonable HTTP cache headers
  • Trivial deployment
  • Auto-renewing Let’s Encrypt certs for serving this site over HTTPS
  • Automatic redirecting of HTTP-requests to HTTPS
  • Ability to use any Jekyll plug-in (unlike just a subset like with GitHub Pages)
  • Free private repository support (also unlike GitHub Pages)

So, can’t complain. Can recommend!


I was actually thinking that I might have seen enough Opeth gigs by now. But no! Last night in Cologne was the best one I’ve been to (yet)! Great setlist, great light show, and – as always – great musicianship. Very happy we went.


It’s the time of year where I generally push my films to ISO 1600. And that means I now need to slightly readjust my brain again for guessing exposure.

And in April it’s all back to ISO 400 again.



Fuck you, Instagram!

I made a little bookmarklet to disable and hide Instagram’s login prompt and re-enable scrolling, so I can keep browsing Instagram web pages when I am logged out. I call it “Fuck you, Instagram!” or “FUI” for short.

Just drag the following link to your browser’s favourites-/bookmarks-bar: → FUI ←.

I need this, because I don’t have an Instagram account (and am therefor always logged out), and so I get prompted to sign in all the time. But now I can click this bookmark and I’m back to browsing.

Unfortunately, this only seems to work on desktop browsers. On iOS, the modal disappears, but then scrolling is disabled afterwards. Maybe I’ll get around to fixing that, too.

And I’m not sure how long this will continue to work like this at all. But if it’s not much trouble, I’ll make sure to update it so it keeps working with their latest markup.

For anyone who’s interested, here’s the code:

document.body.setAttribute('style', 'overflow: initial');
document.querySelector('div[role=presentation]').remove();

Recent film development fuckups

This week I had two film rolls come out of the tank with really thin negatives. And I’m pretty bummed about that. I’m pretty sure, the film simply got underdeveloped because of bad developer. That’s what it looks like and makes sense to me.

At the very least, I hope that’s what it is. Because the alternatives would mean I either underexposed all shots on both rolls, or pretty much all shutter speeds on my Leica are too short. Both of which are highly unlikely. I suspect the reason was my pretty newly mixed XTOL developer. This time I stored around 600ml of it in a 1-litre bottle that I haven’t used for developer before. And this is an old bottle of fixer. And I guess this might have affected the solution negatively. I thought I washed this thoroughly, but apparently I didn’t – or I couldn’t. Anyhow, for the next batch I’m going to use the XTOL from the containers I know are fine.

[Update 02.11.2019]: The next two films using XTOL from the “safe” containers were perfectly fine!

And the week before, I noticed too late that my fixer was exhausted. Apparently, the Adox fixer I’m currently using doesn’t last as long as the one from Ilford, which I normally use. I’m used to getting at least 25 films fixed from a 1-litre solution, but the Adox solution did only manage 15 or so.

When I noticed, I made new solution and fixed the last two films again. Because they were still uncut and hanging in the shower. But there are still at least two films that are still under-fixed, and I’m not quite sure if I want to re-fix them, too. Because they are already cut into strips and in their sleeves. Which means a whole lot of effort to get them fixed again.

The “joys” of film photography I guess.

[Update 01.01.2020]: The underfixed negatives happened to me again. It’s often really hard to spot. But I think I found what it was: I diluted Adofix too much. I only looked at the bottle’s label, which states to “dilute 1+9”. But after researching this fixer a little bit, I found you should actually dilute it 1+4 for film fixing. Damn.



New website

I have a new site! It’s truly indie now. No more reliance on Tumblr. And I’m pretty happy about that! So, danielpietzsch.com is going to be my virtual home for the foreseeable future.

The site is build using Jekyll – no surprise here. I simply like the main tool to be written in my favourite programming language, Ruby, because that makes things very familiar for me. Plus, I’ve used Jekyll before anyway.

I decided to host on GitLab Pages, at least for the first while. GitLab can automatically build and deploy this site. It’s a joy to use and makes publishing very easy and convenient once configured.

As one can see, the whole site is still very bare-bones as I focused on the basics only so far: hosting and deployment workflows, deciding on site- and URL-structure, how to organise posts with Jekyll internally, and writing the basic markup and CSS. I can always extend and improve as I go.

But it’s a working right now and I can start posting again. And – more importantly – I feel like posting again. Yay!