Over the Easter break I spent some time making changes to this blog so that the posts from 2004 through to 2014 are displayed in the style in which they were originally posted rather than the current theme. This might seem like an odd thing to do: these old designs do not conform to modern layout standards, nor are they optimised for the typical screen resolutions in use today. However, as I looked through the older posts, some of them had visual oddities where the original formatting had not translated properly to a new theme, and even when the formatting was OK, there was something odd about reading text written 15 years ago but presented in an up-to-date way.
I was able to implement this by creating a directory structure for the older years and populating it with static files for the older posts. The default WordPress configuration means that if these files and directories exist then they are served instead being given to WordPress to render dynamically. The easiest way to generate the static pages is to use the Preload setting of the WordPress Super Cache plugin, then copy the files it generates from
wp-content/cache/supercache to the correct location. Before doing this you should review your theme to make sure that any time-sensitive dynamic content (for example, an instagram feed) is turned off, otherwise the generated pages will remain stuck with today’s content which which may look rather odd in a few months time.
One problem I encountered is that my initial approach broke some of the auto-generated year archive pages (e.g. /tooBusy/2005). The monthly archive pages were produced consistently, but the year ones were sometimes missing. I used the curl command to fill in the missing ones, but it also highlighted that any private posts will no longer appear in these year and month archive pages when you are logged in, although they will be shown in other views such as tags and categories.
Executing this for posts using two older themes, presented a slightly harder problem. I did not want to reconfigure my live website while I experimented with this setup, so I spun up a copy of WordPress on my laptop using Docker and loaded into it a backup of my live website. I then used the WP2Static plugin which, in addition to generating the files, can also post-process them to change any references to the web server running on my laptop to the correct one.
I reviewed many, but not all, of the generated files—if you spot any problems, please let me know. Getting a good quality result using an offline copy of the website took considerably more time and effort than I hoped, but looking through those older posts I am struck by how much better many of them look in their original style, while I find the current theme to be equally good for more recent posts. WordPress continues to offer a first-class writing experience for new posts, and the fact that the same software is still running this blog after 16 years is a triumph of longevity and backwards compatibility. The existence of practical solutions for migrating away from it are just another point in its favour.
Despite its reputation for flashy graphics, macOS has a number of nifty features and shortcuts for terminal users. Here are some of my favourite keyboard shortcuts within the Terminal application itself:
- ⇧⌘a (“shift-cmd-a”) to copy the output of the last command.
- ⇧⌘v (“shift-cmd-v”) to paste the currently selected text.
- ⌃⌘v (“control-cmd-v”) to paste escaped text.
The following keyboard shortcuts work in other applications:
- ⌥⌘c (“option-cmd-c”) in Finder will copy the path to the selected file(s) (via @scriptingosx).
- ⇧⌘. (“shift-cmd-fullstop”) toggles
show hidden files, even in file open/save dialogs (via @howardnoakley).
- ⌃t (“control-t”) transposes the two characters to the left of the cursor (via @eWhizz).
While testing the copy & paste shortcuts in this post, I also discovered—after 15 years of being a Mac user—that Finder has the ability to show the current contents of the clipboard (Edit→Show Clipboard).
A combination of a growing volume of personal media from 24+ megapixel cameras/4k HD video-recording phones, the switch to smaller solid-state internal drives, and the increasing life-span of our desktop computers, means that at some point you are likely to find yourself needing to offload data to an external storage device. Having gone down this path earlier in the year I thought I would share my experiences with the WD My Book Duo.
Continue reading “MacOS External Storage Setup”
Since I have recently written about and recommended multiple Extensions for Apple’s Photos.app, I thought I would share a link to this article by the author of the RAW Power application on what happens “under the covers” when using an Extension. It also covers the difference between an Extension and the “Edit With..” functionality. What is happening is far more complex than you might imagine and will probably explain various inconsistent behaviours you may have observed.
A few months ago I noticed that the home page of this site was taking multiple seconds to load. Common wisdom is that a “good” loading time is under 200ms, and even though a photo blog such as this might be a bit slower than a text-heavy site, multiple seconds is just too long to wait.
The best lead I had as to why this was taking so long was the comment inserted by the WP Super Cache plugin at the bottom of every page recording how long it took to generate in seconds. This was frequently more than 3 seconds which suggested that the problem was either my web server being too slow or a problem with my WordPress setup. Discounting the first as unlikely, I did some reading up on WordPress performance-tuning. The most practical advice was to minimise the number of plugins you use, and turn off each plugin in turn and check the effect on load-time before and after. I use few plugins but had been fond of Flickr Justified Gallery for displaying my Flickr-hosted photographs, and of course this was the culprit. The problem is not the plugin itself but Flickr’s own API—generating each gallery requires a query to Flickr to retrieve the list of photos in the album.
My preferred solution was to host my own images. This blog is 14 years old now and as I learned last year, third party services can disappear or change unexpectedly. Sadly the built-in gallery layout with WordPress 4.x remains an old-fashioned looking grid of square thumbnails that can fail to represent the underlying photograph properly (example). The JetPack add-on comes with a more attractive gallery layout but automatically uploads and serves all your images from their servers, which has its own downsides.
I looked at a number of third-party gallery plugins but anything outside the WordPress core also has the same “third-party risk” as Flickr: the code could stop working in the future, breaking all my old posts. None could also match the slick efficiency of Flickr’s upload workflow for optimising, arranging and captioning images. Fortunately while I was investigating this, WordPress released their new Gutenberg Editor. This comes with a new Gallery, the first version of which was a bit buggy but has the modern look that I wanted, and has improved over the last few months. (At time of writing there remains a bug where clicking on any photo in a gallery displays the first photo in the gallery not the one you clicked on. This is due to be fixed in mid-January.)
Switching to the new gallery improved page-generation times but without Flickr to optimise my images, I need to do this prior to upload to keep page-load times acceptable. This involves a two-step process:
- Use ImageMagick to resize images to no more than 2048 pixels on their longest edge: mogrify -resize 2048x2048 *.jpg (be careful, this changes the original files!)
- Reformat to be progressive JPEGs and apply lossless optimisation. There are a number of tools that can do this but ImageOptim is an efficient open-source drag-and-drop option for MacOS.
The final tweak, as recommended by Google’s PageSpeed Insights tool, was to defer offscreen images. This should make the initial page render faster by not loading images that are not yet viewable, and was already available as part of the Jetpack add-on (Lazy Load Images).
On1 Photo is one of the many editing applications I use to process my photographs. I have previously written about my journey from using a single application (Apple’s Aperture) to many so an update post about the latest version seemed overdue. [Due to a delay in publishing this article, RAW 2019 is now available and 2018 is no longer the latest version!]
The upgrade from On1 Photo 10 to On1 Photo RAW had been a bit bumpy. The new features were great but some older ones had not made the transition. While I did not directly experience too many bugs, there were frequent bug-fix releases with the consequence that it seemed like every time the program was opened it wanted to update itself, interrupting my photo editing session. Consequently I did not rush to upgrade to the 2018 version when it was announced, the new features were not initially compelling and the current version was working well enough.
A few months ago I received a significant discount offer to upgrade. (This was before On1 had announced the 2019 version.) I also noticed that their most recent point release (free upgrade within the 2018 version) had added the ability to manage RAW+JPEG pairs in Browse. Since this is how I shoot, I had found managing the sets of files separately to be tedious and been looking for a better file management solution. I was also looking forward to trying out the panorama feature since I capture them too infrequently to invest in dedicated panorama software.
Immediately after starting with Photo RAW 2018 I realised that this was a more significant upgrade than I had expected. The interface felt comfortably familiar but also subtly tweaked to be more streamlined to use. The performance was significantly better too—I could not help feeling that this was how Photo RAW should have been at release, and had now arrived after 18 months of feedback and iterative improvements.
If you were disappointed with the initial release of On1 Photo RAW then I can thoroughly recommend the upgrade to the 2018 version if you have not settled on some other tool instead. I have not upgraded further to the 2019 version, for similar reasons to why I did not upgrade to 2018 at the beginning. I am also waiting for Luminar 3 to be released since its promised libraries feature is very similar to the browse functionality that I use extensively in On1 and it will be interesting to compare them before committing my money. If you have yet to try On1 Photo RAW then their extensive collection of video tutorials is the best starting point—they can really help you understand how to get pleasing results from it.
The use of Adobe Photoshop® to edit photographs is so ubiquitous that to photoshop became a verb. Photoshop is an incredibly powerful image manipulation program for which the only limit is your imagination, or possibly your knowledge of how to drive it. Given then the maturity of the market, a surprising number of new applications have appeared in the last 18 months. Many of these delineate themselves from the metaphorical 800lb gorilla by providing a very different user-interface paradigm to that of Photoshop, often the “filters” approach popularised by Instagram. This has enabled them to appeal to the large and rapidly growing market of casual photographers for whom the cost of Photoshop’s monthly subscription model is unsuited.
Of the applications I have tried, each one has its strengths and are continuously improving. Consequently I now have a toolbox of different apps I use when when editing a photos but fortunately Apple’s Photos.app makes it very easy to call upon each one as the situation demands.
DxO OpticsPro for Photos: A specialist application with just three functions that earns its place for its tremendous noise reduction. The lens correction and haze removal can also be very useful, and the small number of functions make it quick and easy to use.
RAW Power: I have previously written about this application and continue to find it indispensable for adding advanced RAW editing facilities to Photos.app.
On1 Photo RAW: This is currently my primary tool for comparing and culling photos prior to loading into Photos.app, and occasionally when selecting for publication too. It has a great “Compare Mode” for comparing an arbitrary group of multiple images side-by-side full-screen—a feature that Apple removed from iPhoto in 2010 and still has not been restored in Photos.app. This is also the only tool to provide an edge-detecting brush for creating masks. The filter-based editing approach can produce some impressive images but knowing which filters will achieve the desired result requires considerable retained knowledge acquired through experimentation or watching On1’s excellent and extensive selection of tutorial videos.
Luminar: Similar in concept to the Effects module On1 Photo RAW this provides editing through the paradigm of tuneable filters, which can be masked and stacked to produce an output that ranges from subtle enhancement to heavy stylisation. Luminar wins its place in my toolbox because the filters and presets are more accessible than those in On1—it is easy to see what needs to be done to a photo to improve it and choose the appropriate filter to achieve that. Another reason to like Luminar is that while it is now available on multiple operating systems, its native Mac origin means it seems to integrate much better with the MacOS than On1.
Polarr's approach to editing is closer to that of Photos.app: a series of sliders grouped into adjustment blocks of a technical theme. The controls are significantly more sophisticated than those in Photo.app and it also allows some adjustments to be applied to selected areas (masking). There are some interesting presets of the “highly stylised” variety. The face detection is impressive but the automatic enhancement is completely over the top to the point where it noticeably changes the features of the subject. Overall it is an impressive app, but except for the presets and face detection it requires technical skill to understand how to get the best out of it and I do not find myself reaching for it very often.
All of these apps, except RAW Power and DxO OpticsPro for Photos, are available for Windows as well as MacOS.
Whilst browsing the Google Search Console for this site I noticed that some of my older image galleries were returning errors. This gallery is run by 15 year old PHP code that I occasionally have to hack to keep running on newer versions of PHP so it was not a complete surprise that it might need some fixing. I should pay more attention to webserver upgrade notices though as the logs indicate it has been broken since 1st October.
The error was a bit puzzling at first:
PHP Parse error: syntax error, unexpected end of file
but eventually a helpful StackOverflow page made me realise that I needed to replace all instances of
<?php and the problem was solved.
During testing of the fix I found a more serious problem. All my links to picasaweb albums where I had hosted my photos from 2008 and 2009 were dead. This was unexpected since Picasa was run by Google and even though they replaced the service with Google Plus/Photos, I knew all my photos and albums were still online at the latest incarnation of Google’s service and I had trusted that Google, a company who place high importance on links for generating their search results, would not break links. It turns out that my trust was mis-placed as Google had broken some links but not others. Any link containing a username was broken but a userid would still work. So, if I could find my user id I could restore the links. Fortunately my Picasa user id turned out to be the same as my Google Plus user id, and because this was only a small number of posts over a 2 year period I could work through each one and replace the user name with that id to repair the link. There were a few direct links to photos that I was unable to repair because the URL did not contain my username.
These problems make me want to reconsider whether my current photo hosting solution with Flickr is the right one. While WordPress has improved since 2015, and has add-on features to make photograph-heavy websites go faster, those add-ons are still third-party integrations so these potential problems of what is known as “link rot” remain. I have recently been thinking about some of the other disadvantages of using WordPress, but I shall leave those for another post.
As of last week, the toobusyto.org.uk domain is now configured with a Sender Policy Framework (SPF) DNS record. This is a special type of DNS record which identifies which mail servers are allowed to send mail on behalf of toobusyto.org.uk users.
The aim of SPF is to prevent the unauthorised impersonation of users, a tactic frequently used by spammers. In practice it is not reliable because it can cause problems for a number of legitimate use cases related to mail forwarding, including mailing lists. In fact, Google explicitly recommends configuring an SPF record for “soft” failure rather than hard failure because of these issues.
The record was easy to setup once I realised which servers I needed to include. I send mail from toobusyto.org.uk directly via mail.toobusyto.org.uk, which is a CNAME to another system, and occasionally from Gmail’s web interface. Google have clear instructions on how to permission the latter but use of CNAMEs in SPF is discouraged to prevent receiving servers needing to perform an excessive number of DNS lookups so it is necessary to hardcode the name of the target of the CNAME. There is a risk the two can become out of sync but hopefully this is mitigated by the proximity of the two records in the BIND file. You can query the current record using your favourite DNS client but for the record the initial setup is:
; SPF record
toobusyto.org.uk. IN TXT "v=spf1 a:saturn.retrosnub.co.uk mx include:_spf.google.com ~all"
The result is that Gmail can now successfully authenticate me as a sender and for many users no longer shows a red question mark next to my name. Some experimentation has shown that the red question mark can still be present where I have emailed email@example.com and he or she forwards to a Gmail account because their.domain.com is not authorised to send mail on behalf of toobusyto.org.uk. This is actually the no worse than those users experienced prior to the configuration of the SPF record and some quick research turned up some forum posts that indicate there are potentially steps email forwarding services can do to mitigate this, although it was not clear whether the mitigation was feasible and/or effective.
One of the power features lacking in Apple’s Photos application is the ability to tweak the built-in conversion from RAW to JPEG. The now-discontinued Aperture application allowed manual control of these RAW conversion settings giving the photographer the ability work with more of the captured data to unlock hidden detail without needing a separate specialist application.
RAW Power is a Photos extension that enables this fine-tuning from within Photos. I learned from a YouTube interview with the Developer that he is the former dev lead for Aperture, having left Apple over a year ago, which suggests to me that Apple will likely cede advanced editing functionality to third party developers as I previously speculated.
As a tool with a very specific purpose, its focus makes it simple and effective to use. The interface is clearly laid out and performance nimble, and if it becomes apparent that RAW modifications are not able to improve the photo then you can cancel your edits and return to Photos with one-click.
RAW Power currently costs £9.99, and although this is labelled as promotional pricing, it is my opinion this represents very good value.
In moving to my fifth iPhone I decided it was time to try a fresh install instead of transferring state from my previous one. Apple’s transfer process has always worked works seamlessly but that Star Trek-like transportation of your old phone to the new makes the new one seem, well a little less new somehow. Previously I would have feared losing something small but vital by not using the transfer process but with so much now synchronised between devices by iCloud, it seemed that the most painful and important items were covered. My willingness to experiment was also mitigated by the knowledge that if it all went wrong I could still re-install the new phone from my old backup.
Without the need to wait for a gigabyte of data to be transferred to the new phone, I was up and running very quickly and enjoyed seeing what differences there are between an out-of-the box configuration and my own. With the exception of turning off the sound and vibration notifications for new email, I have customised very little to start with: I want to see if there are any settings or features I have previously overlooked because of some decision I made 7 years ago. Working through my list of apps and choosing to only reinstall those I know I have used recently was also enlightening—there were applications I had forgotten existed buried in never-opened folders, and including some that now crash on startup. I noticed others that are no longer being updated but the developers have instead issued a whole new app instead. I learned that the telltale sign for this is when you tap on the application in your “purchased” list and it fails to display anything about it.
Having chosen which apps would survive the migration and downloaded them all, the main pain point was having to re-authenticate in all of them. The reduced number of apps kept this manageable and I would guess about 50% enabled the use of iCloud Keychain which made it a two-tap process. Given the tedious and error prone nature of typing in a complex password onto a phone keyboard I am shocked that the other 50% do not enable this. Those apps which forced me to lookup and retype my password are certainly strong candidates for deletion if there is an alternative.
By not restoring from backup, any applications that store state locally and not in the cloud would lose their data. I was a little worried about my Angry Birds progress but then realised I had not played the game in a very long time anyway, and so far I have discovered only one application which stores data I would like to keep. It is a free app and its paid for version supports data export, which seems fair enough. WhatsApp messages were restored from its own iCloud backup (which it performs nightly) but I did lose my SMS and iMessage history (going back to 2008). Recent iMessages are on my mac anyway and after reviewing the older messages they were all very temporally contextual—“I am here / outside, where are you?”—type stuff. It is noticeable how much longer messages have become recently, perhaps an inevitable consequence of removing the 160 character limit of SMS.
In conclusion, unless you have apps or games that depend on local data, setting up from scratch was not at all painful and it felt really good to have a spring clean. Deleting something always requires metal energy to assess its value, or downside of its loss, and with storage so cheap it is rarely worth the effort. Consequently we accumulate bits and bytes rather too easily, and sometimes a platform migration is a good moment to assess what is no longer required, and start afresh.
Subscribing to a blog via RSS remains a niche and decidedly geeky activity. Having said that, Apple devices now come with a built-in News.app which, for all the usual Apple gloss, does use RSS. To view this blog in Apple News, visit this link on your iPhone or iPad and tap the + sign in the top right hand corner to subscribe.
If you do not use News.app, Safari’s shared links feature (the @ tab in the bookmarks pane) also allows you to subscribe to this and many other blogs.
In my post, A macOS Photo Editing Workflow, I admitted to taking the somewhat unorthodox position of capturing both RAW and JPEG versions in-camera and normally working with only the JPEG version. The conventional wisdom in photography is that RAW is the more flexible option, providing greater opportunity for correcting and improving the image in post-processing than when the camera is allowed to make all the decisions on your behalf. There are traditional reasons for not using RAW files such as the increased file size, but these are normally only relevant in specific situations—there seems to be few generic reasons not to use RAW unless you are operating under specific constraints.
I was therefore intrigued to see a recent article entitled, Is RAW Dead? in Photography Week. In addition to examining all the usual issues, it points out that in-camera JPEGs are now so good that in the majority of situations the camera will probably do a better, or at least no-worse, job of rendering the final image than you. This makes sense: unless you actively tweak the settings in your RAW processor then you are simply handing the conversion over from one algorithm (your camera) to another (your RAW processor), and while in the past the processing ability of a camera was limited compared to that of a PC, the advances in mobile chips and image processing have removed the PC’s previous advantage. Moreover, since the JPEG output is the version seen by potential buyers and new owners of their products, the camera companies themselves are highly incentivised to make the JPEG output as attractive as possible. The article does list a specific benefit of RAW as being able to recover an additional 1-2 stops of highlights and shadow detail compared to JPEG, although it also points out that a wider range can be obtained using the camera’s automatic exposure bracketing or even built-in HDR.
For the moment I will be having my cake and eating it by using RAW+JPEG: JPEG for convenience but with the RAW available as an option should the trade-offs and technology change in the future.
This is part of a series of posts describing my move from Apple’s Aperture to Photos.app for managing and editing digital photographs. Previous entries include a feature comparison, third party applications and extensions.
Although Aperture has not received a significant update in three years, I did not feel it was deficient in any way. Having now used a number of recently released other applications in the last few months I have now become aware that Aperture does lag behind the state of the art and it is time to update my toolbox. Another consequence of using different tools is that I now recognise that Aperture is in fact three products in one: RAW converter, photo manager and editor. Given the convenience and advantages of using Apple’s built-in image management, including the iCloud library for device synchronisation, it seems obvious that Apple’s Photos.app should be the starting point for a replacement solution.
When editing, for many photographs I found I could produce the same or better results in Photos.app compared to Aperture, unless I needed to tweak the RAW conversion. Photos’ superior plugin implementation also means that when it cannot get the job done alone it only takes one click to call out to another application. Consequently while Aperture has more built-in tools than Photos.app, the high quality of external applications means that Photos.app plus plugins can get better overall results with no loss of efficiency.
Photos.app handles RAW files but offers no editing abilities above and beyond what is offered for JPEGs. Given the additional time and bandwidth required to upload them to iCloud, along with the greater space consumption on iCloud storage, there seems to be no benefit to offset those costs and I have decided not to store RAW files in Photos.app. Storing my RAW files in a standard folder hierarchy without the obfuscation of a management application also makes it very easy to move these files between tools and platforms in the future.
I have been using Nikon’s Capture NX-D software to convert the RAW files into JPEGs. This is free from Nikon and produces lovely JPEGs which match what is shown on the camera screen, but I found too slow and too difficult to use to make even the most basic edits. I tried a 30 day demo of DxO Optics Pro 10 which produced reasonable JPEGs and was very good at improving certain aspects of a photo (noise removal and some lighting scenarios) but for the average photo is no improvement on the built-in Apple RAW conversion, and not as aesthetically pleasing as Capture NX-D.
In light of these findings, on recent shoots when SD card space has not been an issue, I have set my camera to store RAW+JPEG rather than RAW-only. I have then imported the camera JPEGs directly into Photos.app and reserved RAW edits for only those where the in-camera JPEG is not good enough. In that situation I do then import the RAW into Photos.app and use the excellent DxO Optics Pro for Photos plugin if I think that will solve the problem, or resign myself to fiddle with Capture NX-D if necessary.
Previously I noted that moving from Aperture to Photos.app meant giving up the ability to selectively apply enhancements using a brush. I speculated this advanced functionality would be something third parties could provide via the extensions API, and the latest version of the superb Pixelmator provides all the brushes I remember having actually used in Aperture: burning, dodging, colour and sharpening. The retouch extension also provides access to Pixelmator’s very impressive repair tool for removing unwanted objects, a serious upgrade to the built-in retouch function.
Also worthy of mention is the Mac version of the Polarr Photo Editor. A slick and efficient editor in its own right, it makes the popular curves adjustment easy to apply without leaving Photos and its de-haze slider is also useful for increasing the clarity of hazy or misty photos.