I've recently upgraded my Infrared camera from a self-converted Canon EOS M, to a professionally converted Canon EOS M5. I converted the EOS M myself to a full spectrum camera, when I upgraded my primary camera to a Canon EOS M5. Converting the camera was an effective way to keep the old camera useful, but the quality of the conversion, and the poor high ISO performance of the EOS M sensor, meant I was pushing the limits of what the camera could produce. The time had come to upgrade to a better quality system.

Choosing which camera is a personal preference. Most cameras will convert to full spectrum or Infrared pass. As I already have an EOS M5 as my primary camera, along with a handful of EF-M lenses, as well as adapted EF and EF-S lenses, being able to share lenses between my primary camera, and my infrared camera made a lot of sense, and it helps everything fit in my Lowepro Protactic 350 camera bag. Another factor is cost. Cameras aren't cheap, especially when you add the cost of converting to full spectrum or Infrared. Canon appear reluctant to continue with the EOS M series cameras and lenses, and instead focusing on the newer EOS R system. Normally this would put me off buying into an obsolete system, but for my requirements, this actually works really well, as the second hand market has plenty of EOS M cameras and lenses at very affordably prices.

I paid £279.00 with MPB (https://www.mpb.com/en-uk/product/canon-eos-m5) for an excellent condition second hand Canon EOS M5. This is a 24mp camera, with good low light/high ISO performance, and It's light and small, making for a great travel camera. For the conversion, I paid £280 with protechrepairs.co.uk for a 720nm conversion. The service has been pretty good, and I'm so far impressed with the results.

Lens choice for Infrared is a lot harder to plan for, and often requires just trying different lenses to see what works best. Many lenses suffer from hot spots, this is when infrared light falls uneven on the sensor and causes an overexposed patch in the centre of the image. There is no easy way to know if a lens will work well, often older and simpler lenses will work best, but a there are specialist lens databases published by kolarivision and LifePixel that provide good options to check based on your lens mount type. There is also the excellent work carried out by Edward Noble.

I tend to prefer wider lenses for most infrared images. This partly for composition, infrared works well for landscapes as well as urban photography, but it's also for a technical reason. Infrared light diffracts faster than visible, meaning that you likely won't be using small apertures. To ensure a decent depth of field at larger apertures, it's best to use a wider angle lens. Cameras converted to infrared will also be capturing less total light, so you'll be wanting a lens that capture as much light as possible.

For my infrared setup, I have the EF-M 22mm F2, and the EF 40mm F2.8. Both of these lenses offer great infrared performance, great image quality, respectable low light performance, and both lenses are also very small. If required, I can also my full range of lenses from my primary setup, covering 10mm to 200mm, however, not all of these lenses are well suited to infrared, and usually require additional post processing to correct any lens flaring, Infrared Hotspot and refraction at wider focal ranges.

All photos on this page are taken with this new setup, and processed via Adobe Lightroom with Rob Sheas Infrared Profile pack with custom LUTs applied. I cannot recommend Robs website and Youtube channel enough for tutorials in Infrared Photography and Infrared Processing.

In my day-to-day work, I spend a lot of time working with JSON, and and one of my favourite tools for working with JSON is jq. Jq is an excellent tool for working with JSON on the command line … however, I can never remember what arcane syntax I need to use to accomplish the simplest of queries. So, as any mediocre programmer, I built my own jq in my favourite language, Ruby.

How it works

rjq is a very simple program, in fact in it's original release, it's just 3 lines:

#! /usr/bin/env ruby
require 'json'
puts eval(%{JSON.parse(STDIN.read)#{ARGV[0]}})

If you're familiar with Ruby, this should all make sense … and you've probably noticed that eval call, yes, the user input to rjq is just superglued on to the back of the instantiated Hash or Array from the JSON.

Examples

We'll use the GOV UK bank holidays API as an example data source.

Firstly, we'll just get the top level keys in the dataset:

~/ curl -s https://www.gov.uk/bank-holidays.json | rjq ".keys"
england-and-wales
scotland
northern-ireland

Next, we'll use a simple Ruby enumerable map to return a new formatted list of bank holidays in England and Wales:

~/ curl -s https://www.gov.uk/bank-holidays.json | rjq "['england-and-wales']['events'].map{|e| %(#{e['title']} #{e['date']} #{'🎉' if e['bunting']} ) }"
New Year’s Day 2016-01-01 🎉
Good Friday 2016-03-25
Easter Monday 2016-03-28 🎉
Early May bank holiday 2016-05-02 🎉
Spring bank holiday 2016-05-30 🎉
Summer bank holiday 2016-08-29 🎉
Boxing Day 2016-12-26 🎉
Christmas Day 2016-12-27 🎉
New Year’s Day 2017-01-02 🎉
Good Friday 2017-04-14
Easter Monday 2017-04-17 🎉
Early May bank holiday 2017-05-01 🎉
Spring bank holiday 2017-05-29 🎉

Should I use this?

As you can see, it's just simple Ruby, however, there is that eval command in there, which has the potential to introduce security concerns. You should always check the JSON datasource is trusted before operating on it.