Five minutes of some trivial testing shows that this is just not true.

Noise is still affected by input gain

Here’s a composed recording of four 3-second clips recording the room tone in my office. They are (in order): Auto gain, 57dB, 35dB, 0dB:

As you can hear, auto and maximum input gain in this case have very similar noise levels (which is to say, perceptually none), but as you reduce the recorder’s input gain (and instead apply the gain in post) the noise increases substantially and becomes very noticeable.

Granted this is a very big gain application – 57dB – which you would hopefully never need to apply to a real recording, but nonetheless it demonstrates that Tascam’s claims are exaggerations at best; if you actually had the Portacapture X8’s input gain set to 0dB and recorded quiet sounds, you would in fact have problems with noise – problems that would be avoided with a correct input gain setting.

Clipping still happens if input gain is too high

The recorder clearly applies actual analog amplification and can still saturate its ADCs, as shown in this composite of three gain levels. They are (in order): Auto gain, 35dB, 57dB.

Warning: annoying, distorted sound.

It only went over by about 3dB (at 57dB input gain), but that was enough to destroy the input signal and make the recording unusable.

Auto Gain still affects the recording

In the above tests I included the Auto Gain setting, even though it doesn’t exhibit particularly high noise nor does it clip in these simple sound environments (basically constant sound levels). And it worked pretty well (not optimal input gain levels, but close enough for my taste).

But, I was curious if it had any effect at all – again, reading about 32-bit floating-point recording online, you’d be forgiven for thinking Auto Gain has no impact on the actual recorded data. Many people liken the format to camera raw files, and some explicitly state that Auto Gain has no impact on the bits that get written to disk.

This is completely false, at least in the case of this Tascam Portacapture X8. It’s trivial to see why:

Auto Gain still does exactly what it always does – it changes the gain in response to the input. That change is baked into the recorded audio track(s).

So in a nutshell, 32-bit floating-point recording might provide slightly more flexibility in some situations, but it does not mean you can ignore your input level settings, it does not mean you can use Auto Gain in every scenario, and it does not mean you cannot clip.

Addendum: Technical details

I tested post-production gain changes in Final Cut Pro, Logic Pro, & Audacity. All produced the exact same results (to my ears). I had read that Final Cut Pro sometimes ‘bakes in’ clipping with 32-bit float inputs, as if it’s pre-rendering them down to some smaller dynamic range, so I wanted to rule out some Final Cut Pro-specific stupidity. It’s possible that all these editors are doing that, but I’d be flabbergasted if that’s true.

The “industrial noise” sample I used was my dehumidifier, which is about 66dB according to DecibelX on my iPhone 14 Pro. My office room tone is about 42dB according to the same app.

I used Sennheiser K6 modules with an ME65 and ME66 attached, plugged into the Tascam Portacapture X8 via 3′ Cable Matters XLR cables.

I recorded at 96kHz because that’s what I’ll use most often. I like the aliasing headroom above 48kHz (even though of course my final outputs are almost always 44.1kHz or 48kHz), but don’t see evidence that 192kHz provides meaningful additional benefit (and it also hurts the frequency response significantly, compared with 48kHz and 96kHz, according to Tascam).

I had intended to just buy an Apple Vision Pro on release day, but by the time I woke up and went to Apple’s online store – a couple of hours after pre-orders opened – they were showing a nearly two month shipping delay (and no in-store pick-ups at all). So I figured there was no point ordering then; like it or not I’d have plenty of time to see what others think first.

Of course, it turns out it was not in fact massively out of stock. I later found out that people had ordered theirs later that day, or even the next day, and were still included in the very first shipment. Nobody had to wait two months for theirs, even if they ordered weeks later. Apple’s online store was full of shit.

But I’m glad for it, because as soon as I was resigned to not ordering one, I was at ease with that decision. I felt oddly relieved. Having since read & listened to many people’s impressions & commentary, over the last month, my confidence in that decision only increased. And now that I’ve tried one for real, I am certain of it.

The Good

Ease of use

I found the interface to be pretty intuitive. Eye tracking worked very well, and gesture recognition was fairly reliable – neither were perfect, but then mouse tracking and “the key I meant to press” tracking isn’t perfect either. 😉

It’s hard to say with any confidence from such a short use of the Vision Pro, but my impression is that its eye & gesture tracking is at least as accurate as touch on iPhones, iPads, and Apple Watches. My Apple Watch & iPhone routinely reject my taps just to spite me (they animate the GUI to show that they know that I did tap, yet they refuse to accept it).

Which is to say, I suspect it would annoy me at times with its errors but I don’t think it’d be a barrier to long-term use.

Sound

One thing which I did not remotely anticipate is how good the sound isolation is – even more astounding given there’s nothing in or on your ear to provide a physical barrier. There were dozens of people in the Apple Store, including several pairs right around me going through their own Vision Pro demos or iPhone upgrades, and with the headset on I barely registered any of their conversations.

I find it hard to believe it’s due to traditional noise cancellation methods, just given the physical position and arrangement of the speakers, so this might be as much a psychological ‘trick’ as anything. In any case, it is effective.

I was also impressed by how well 3D audio worked (and how good the sound quality was in general). Better than AirPods (and Beats Pros) in my experience, although that’s a low bar.

I’m less sure how the Vision Pro’s speakers stack up against real headphones – even my aging Sony MDR-ZX780DCs – but it’s at least a reasonable comparison, which is impressive given the Vision Pro’s speaker’s form factor.

Real world view

When the Vision Pro was first announced I was a little disappointed that it uses cameras to ‘fake’ transparency, rather than using genuine optical transparency. Nonetheless, I was happy to see that the effect is mostly sufficient.

It wasn’t hard to find flaws if you looked – the cameras are not correctly placed to actually see what you see, for example, so any objects closer than about a metre have noticeable parallax errors. That’s very noticeable if you do something as simple as move your hands in front of you, even at arms length.

Yet, looking around the real world worked fine in practice. There is perceptible lag, but only barely – not enough to really cause any issues; you’re not going to accidentally walk into moving objects, for example, and you could probably even play [real] sports with the Vision Pro on (although you wouldn’t be doing yourself any favours).

I should note that it was in no way realistic because you’re clearly looking at a resolution-limited computer screen (more on that later). And I didn’t even test things like dynamic range or optical aberrations of the lenses, as I was in a very evenly lit and low-contrast Apple Store.

Immersive experiences

I didn’t get to do the butterfly & dinosaur one, which is a shame because by all accounts it’s particularly good, but I got the quick demo reel of spherical videos (along with a couple of “3D” photos & videos). It was a bit hit & miss (more on that in later sections), but there were a few moments where I was actually pretty pleased with the experience. I’ve visited Haleakalā a few times but never seen the crater – the weather has always conspired against me – so I actually got lost for a minute or so just enjoying that view. The subtle animation of the mist drifting up & down the crater walls was a sublime touch. Likewise the gentle rain on the lake near Mount Hood.

The 3D video of a kid blowing out the candles on their birthday cake worked relatively well. The feeling of depth was nice – aided by the cake being very close to the camera and the use of a wide angle lens. I suspect wide-angle photos are much more amenable to the “3D photo” effect (they’re often described as more immersive even in plain 2D – although I think that effect is exaggerated by many people).

Human intrusions

The way people very subtly appear when you look in their direction while in full VR mode was quite nice. I like that they are visible but remain faint apparitions. I had received the mistaken impression from second-hand accounts that intruders appeared largely opaquely; much more obtrusively. The implementation strikes a good balance in providing awareness – and facilitating communication – without interrupting more than necessary.

Physical comfort

It’s of course very hard to deduce the real-world comfort of the Vision Pro from a mere fifteen minute session, but for whatever it’s worth I didn’t have any issues regarding weight, size, or contact. The headset certainly wasn’t unnoticeable, but I had no issues forgetting about those aspects while using it.

Also, it wasn’t until I was mostly done writing this article that I even remembered that the Vision Pro has a cable sticking out of it. The battery pack stayed on the table in front of me, and the only time I noticed the cable – even in the slightest – was when putting the unit on (merely because I had to make sure the cable wasn’t tangled around my head). I was expecting to feel the cable tugging and pushing on the headset during use, but did not.

This is in stark contrast to the power cable on my MacBook Air which is constantly getting snagged and yanked by my apparently villainous couch. So I’m very curious how the Vision Pro would work in a more typical environment, rather than at the Apple Store with basically nothing but empty space around me as I sat on a stool.

Minimal internal lens flare & reflection

At least in the bright Apple Store, I didn’t find the lens flare & reflections to be distracting. They are present, but I really only noticed them on the very first screen, where you’re in a black void and thus of course any such optical imperfections are most visible.

This is pretty good, by my estimation, since I find sunglasses to be irritating due to seeing the reflection of my own eyeballs in them. The Vision Pro has the big benefit of the [mostly] enclosed mask, to largely eliminate external sources of light. So it should have far fewer issues with flare & reflections, as a matter of principle.

The main reflection I did notice – and had a slightly harder time ignoring – was the glow of the screen on the inside of the light shield. It’s a pity Apple used a grey, textured material for the interior, rather than something dark like Musou black fabric.

Still, unless you plan to work in a very dark or high-contrast VR environment – perhaps the moonscape that I tried briefly during the demo – you should be fine in this respect.

Real world geometry is no limit

Folks have unanimously stated that – surprising or not – there’s no visual incongruence with pushing AR elements “through” real-world ones. One of the first tests I did was to grab a window and shove it through the table in front of me. Despite clearly violating all logic, my eyes & brain apparently had no issue with it – it didn’t feel wrong, or weird, or uncomfortable.

So – while I didn’t test it – I can easily believe that you can indeed watch a movie on a [virtually] cinema-sized screen despite being stuck in cattle class on a plane. And I can imagine it would be a genuine emotional benefit to have that feeling of so much more personal space, even though it’s “fake”.

Honestly, if I were to get a Vision Pro its use as an aid to commercial air travel might actually be one of the most justifiable reasons.

The Bad

Buggy demo units

My time actually using the Vision Pro was significantly shortened by the demo unit refusing to reset properly. It took three attempts – and a consultation between Apple Store staff – before they finally got it to work properly.

On the first two usage attempts it went straight from the “hold down the crown button to shift the lenses” to the home screen, bypassing eye tracking calibration. It didn’t seem particularly unusable without proper calibration, but my Apple handler refused to start the demo without it.

Bad light seal

Perhaps it’s just me and my apparently tiny nose, but there was a big gap between the unit and my nose. I could easily look through and see the table in front of me, my own lap, etc. This surprised me given Apple themselves have put a lot of emphasis on the importance of a good fit and no light leaks in order to have the proper experience.

However, in use I didn’t find it much of an issue – I wasn’t distracted nor blinded by the light leaking in. I think as long as my focus was actually on the screens of the Vision Pro, and my attention on whatever I was looking at within them, it was okay. Although, just like the glare & reflections within the lenses, it may not be so easy to ignore in a dark VR environment.

Non-immersive experiences

Most of the 3D photos & videos I saw didn’t do much for me. I can clearly see the appeal in theory, but the implementation on the Vision Pro is frustrated by several factors.

For a start a lot of the 3D photos – and especially videos – were blurry outside of the centre¹. Really blurry, in the case of the Alicia Keys clip – she was reasonably in focus but almost everything else was way out of focus. I think in the original recording, although I guess I can’t be sure that it wasn’t buggy foveated rendering or somesuch.

Second, even when they weren’t blurry, they were often low resolution. Hard to say whether this is because of the Vision Pro itself (more on this later) or with the source materials.

I was hoping that the panoramas would be a big (pleasant) experience, as I’m quite a fan of taking panoramic photos (and photo spheres) even though you can’t really view them well on fixed displays. In a way I’ve been waiting and preparing for VR goggles for decades. Heck, I was super excited when Quicktime VR was released, even though it turned out to unfortunately be decades ahead of its time.

Yet, I was a bit disappointed with the panorama experience on the Vision Pro. I’m not entirely sure why, although I know one obvious reason was that you can see the edges. Any illusion of being there is rattled when the edge of the photo appears in view. Photo spheres are the better way to go.

Seeing the edges might sound trite – after all, we see the edges of photos and videos all the time on our existing displays; what’s the problem? It’s a good question – I don’t know if I can explain it, I just know what I felt. Perhaps it’s an uncanny valley sort of problem – because you are in a nominally immersive, VR environment, it matters so much more when the illusion is shattered. Perhaps it’s something you get used to?

In any case, even for photo spheres the feeling of immersion is compromised by the field of view being way too small…

Limited field of view

I had heard that the Vision Pro has a limited field of view – even compared to its contemporaries – but I was still surprised to see what that’s actually like. It’s even more limited than I expected. It’s like wearing bad goggles – blinkers, perhaps. A kind of tunnel vision. I’ve heard it said that you “just” need to keep your eyes centred and move only your head instead, but even looking dead ahead I clearly perceived the outline of the screens, and it took some effort to ignore that (mostly successfully).

As noted earlier, this kinda ruined any would-be feeling of immersion for me, in most cases. You’re not much more “there” than you are viewing a photo in a picture frame (or on a traditional screen), or watching a video on a TV placed too far away.

Everything’s too close & big by default

I was surprised that windows open way too close (in perceived depth) and too big (in field of view) by default. I was constantly manually resizing things and pushing them away from me, in order to actually be able to see them [fully] and comfortably.

I do not like having to move my head just to look around a single window, it turns out.

I also found it quite unintuitive that windows enlarge as you push them away, maintaining the same angle of view. It was not only annoying – since the whole point of pushing them away was to make them smaller and feel less claustrophobic – but it made it hard to actually judge if & to what degree they were moving. More than once I repeated a “get back” window movement because it seemed like the first try was silently ignored (and honestly, I can’t be sure it wasn’t – that’s the point).

3D movies

I watched the brief trailer for Super Mario Bros. I didn’t really get much of a 3D effect, but I did get the very limited field of view (see prior point) and poor visual quality (see below). I’m actually a bit bullish on 3D movies, but I think we’re still just not there technologically².

I do like to have a big screen – such that my vision is pretty filled by a movie – but apparently I really don’t like it when there’s a black mask over the outskirts of the movie. Even if it’s only visible in my peripheral vision.

Possibly I’d get used to this in time, but of course I don’t really want to – I should be able to see the whole movie. Otherwise, what’s the point? If the director wanted me to see only a subset of the view, they’d have filmed it that way.

I presumably could also have manually moved the window back – and I did for some of the other videos I watched – but it’s just not practical to have to do that for every video I ever watch.

Perhaps the problem is in taking existing movies – designed for a relatively tiny field of view (≤40° typically) – and naively shoving them in your face in the name of immersion. Maybe what we need is to add new content around the existing frame. Despite our huge angle of vision, our focus area is actually quite small. It’s uncomfortable and confusing to have to look around frequently and rapidly just to make sense of a movie.

The Ugly

Very blurry & low resolution

I was really surprised to see pixels. Immediately. Even though I was already aware – mainly from John’s stumbling over the topic on ATP – that the PPD (Pixels per Degree) is actually quite poor on the Vision Pro, at just 34³. A “Retina display” at typical viewing distances is around 100. Even an ancient non-Retina Apple display is about 50.

In fact, 34 is about the same as an original Macintosh from 1984. 😳

I found this handy calculator for determining PPD, in case you want to estimate for your own devices. If you have a 5k 27″ monitor, for example, but typically sit with your nose about 4cm from it, then you’re already used to the Vision Pro’s display resolution⁴.

Furthermore, unlike the original Macintosh’s screen – which at least had quite crisp pixels – the Vision Pro is blurry as well. That surprised me less – I figured there might be some calibration required, which was perhaps unintentionally skipped by the buggy demo unit. But my Apple Store handler didn’t seem to think so, yet seemed surprised by my comments (that the view was pixelated and blurry). He had no real answer to that. He implied (by omission) that my experience was normal. 😕

Jittery

The other thing I noticed within a literal second of using the unit is that the artificial visuals jitter – jump randomly about by a pixel or two. All the time. It’s less noticeable in full VR mode where you have no objective reference in the form of real world objects, but in AR mode everything displayed by the Vision Pro is shaking. I was able to mostly ignore it throughout the demo – but only with conscious effort. Any time I let my mind or vision wander in the slightest, the shaking immediately bothered me once more.

To be clear, this was while sitting perfectly still. I didn’t really test actual lateral movement of the headset, as I was asked to stay seated for the entire demo.

Since everything you see in the Vision Pro is technically artificial – it’s all from opaque LED screens, even the view of the real world that’s piped in view cameras – this jitteriness is baffling. I’m pretty sure it was the virtual objects that were moving, not the feed from the real world – just based on my own perception of what was and wasn’t moving – but I have no explanation for why that would be the case. While I could sense a tiny bit of a lag in the real world view, it seemed to remain correctly positioned (and stably positioned, more to the point) relative to objective reality.

It’s hard to say from just fifteen minutes of use, but I suspect this jittering would contribute significantly to eye strain.

Eye strain

When I took the Vision Pro off, my eyes were immediately assaulted by [comparatively] bright light and much sharper everything. It was both uncomfortable and a relief.

It took several minutes for my vision to de-blur. It’s a very similar experience to looking through the viewfinder on my Z9 for an extended period. And similarly it took a good couple of hours for my eyes to get fully back to normal, and to stop feeling strained.

Based on that parallel experience, it seems very clear that I cannot use a Vision Pro for any significant amount of time, without serious eye strain that causes lasting blurry vision and headaches. 😣

I’m assured by my optometrist that my vision is actually excellent – much better than average for my age, and I’m not that old yet anyway – and I’ve never needed glasses for anything⁵. So I don’t think the problem is me. I think the problem is quite apparent from the facts: the Vision Pro simply has a very low-resolution, unstable display that is uncomfortable to look at.

So now what?

Now I wait.

If I’d decided to develop apps for the Vision Pro, as a business choice, then it’d make sense to own one – it could be considered a dev kit; an early prototype. But for now I’m content not to. There doesn’t seem to be a rush – the app market is comparatively tiny.

For personal use it makes no sense to get a Vision Pro. Aside from its novelty factor and some very limited uses, it’s inferior to a Mac for almost all purposes (like productivity tasks, watching movies, reading books, video calls, etc).

Yet I’m hopeful that the AR and VR headsets’ times will come, eventually. Still at least several years from now, based on what I’m seeing with the Vision Pro. But one day.

I’ve been trying to discern if the Vision Pro is an iPhone moment or an iPad moment, since it was announced. I was bearish on the iPhone and bullish on the iPad, apparently at odds with the entire rest of the planet. And I’ve since conceded defeat entirely on the iPad – when I replaced my iPad Pro 13″ with a MacBook Air, it was such a relief – I finally had a device which I could use freely and broadly, rather than a glorified iPhone for web browsing and watching video. So I’m leery about getting too enthusiastic about a new class of device which clearly has some of the same existential challenges as the iPad.

One thing seems clear – it’s not a Mac moment. I don’t see anything with the Vision Pro that fundamentally changes the nature of computing, let-alone day-to-day life. But then, I don’t think it’s fair to expect it to – there’s only been one Mac moment so far.

1. This might be just flaws in the demo material, although it’s hard to imagine Apple letting that fly. I have to assume the Vision Pro itself is the limitation here.
   
   That said, in the “3D” video of the girl popping bubbles I saw what looked exactly like JPEG or MPEG compression artefacts (mainly blocking and over-smoothing). I can’t be certain whether that’s an issue in the video file or in its playback by the Vision Pro, but I would assume that graphical rendering glitches would appear somewhat differently…? ↩︎
2. Most immediately, we lack the display technology to show a 4K (or better) video in 3D, whether via a headset like the Vision Pro or traditional means like coloured or polarised glasses. But that’s merely the easy part – we also need real-time rendering of the movie itself, in order to do proper foveated depth rendering – i.e. so that if you look at something in the foreground or background you can actually bring it into focus, even if the director hadn’t planned on that. As best I can tell practically nobody is even working on that yet. 😕 ↩︎
3. Tangentially, it’s baffling how news media outlets like The Verge can shamelessly try to spin that as in any way good. Talk about drinking the Apple koolaid. 😠 ↩︎
4. And if you can actually focus at that distance, then I applaud & hate you, because I can only reminisce fondly about those days. Stupid aging. 😔 ↩︎
5. Although admittedly I can no longer focus on the end of my nose like I used to be able to do when I was a few years younger, so I know my descent into old-age far-sightedness has begun; I’m told I will need reading glasses at some point in my life (barring an unfortunate early exit). ↩︎

So you’d think it’d be trivial to do correctly. Alas, it is not.

What is the danger?

There are two key things to watch out for when creating files:

1. Security flaws due to incorrect use of, or badly designed, file system APIs. This is especially a concern for privileged applications (e.g. setuid) or those that ever run with elevated privileges (e.g. via sudo or by admin users). Unintentional reuse of existing files can be (and has been) the cause of major security vulnerabilities. See the appendix for more details.
   
   Another security concern is leaking sensitive information to other programs (or users, on a shared computer). This can easily happen if files are created in places other programs or users can access, such as shared folders. The files may be inadvertently created with inappropriately broad permissions (e.g. world-readable) or the parent folder’s permissions might permit others to change the permissions of the file after the fact even if they don’t own it (e.g. a world-writable folder without the sticky bit set).
2. Data loss risks due to inadvertent overwrites or modifications of existing files. If you’re not certain you know what file is already at a given path on disk, and that you should be allowed to overwrite it, then you should not. Usually, the user has to give explicit permission (e.g. Save dialogs that explicitly ask the user if they intend to overwrite an existing file).
   
   This risk is greatest for persistent files, e.g. files in your Documents folder. Those are usually where the user stores their most important data.
   
   For temporary files the level of danger is generally lower but not zero. If you’re using a system-designated temporaries folder, then in principle anything in there is unimportant anyway. However, randomly mucking with temporary files can still cause data corruption or loss, depending on how those files are used by applications (including your own). e.g. they might store autosaves of the current document in temporary files, and directly copy / move those files when the user formally saves. Thus, modifying the temporary file might end up modifying the user’s actual save file.

How are these dangers mitigated?

App Sandboxing helps

As annoying & limiting as App Sandboxing can be in other regards, it is one of the best single steps an application author can take to improve file security. For the most part, your application is the only (non-system & non-privileged¹) application that can write within its sandbox, and you’ll usually be creating files only within your own sandbox.

Avoid /private/tmp (a.k.a. /tmp)

/tmp is merely a symlink to /private/tmp.

/private/tmp is world-readable: every program on the computer can access its contents. Thankfully, it’s not as bad it first appears – /private/tmp is special in that it has the “sticky bit” set, which imposes some key restrictions on what users may do to each other’s files (most importantly, that they can’t delete them even though /tmp is world-writable).

Still, it’s better to use the tmp folder designated via FileManager.default.temporaryDirectory or URL.temporaryDirectory. Though the location and security properties of that folder varies:

• If App Sandboxing is in use, it’s an application-specific folder like /Users/SadPanda/Library/Containers/com.sadpanda.MyApp/Data/tmp/. No other (unprivileged) application can access that folder.
• If App Sandboxing is not in use, it’s a user-specific folder like /var/folders/v3/8anbad56df64adf3_35gj346jg13v19a/T/ (the exact path varies between user accounts and computers, by design for security). That folder is still insecure – it is accessible to all programs of the same user – but at least you don’t have to worry about other [unprivileged] users.

If used correctly, /private/tmp has essentially the same properties as the user-specific temporary folders. Using it correctly starts with ensuring files are created with no group or ‘other’ privileges, but the full complexities are beyond the scope of this post.

Consider setting a restrictive umask

When you create a file on any Linux or Unix system, such as macOS, its permissions are set based on a combination of the specific API used and the process-wide umask. Good APIs will require you to specify the initial privileges of the file, but some do not (e.g. fopen) and instead use some arbitrary default, such as creating files as readable and writable by anyone (0666). That is bad – usually you don’t want your files readable by any other users.

While you should generally avoid APIs that don’t provide proper control over file permissions, you realistically may not even know if you’re using such APIs because they might be employed by library code you don’t control (including Apple’s).

While it’s possible that the parent folder(s) will protect a given file (by preventing access to their contents by other users), it’s safest to not assume that.

The umask can help mitigate the dangers of bad APIs by specifying which privileges are not to be granted by default².

The umask defaults to denying write access to groups and other users (0022), which is a start but still not good – read access to private user data is still a concern.

However – beyond the overly permissive default setting – there at two problems with umask:

1. It is a process-wide global. Modifications to it apply to all threads in your process, which makes it dangerous to modify. e.g. you might be creating a particularly sensitive file and need the umask to be 0177, so you set it to that, but before you actually get to execute the file creation another thread sets the umask to 0000 because it wants to create an otherwise unrelated file that’s world-writable.
   
   So unfortunately the only safe way to use umask is to set it very early in process launch before any additional threads are created³.
   
   You can try to enforce your own mutual exclusion around umask, e.g. with a global lock, but beware of 3rd party code (including Apple’s) that might modify umask without following your mutual exclusion protocol. Generally umask isn’t modified often, so this arguably is possible to achieve in practice, but proving that there are no missed calls to umask can be practically impossible.
2. Lots of existing code, that you might be unwittingly using via libraries or frameworks, assumes the umask remains at its default. Thus, making it more restrictive might break things in ways & places that are difficult to foresee.
   
   In general the more complicated your program, that more of a concern this is. e.g. most command-line programs can modify umask without causing issues, but GUI programs pull in a lot of framework code and functionality, some of which might implicitly rely on certain umask bits. Unfortunately the only way to find out is experimentally.

So umask is not a panacea. Still, setting a restrictive umask improves security if you can get away with it.

Correctly use the right file creation APIs

In short, creation of files needs to (generally) not extend nor replace existing files, and ensure correct initial file permissions.

There are quite a lot of APIs for creating a file in macOS. I’m going to enumerate only the most common ones provided by the system libraries & frameworks.

⚠️ open

Nominally this is the low-level API for opening (existing or new) files, although as you’ll see later it’s not actually the only one.

It has a flags parameter, which is how you tell it what to actually do, between opening existing files, creating new ones, etc. Two of the most important flags are O_CREAT and O_EXCL. O_CREAT tells open to create the file. If O_EXCL is specified, open will fail if a file already exists at the target location. If O_EXCL is not specified, O_CREAT is interperted as “create the file if necessary” – meaning, it will actually open the existing file if it exists, and not create a new file.

You should almost never use O_CREAT without O_EXCL. If you really do intend to overwrite the existing file, then it’s safer to remove the existing file first (e.g. with unlink), and then create your new file (with O_EXCL to ensure no other file appears at the target location in the interim). That way you ensure the new file has your expected location (not a symlink) and attributes (e.g. file permissions).

Note that O_EXCL will fail if the target is a symlink, so you don’t need to specify O_NOFOLLOW (although it doesn’t hurt).

open requires you to specify the new file’s permissions if you use the O_CREAT option (and respects the umask), which is good as it makes you think about what the permissions should be, and lets you set them to something suitable for each use case. These permissions are only applied to new files, so in a nutshell you cannot rely on them if you don’t use O_EXCL.

For that reason also, you typically should not use O_TRUNC. If you don’t need the contents of the existing file, delete the file first. “Reusing it” via O_TRUNC also reuses its permissions and other attributes, which might not be set correctly for your intentions (e.g. a malicious program might have pre-created the file as world-readable, even though you intend it to be readable only by the current user and have otherwise done the right things such as set the umask to ensure that).

One reason you might validly use O_TRUNC is if you anticipate there being multiple hard links to the file, and you want to modify the file as seen by the other links too. This is very rare. Be sure that’s necessary before you use O_TRUNC, and consider putting validations in place to ensure the file you’ve just opened for reuse has the expected permissions and attributes (e.g. via fstat64 and similar APIs that operate on the file descriptor – do not use lstat or any other path-based APIs).

⚠️ fopen

This is essentially just a wrapper atop open, with the “w” and “a” flags mapping to O_CREAT (essentially) and the “x” flag mapping to O_EXCL. The same rules apply, so you should generally never use “w” without the “x” flag as well, nor “a” without “+”.

fopen does not let you specify the permissions of the created file, instead defaulting to 0666 (readable & writable by everyone) which is a terrible default. It does respect umask, so by default it will create files as 0644 which is marginally better. But, as discussed previously, it is difficult to guarantee what the umask actually is at any particular point in time. So in general you should prefer open instead of fopen.

❌ OutputStream(toFileAtPath:append:) & friends

This ultimately (when you call the open method) calls open with the flags O_WRONLY | O_CREAT (plus O_TRUNC if the append argument is false). As such it will always modify an existing file if present.

It also does not let you specify the permissions of the new file, instead defaulting arbitrarily to 0666 (but respecting umask, at least).

It is an unsafe API and should not be used.

⚠️ NSData.write(toFile:options:) & friends

This family of methods all ultimately call open_dprotected_np (implementation), a variant of open specific to Apple platforms which adds Apple-specific functionality regarding file encryption and isolation (see e.g. the protection-related flags within NSData.WritingOptions). It takes the same flags as the regular open, and write(toFile:options:) by default uses O_CREAT | O_TRUNC. If you use the withoutOverwriting option, it adds O_EXCL. So you should usually use withoutOverwriting.

If you use the atomic flag, it creates the file using a private function _NSCreateTemporaryFile_Protected which obtains a file path using mktemp ⚠️ and calls open_dprotected_np with the flags O_CREAT | O_EXCL | O_RDWR⁴. Once it has created & written to that temporary file, it uses rename to move it into place. rename just silently deletes any existing file at the destination path. So it’s safe against race attacks, but susceptible to data loss bugs from unintentionally overwriting existing files. As such, use atomic only with caution.

It also does not let you specify the permissions of the new file, instead defaulting arbitrarily to 0666 (but respecting umask, at least). For files containing sensitive data (such as private user data), this API should generally not be used.

❌ NSString.write(toFile:atomically:encoding:) & friends

These are essentially just wrappers over NSData.write(toFile:options:) & friends, where the atomically argument maps to the atomic option. They provide no way to use the withoutOverwriting option, so they should not be used in most cases.

Use randomised names for transient files

Whenever the file name doesn’t actually matter – i.e. it’s not chosen by the user and isn’t pre-defined by some system requirement – it’s best to use a randomised name. This serves two purposes:

1. If your code has any bugs that allow it to erroneously overwrite existing files, using random names at least makes it a lot less likely that you’ll trigger those bugs, by greatly reducing the odds of using the same name twice.
2. It makes it harder (if not impossible) for attackers to predict the file names, and therefore to attack them.

There are many ways to obtain a randomised name, but it’s wise to use one of the canonical methods detailed below.

⚠️ mktemp

mktemp is infamously a source of security vulnerabilities, because it doesn’t actually create the file (or folder) but merely returns a path. The caller is responsible for securely creating the file (or folder). This can be done safely – by following the guidance earlier in this post, in particular around the O_EXCL open flag – but it’s easy to screw up.

Generally it’s preferable to use mkstemp / mkdtemp & friends. Unfortunately, if you want to use higher-level file APIs on Apple’s platforms that’s a problem because most of those APIs don’t support initialisation from a file descriptor, only a path (or equivalently, URL). So you may find that you still need to use mktemp. If so, be very careful about how you actually create the files & folders.

✅ mkstemp / mkdtemp & friends

These replacements for mktemp actually create the file / folder (respectively), in a safe way.

mkstemp creates the file and returns the corresponding open file descriptor, instead of merely returning a path and leaving it to the caller to get the creation step right. It will never overwrite (nor open) an existing file. It also sets the file’s initial permissions to 0600 (i.e. read-writable but only by the current user), which is a pretty safe default.

mkdtemp still returns a path (not a file descriptor), like mktemp, but it ensures the folder was actually created (and not previously existent) with the permissions set to 0700 (i.e. usable only by the current user).

Neither make any guarantees regarding security – or lack thereof – due to parent folder permissions. The caller still needs to ensure necessary security protections for those (whether by choosing a suitable system-provided folder, or manually checking permissions and symlinks in the path). URL.temporaryDirectory is a good starting point.

Using these from Swift is a little awkward because they mutate their primary argument (the path template), but here’s an example. Once you have the file descriptor (in the mkstemp case) you can wrap it in e.g. a FileHandle and work with it at a slightly higher level.

⚠️ FileManager.default.url(for:in:appropriateFor:create:)

In its special mode where ‘for’ is .itemReplacementDirectory and ‘in’ is .userDomainMask, this behaves like mkdtemp; it creates a randomly-named folder and returns the URL to it (note that it completely ignores the ‘create’ argument in this case – there is no way to have it not create the temporary folder).

This API seems to presume the use of App Sandboxing to mitigate its problems – and when App Sandboxing is enabled, it’s the best way to obtain a temporary file or folder path, though only if you use a suitable value for the ‘appropriateFor’ parameter, such as URL.temporaryDirectory⁵. When App Sandboxing is enabled, that will result in a path inside the sandbox, which is the most secure place an unprivileged application can use.

However, if instead a URL is provided which points to a different volume, it returns a path to a user-specific temporary folder on that volume, e.g. /Volumes/Example/.TemporaryItems/folders.501/TemporaryItems/. While that does exclude (unprivileged) other users, it’s still a big step down from a location inside the app’s sandbox.

Appendix: File system races in more detail

Generally-speaking, the file system is a shared resource. Multiple programs can access it simultaneously with no coordination required⁶ between them. That opens the door for races – where the state of the world changes in-between file system operations that a program might mistakenly assume are atomic.

In general, any single call to a low-level file system API – e.g. open – is atomic. Most such APIs correspond to a single syscall into the kernel, and the operation inside the kernel is wrapped inside a lock (conceptually if not also literally).

Conversely, any operation that takes multiple calls to a file system API is never atomic.

A textbook security vulnerability arises when you do something like:

1. Make up some random file name (e.g. with mktemp).
2. Check that it doesn’t exist (one syscall), and see that it doesn’t.
3. Write to that file (a separate syscall).

A malicious program could inject its own file in-between steps two and three – or even more dangerously, a symlink – and cause your program to overwrite something (many file APIs will automatically follow symlinks and open existing files, if not used correctly as detailed in this post).

The classic concern in this regard is with privileged programs that have the ability to overwrite sensitive files, e.g. /etc/passwd. Tricking them into doing so can cause major damage to the system (e.g. nobody can login anymore!) in the best case, and in the worst case – where the attacker can also influence the contents of the file, or those contents are conveniently just what the attacker wants – they might be able to implement a more subtle attack that doesn’t merely break the system but instead e.g. changes the root password, giving them superuser access to the computer.

Even for unprivileged applications, it can still be a concern. e.g. they might be tricked into writing a bunch of private user data into a shared location from where the attacker can exfiltrate it.

Appendix: File writing APIs that cannot create new files

These APIs are nominally irrelevant since they can’t be used to create new files, but it can be useful to know that fact, for use in converse scenarios where you do not want to create a file.

FileHandle(forWritingAtPath:)

…ultimately calls [[NSConcreteFileHandle alloc] initWithPath:… flags:0x1 createMode:0 error:nil], which turns the path string into a URL using -[NSURL fileURLWithPath:] and calls -[NSConcreteFileHandle initWithURL:flags:createMode:error:], which calls _NSOpenFileDescriptor to do the actual file system calls. That calls open with only the flag O_WRONLY; it does not pass O_CREAT nor O_EXCL. So FileHandle cannot create new files (which I find a bit unintuitive, as nothing in the name really suggests that limitation).

NSData(contentsOfFile:options:) & friends

…ultimately call open with no flags (meaning they can only read existing files, not even modify them). So again, cannot create new files. Which is perhaps implied and obvious from the name, but it’s good to be certain.

1. In principle system programs & privileged (e.g. root & admin) programs should be defended against too, but it’s often impractically difficult to do so, and beyond the scope of this post to try to explain how.
   
   Root is of course the most impractical to defend against – even though the root user is not a traditional “God” user on macOS, Apple’s nerfing of root is designed to protect Apple’s programs, not yours. Root (and admin users) can ultimately still access any files your application(s) create and there’s nothing you can do about it (other than potentially through orthogonal protections, such as encryption). ↩︎
2. It is of course possible for libraries to override the umask, but that would be particularly foul of them and none that I’ve surveyed do that, thankfully. ↩︎
3. This can be hard to guarantee, in a non-trivial program. You can use an assertion or precondition on the return value of pthread_is_threaded_np to help ensure you’re modifying umask before additional threads are created. ↩︎
4. It’s not apparent to me why it needs read access to the file as well – that appears to be a bug. ↩︎
5. I’m not sure what happens if the App Sandbox container is not on the boot volume. ↩︎
6. There are various mechanism for voluntary coordination, such as NSFileCoordinator and flock, but programs are not required to use them (and malicious programs happily won’t). ↩︎

The built-in “code” block for WordPress (the CMS I use for this site) is virtually useless – it’s just a <pre> block, essentially.

The appearance may vary depending on WordPress theme, but will virtually always be bland.

In fact, it’s not even guaranteed to use a monospaced font – the example I’ve shown here is what you’ll probably get with any given WordPress theme, but it’s not actually the default for the theme I use (GeneratePress) due to a known bug in GeneratePress (which the theme authors outright refuse to fix!).

In any case, you have to use WordPress plug-ins to extend or replace it with something that actually looks in any way decent.

Unfortunately, Swift is a complicated language, even just at the “superficial” level of syntax highlighting. And most generally-popular syntax highlighting tools are both:

1. Focused on languages like JavaScript and HTML, not Swift.
2. Written in JavaScript or Ruby, with no access to standard tooling like the Swift Language Server Protocol.

Since I’m using WordPress for this site, Ruby’s not a good option (and I didn’t find any relevant WordPress plug-ins which rely on it, anyway). Hypothetically I could add a Ruby environment to my server and do static generation through it, but, ugh. It’s annoying enough dealing with JavaScript and PHP. If you’re going to go to that much trouble, you’d probably be better off actually using Swift (e.g. SwiftSyntax). And while I’d welcome a WordPress plug-in which does exactly that, alas no such plug-in exists today.

So, I spent way too much of my time trying out a bunch of the available WordPress plug-ins, and now I shall report the results so others don’t have to suffer [as much].

I’ve presented previews for both light and dark modes (but my apologies to dark-mode viewers that all the samples default to light mode – an unfortunate limitation of my CMS).

Baseline: Xcode

Syntax highlighting theming is a very subjective and somewhat personal preference. I really must stress this, as something to keep in mind as I critique these plug-ins based on my preference, which is pretty close to Xcode’s default theme.

I’ve tried to focus mostly on how well the plug-ins understand Swift syntax & grammar and what functionality they offer broadly, rather than which ones look prettier out of the box. Most have at least some degree of custom theming support, or at least permit unofficial theming through straightforward CSS overrides.

It is unsurprising that Xcode does by far the best job of understanding and correctly syntax-highlighting Swift code, of anything tested here. It has the advantage of being able to actually compile and analyse the code with full context – the example shown here has supporting type and function definitions “off-screen” – which WordPress plug-ins do not¹. While I set out on this exploration hoping to find something effectively as good as Xcode, I wasn’t really expecting to (and spoiler: I did not).

Allow me to call out a particular few things Xcode does right, that (as you’ll see) few if any of the WordPress plug-ins do:

• In short, it supports all Swift syntax. It correctly identifies all the keywords (and things that are not keywords but happen to be the same word, such as static properties called default as in the example code).
• It utilises not just colour but font and font weight. This permits it to effectively delineate things without having to use an excessive variety of hues.
  
  Some might finds its results comparatively bland with the default theme as shown here, in light mode especially, but it has other themes for those that want a more hue-centric approach, and supports a very good degree of theme customisation.
  
  The default theme doesn’t “demo” well (in light mode), in the same way that colour-accurate TVs look rather bland and unattractive in the showroom but are actually great in real-world use in your home.
• Even though it uses multiple font weights, it still preserves correct letter spacing.
• It understands DocC’s limited Markdown-like markup within documentation comments (and can even render them as properly styled text, although that’s not shown here).

I’ll also call out one thing which – in my opinion – it gets wrong, which is essentially not recognising custom type names. It renders them as plain text – no highlighting at all – yet gives special treatment to “built-in” types (from the Swift standard library) like String. It’s fine if it wants to distinguish between those two sets of type names, but it should use some kind of highlighting for both of them. Many of the WordPress plug-ins actually do a better job in this respect.

Common limitation: no Light/Dark mode support

One thing that none of these plug-ins do, that you would think they could and reasonably should, is explicitly support light / dark mode – even though most include both light and dark themes (some plug-ins even include light and dark variations of the same theme – so close!).

Instead, you have to pick just one theme. Furthermore, if you want proper light and dark mode support you have to pick a light theme specifically, to match WordPress’s default mode of light. This limits your control over the appearance in dark mode – and may make it difficult for you to find a theme which suits your aesthetic preferences in both modes.

WordPress itself doesn’t support light/dark mode – you have to² use 3rd-party plug-ins. Depending on which one you use, you might get viable automatic switching anyway. The several that I experimented with were all able to make my theme adapt actually quite well.

I initially used WP Dark Mode, but discovered it was buggy in that it would load pages in light mode first and only after the initial render would it switch them to dark, making browsing my site in dark mode very uncomfortable. It also didn’t work properly with SyntaxHighlighter Evolved. I consequently switched to Dracula Dark Mode which is a very similar plug-in but doesn’t have those bugs.

Note that most of the dark-mode screenshots shown here were taken while using WP Dark Mode. There may be slight differences in colours with Dracula Dark Mode (or some other dark mode plug-in), but in my brief experimentation the results are virtually indistinguishable.

The contestants

Code Block Pro

This advertises itself as using the syntax highlighting engine from Visual Studio Code, but that’s actually misleading – it uses Shiki, which is really its own engine albeit one that utilises the same TextMate-inspired grammar definitions and themes as does Visual Studio Code.

It’s open source and free for the most part – for a token $12 you can support the author and obtain a couple of dozen extra themes, adding to the two dozen or so that it includes by default.

Performance

If you’re familiar with Visual Studio Code for Swift development, then you basically already know how it performs, as the results are (in my testing) identical.

That’s only mostly a compliment, though. This plug-in, like Visual Studio Code, doesn’t really understand Swift, it merely does a relatively good job of faking it.

Unlike every other plug-in tested, where the grammar parsing is completely independent of the theming, the performance of this plug-in does vary between themes. Thus, some themes might have colours you hate yet be the only ones that actually identify Swift keywords correctly, while others are the reverse. This is demonstrated in the example shown here – the Light Plus theme – where the colours are the least ugly of the themes available but it doesn’t recognise some basic Swift syntax, like protocol conformances, which is recognised in other – albeit uglier – themes.

But, in general, it:

• Actually understands the difference between function parameter labels, parameter names, and parameter types.
• Tends not to recognise custom type names, only the Swift stdlib & Foundation ones (e.g. notice it doesn’t recognise Floor but does recognise String). This is somewhat common behaviour amongst the plug-ins tested (and Xcode itself).
• Doesn’t recognise some important keywords, such as async and some.
  
  As it happens, this is because the Swift grammar file it uses is quite a few years old and seems like it might be largely abandoned (other than sporadic community updates such as this which might or might not be incorporated by this plug-in). This is the same grammar file that Visual Studio Code uses, making it doubly-surprising, but I guess it says a lot about the level of interest the Visual Studio Code community has in Swift.
• Is not easily fooled by the use of ambiguous names, e.g. the default static property of HomeItem that’s often mistaken for the default keyword by other plug-ins.

Pros

• Includes the ability to highlight an arbitrary set of lines by blurring out all the others (but readers can mouse over the code block to unblur everything, if they want to see the full context of what you’re highlighting). This particular approach – blurring rather than just using a different background colour – is unique amongst all the plug-ins I found, and aesthetically far superior. Most of the other plug-ins don’t even have a way to highlight or hide certain lines.
• Uses server-side rendering with CSS inlined into the HTML, so code is highlighted right from page load without delays or visual glitches.
  
  Some other plug-ins tested here do server-side syntax analysis too, but to actually effect styling they use class tagging of HTML spans with CSS, which can mean rendering glitches if the CSS takes a while to load and the browser renders the code without it in the interim. Code Block Pro avoids that (and might also play better with other styling plug-ins or modifications, such as dark mode plug-ins).
• Has a live playground so you can easily test it out (although that playground is hard-coded to use the Fira Code font, which is only one of a number of open-source font options it provides).

Cons

• No global settings – if you decide to change any settings, such as the theme, at any point, you have to manually find and adjust every existing code snippet manually.
  
  This might be considered a positive by some users, where they want existing content to remain as-is. However, some plug-ins offer both a global setting and the ability to override that on a per-case basis, providing more flexibility.
• The provided themes – even with the paid expansion pack – are predominately intended only for dark mode, and most of the light mode ones are pastel. So if you want a clean light mode theme, as I do, you have only about three options with this plug-in.
  
  Furthermore, the performance varies between themes, as – unlike every other plug-in tested here – the themes are in essence tied into the parsing.
  
  None of the provided themes really do Swift justice compared to how well they work for other languages. Especially within the limited selection of light-mode themes, there’s precious few that don’t make obvious mistakes (like conflating the some keyword with operators, or being confounded by generics syntax).
• Theme customisation options are extremely limited, not just officially but even unofficially with custom CSS. Although, the author seems receptive to theme suggestions – to add to the paid expansion pack – if you find something you like in the Visual Studio Code Marketplace.
  • The only way it officially allows any custom theming is with an unusual mechanism documented only in a tangential GitHub discussion: you select the theme called “Use CSS Variables”, which is a ‘theme’ that merely specifies var(--xyz) values for the color CSS property. You’re then expected to specify values for those CSS variables in some suitable stylesheet (which the plug-in does not facilitate).
    
    This custom theming functionality is only available in the paid version.
  • It only officially supports adjusting the colours – you nominally don’t have the ability to adjust font families, sizes, weights, or styles.
    
    It is possible to match each type of element, but it’s pretty clumsy and fragile, because…
  • As mentioned under Pros, it inlines the style information directly into the HTML span tags, as simple color style attributes. While that’s good for avoiding rendering glitches, the downsides are that:
    • It produces more verbose HTML than if it just used a short class name on the spans (as all the other plug-ins do), which can hurt page load times.
    • It’s more difficult to customise the styling with CSS, since you have to match on the colours – using CSS attribute queries like span[style*=#xxyyzz] – which is not just awkward but can be impossible to do precisely for multiple distinct grammar elements depending on the base theme used.
    • It optimises the HTML by merging (server-side) span elements with the same style information. That’s great for reducing page size and load times, but if the base theme doesn’t already visually distinguish between two distinct grammar elements, it’s impossible to distinguish them through custom CSS.
• Custom themes don’t render in the post editor – you just get plain pre-formatted text. (built-in themes work fine in the editor)
• Uses a custom Gutenberg block type, rather than just extending the standard Code block. So you can’t just upgrade your whole existing site – you have to manually go through and find every existing Code block, and manually migrate each one.
  
  Inversely it’ll also be more difficult to migrate away from, if you choose to do that some day, as you’ll likely have to repeat that whole process no matter what replacement plug-in you choose.
• If you enable the ‘Copy’ button for the convenience of your readers, it includes a duplicate copy of the code in a hidden span (as do at least some of the other plug-ins tested, although I didn’t always call it out here).

So in a nutshell, if you’re completely happy with its built-in theme options, then this is one of your better options. But if you want theme customisation, it becomes worse than many of the other plug-ins, sadly.

CodeColorer

A very old – though nominally still maintained – plug-in uniquely based on GeSHi.

It’s open source and free (as is the GeSHi engine underneath it).

Neither the plug-in itself nor the GeSHi engine have seen a lot of activity in recent years (and confusingly the old GeSHi webpage is still up as is the early GeSHi page on SourceForge, creating an even worse first impression). Both predate the [public] existence of Swift entirely.

To be honest I’m including it here only for completeness. It basically doesn’t work – especially for Swift – and shouldn’t actually be considered. It seems intended solely for use via shortcodes – even though it does take over all existing <code> blocks – which I didn’t test as the use of shortcodes in WordPress is archaic, and poorly supported in the modern (Gutenberg) editor. They seem to still be officially supported, and not formally deprecated, but I think introducing any new reliance on them at this point is foolish.

Performance

So, yeah… no syntax highlighting at all. It’s not apparent to me if this is a failure specific to Swift or if the plug-in in general just doesn’t work. It does offer a [non-live] preview in its settings, which does work for its example snippet of JavaScript.

It also (by default) forces the code into a tiny box, although you can fix this through its settings.

There’s no per-use customisation since it just takes over any existing <code> blocks, and there’s very few global settings – including an absence of any setting for a default language.

I won’t bother trying to enumerate its specific pros and cons – it’s clearly not a viable contender.

Code Syntax Block

A simple plug-in based on Prism.js, with very limited customisation options.

It’s open source and free (as is the Prism.js engine underneath it).

Performance

Prism.js prides itself on being [relatively] small. Perhaps because of that goal of being “lightweight”, its performance is a bit mediocre.

The default theme makes it look even worse than it really is, because it bizarrely doesn’t provide any distinguishing styling for important things, like type names.

On the upside, it does get a few things right which other plug-ins often don’t – even others which also use Prism.js, curiously, like Highlighting Code Block. Things like it:

• Recognises @-attributes, such as macro and property wrapper invocations.
• Recognises relatively new Swift keywords such as async & await.
• Understands multi-line and raw strings.

On the downside it:

• Doesn’t recognise a lot of very basic Swift syntax – or, at least, doesn’t distinguish them with a span and therefore resigns them to the default, plain text styling of the overall code block – including but not limited to:
  • Variable names (neither their declaration nor references to them).
  • Function parameter labels & names.
  • Property names.
  • Tuple field labels.
• Doesn’t recognise method calls consistently (e.g. pack & reduce vs map in the example shown).

Although you can’t tell with its default theme, it actually recognises custom type names (although doesn’t distinguish them from Swift standard library types, like Xcode – though it’s debatable whether that’s a feature).

It uses font weight, not just colour, which would go a long way towards giving it higher fidelity without making it look garish if it didn’t use it really weirdly. Instead of bolding keywords, for example, it bolds function & method names – sometimes, when it recognises them correctly.

At least it defaults to Menlo, which is actually a respectable choice and makes it one of the few plug-ins tested that have a decent default for Apple platforms. In case you’re unfamiliar, Menlo was the default monospace font for Snow Leopard through Yosemite (before it was replaced by SF Mono). You’d most likely have encountered it in Terminal or Xcode, if you used a Mac in that timeframe (2009 – 2015). It’s still available on every Apple device (as of time of writing, December 2023).

Pros

• Extends the built-in, standard Code block. This makes it comparatively trivial to adopt if you’ve already got Code blocks on your website (although you may still need to go through and customise some things, such as the language in case auto-detection doesn’t work correctly).
  
  This also makes it easier to switch syntax-highlighting plug-ins, provided that the one you switch from or to also supports the standard Code block, which is sadly a minority of them.

Cons

• Hasn’t been updated in a year – possibly abandoned.
• Does everything client-side, so there’s a noticeable delay before syntax highlighting is actually applied (especially on first load, when the relevant JavaScript & CSS isn’t cached in the browser). It’s a bit visually jarring as the unstyled code is replaced with the styled.
• Adds its Prism CSS & JavaScript files to every page load, irrespective of whether the page actually needs them or not. This is the core Prism.js library only – the grammar file for each language is only loaded when actually needed.
  
  They are somewhat small files, at least – most of it is Prism.js at 30 KB alone, plus a few extra KBs for the chosen theme’s CSS. With Brotli compression they’re ~13 KB. Language grammar files tend to be only 3 KB or less.
• Very few built-in themes – only four – and using a custom theme is technically possible but awkward. The official instructions didn’t work for me, either – I had to use the WPCode plug-in to execute the relevant PHP:
  
  add_filter('mkaz_prism_css_url', function() {
    return '/wp-content/themes/prism-xcode.css';
});
• Theming is controlled globally with no ability to override it for specific uses.
  
  This is (IMO) better than not having any global controls at all, as with some plug-ins, but it can be problematic if you use more than one language in these code blocks across your website, as you might prefer different themes for different languages.
  
  You can technically work around this limitation using custom CSS, since the language is included as a class on the relevant pre and code HTML elements.
• Doesn’t render the syntax highlighting in the Gutenberg editor, so you’re stuck with the generic pre appearance there.

Enlighter

The official WordPress plug-in for the EnlighterJS engine.

It’s open source and free (as is the EnlighterJS engine underneath it).

Performance

Generally it does a poor job, with Swift code, and it’s not really a mystery why – its grammar file for Swift is especially spartan and hasn’t been updated since it was created over five years ago! That’s the Swift 4.1 era at best.

It actually behaves very similarly to the SyntaxHighlighter Evolved plug-in, but with the significant difference that it leaves things it doesn’t understand as the plain text colour (e.g. black in Light mode), so it’s much more apparent even at a glance that it doesn’t really understand much.

For example, it:

• Doesn’t understand @-attributes, such as macro and property wrapper invocations.
• Has no idea about the difference between function parameter labels and parameter arguments.
• Doesn’t consistently recognise references to properties, such as when they’re part of KeyPaths.
• Doesn’t understand some important keywords, like async, await, Never, etc.
• Recognises only a limited selection of types – all from the Swift standard library – and has no idea about custom types.
• Doesn’t recognise method calls consistently (e.g. pack & reduce vs map in the example shown).

In a nutshell, it’s doing little more than picking out a pre-defined list of keywords, identifying string & numeric literals, and comments.

Though it does at least handle multi-line and raw strings correctly (albeit only in some themes – in a few it underlines strings and mistakes the indentation as part of the string, for multi-line strings).

The choice of Courier New as the default font is… brave. It’s not actually its preferred default – it favours Source Code Pro foremost, with Liberation Mono as a second choice. They’re both reasonable open-source monospace fonts, but neither are standard fonts on any Apple devices, and the plug-in doesn’t include them.

You can customise the font to a very limited degree – the plug-in provides only five options, none of which are standard Apple OS fonts so the choice is effectively pointless. Thankfully you can override its font choices, like pretty much all its styling, with custom CSS.

Pros

• Supports both a global theme setting as well as use-specific overrides.
• Supports both soft & hard wrapping (the latter meaning it uses a horizontal scroller if necessary, rather than fitting the text to the viewport – generally not what I recommend since it’s pretty hostile to small screens but it’s a notable feature to make this behaviour configurable).
• Includes a pretty extensive theme customiser, as an actual HTML forms-style interface in the plug-in settings pages. That GUI is ultimately just a bespoke configurator for the CSS – which helpfully it also provides, in case you want to save or serve that elsewhere.
  
  And if that proves insufficient – or you just prefer to do it manually – it uses a sensible system of spans with suitable classes, so it’s easy to write custom CSS for styling.
• Provides its own Gutenberg block, but can also optionally be applied to the built-in WordPress Code block, as well as potentially blocks from other plug-ins (Crayon Syntax Highlighter & CodeColorer are explicitly supported – unclear if it also supports Urvanov Syntax Highlighter, the ‘reincarnation’ of the otherwise abandoned Crayon Syntax Highlighter).

Cons

• Built-in themes are pretty limited and (IMO) pretty ugly, at least for the light-style ones (which is ten of the thirteen). The one demonstrated here is the default – just called “Enlighter” – which is about the best it has to offer. 😕
• Puts its settings item at the top level of the WordPress admin menu, rather than under Settings.
• Adds its CSS & JavaScript files to every page load, irrespective of whether the page actually uses the Enlighter block or not. Along with some inline JavaScript in every page header.
  
  And they’re not trivial files, either. The CSS is 80 KB uncompressed – ~10 KB with Brotli compression, larger with GZip or Zip (Deflate). That’s factoring in CSS minification, too. The JavaScript is 63 KB uncompressed (~19 KB with Brotli).
  
  It does offer an option to supposedly avoid this – “Dynamic Resource Invocation” – but it’s disabled by default, and still requires inclusion of a “small” 1 KB JavaScript file with every page load just to determine if the rest of the code & CSS should be loaded. So, kind of a hack to try to cover up a design flaw. Alternatively, you can disable automatic inclusion of the CSS & JavaScript files and handle that manually, but I can’t imagine anyone actually wants to have to deal with that.
• Doesn’t render the syntax highlighting in the Gutenberg editor, so you’re stuck with the generic pre appearance there.

So, overall a pretty poor option, both in terms of how well it understands Swift – i.e. particularly badly – and how it looks out of the box. It does have a lot more options than most of the other plug-ins, and its GUI for theme editing might be a unique selling point for a – presumably rather limited – market of people that want to include Swift code on their website but aren’t comfortable writing CSS. Even that withstanding for argument’s sake, I think it falls solidly towards the bottom of the pile.

Highlighting Code Block

A relatively simple plug-in based on Prism.js, with limited customisation options.

It’s open source and free (as is the Prism.js engine underneath it).

Performance

Prism.js prides itself on being [relatively] small. Perhaps because of that goal of being “lightweight”, its performance is pretty poor – and pretty obviously so even at just a glance.

For example, it:

• Doesn’t understand @-attributes, such as macro and property wrapper invocations.
• Has no idea about the difference between function parameter labels and parameter arguments.
• Doesn’t consistently recognise references to properties, such as when they’re part of KeyPaths.
• Doesn’t understand some important keywords, like async & await.
• Doesn’t recognise method calls consistently (e.g. pack & reduce vs map in the example shown).
• Doesn’t understand multi-line nor raw strings.

On the positive side, it actually recognises custom type names (although doesn’t distinguish them from Swift standard library types, like Xcode – though it’s debatable whether that’s a feature).

It uses italics, not just colour, which goes a long way towards giving it higher fidelity without making it look garish. Unfortunately, its use of italics is weirdly inconsistent – e.g. it italicises some keywords but not all (e.g. final vs class), and italicises some type names but not others (e.g. VStack vs Image & Text).

It doesn’t take much effort to understand why – it’s using a very simplistic parser that knows virtually nothing about the language (other than a hard-coded list of keywords) and instead is just going off of capitalisation, mostly. Which is somewhat clever, and gets it a long way for such a simple method, but ultimately results in poor performance.

At least it defaults to Menlo, which is actually a respectable choice and makes it one of the few plug-ins tested that have a decent default for Apple platforms. In case you’re unfamiliar, Menlo was the default monospace font for Snow Leopard through Yosemite (before it was replaced by SF Mono). You’d most likely have encountered it in Terminal or Xcode, if you used a Mac in that timeframe (2009 – 2015). It’s still available on every Apple device (as of time of writing, December 2023).

It’s a bit weird that the performance is significantly different from some other Prism.js-based plug-ins, like Code Syntax Block. It’d be explicable if one plug-in were strictly superior to the other – suggesting simply use of a newer version of Prism.js by one than the other – but it’s actually a weird mix of improvements and regressions.

Pros

• Good bang-for-your-buck configuration options, which is to say that it has relatively few but it includes the essentials and with maximum flexibility (e.g. font customisation is by entering the actual font-family CSS string, rather than being limited to do a predefined short list of options as with most other plug-ins).

Cons

• Does everything client-side, so there’s a noticeable delay before syntax highlighting is actually applied (especially on first load, when the relevant JavaScript & CSS isn’t cached in the browser). It’s a bit visually jarring as the unstyled code is replaced with the styled.
• Adds its CSS & JavaScript files to every page load, plus some inline CSS & JavaScript, irrespective of whether the page actually needs it or not. This includes the entire Prism.js library with grammar parsers for every supported language, irrespective of which ones are actually used.
  
  And they’re not entirely trivial files, either – mainly because of Prism.js at 35 KB alone. Overall they’re 41 KB before compression (~18 KB with Brotli).
• Limited theming control – it has an unnamed built-in default, which you can override by specifying a server-side path to a custom CSS file (although functionally this isn’t much different from just putting your custom CSS in your website’s general custom CSS file, because of the aforementioned flaw whereby this plug-in inserts its CSS into every page load).
• Theming is controlled globally with no ability to override it for specific uses.
  
  This is (IMO) better than not having any global controls at all, as with some plug-ins, but it can be problematic if you use more than one language in these code blocks across your website, as you might prefer different themes for different languages.
  
  You can technically work around this limitation using custom CSS, since the language is included as a class on the relevant pre and code HTML elements.
• Includes support for a relatively small number of languages (by default), although that does include Swift and Objective-C, among many other popular languages. I list this as ‘con’ only in a relative sense – for most users its built-in shortlist is likely quite sufficient.
  
  You can provide a custom build of Prism.js if you need others, although it’s left as an exercise to the user to figure out how to do that (and to then maintain it).
• Doesn’t render the syntax highlighting in the Gutenberg editor, so you’re stuck with the generic pre appearance there.
• Uses a custom Gutenberg block type, rather than just extending the standard Code block. So you can’t just upgrade your whole existing site – you have to manually go through and find every existing Code block, and manually migrate each one.
  
  Inversely it’ll also be more difficult to migrate away from, if you choose to do that some day, as you’ll likely have to repeat that whole process no matter what replacement plug-in you choose.

Prismatic

A uniquely versatile plug-in that supports both the Prism.js and highlight.js engines.

It’s open source and free (as are the Prism.js and highlight.js engines underneath it).

Unfortunately, it immediately disqualified itself by simply not working. After installing & activating it in WordPress, nothing happens. The built-in Code block doesn’t change, there is no new Gutenberg block (contrary to its documentation which claims it adds a “Prismatic” block), and nothing appears anywhere in the WordPress Admin menu, such as a global settings page.

I checked the PHP logs and found no mention of the plug-in nor any relevant log messages.

It’s unusual – in my experience – for a WordPress plug-in to just silently fail like this. While it might be possible to enable WordPress debug logging and ultimately figure out what’s going on, in my experience first impressions are indicative when it comes to WordPress plug-ins, so I’m not going to spend time trying to get a plug-in to work at all when it’s probable it’ll have numerous other problems anyway.

Syntax-highlighting Code Block (with Server-side Rendering)

Nominally a fork of Code Syntax Block that renders server-side instead of client-side, although it uses a different engine – Highlight.php instead of Prism.js.

highlight.php is a PHP port of Highlight.js. It’s unclear to me how closely or promptly that tracks changes to the original JavaScript library.

It’s open source and free (as is the highlight.php engine underneath it).

Performance

The default theme is particularly bland. It’s actually hard to judge its understanding of Swift purely from its appearance since so much of it looks the same.

It’s noteworthy as a particularly hostile plug-in (with its default theme) for colourblind viewers, due to its use of very similar shades for almost everything, and in particular its use of red vs grey in a way which makes them virtually indistinguishable to a significant portion of the population. It’s not the only plug-in to be thoughtless in this way, but it is the worst.

It does come with a lot of other themes – nearly ninety at time of writing – but you’d be forgiven for thinking it does not, as it puts the theme selection setting in a surprising location – the ‘Customize’ section of WordPress’s Appearance settings. While this actually makes tremendous sense, no other syntax-highlighting plug-ins put their settings there. It’s hard to hold that against this plug-in, for being the one plug-in which (arguably) does the right thing, but I almost overlooked this critical functionality – I only discovered it by chance because I happened upon its Advanced Usage documentation.

That all said, one thing the bland default does have going for it is that the visual sameness helps to slightly obscure how poorly the plug-in understands Swift.

For example, it:

• Doesn’t understand @-attributes, such as macro and property wrapper invocations.
• Has no idea about the difference between function parameter labels and parameter arguments.
• Doesn’t consistently recognise references to properties, such as when they’re part of KeyPaths.
• Doesn’t understand some important keywords, like async & await.
• Doesn’t recognise method calls consistently (e.g. pack vs reduce & map in the example shown).
• Doesn’t understand raw strings (though it does handle multi-line strings correctly).
• Is fooled by the use of keyword-looking names in places where they aren’t keywords, e.g. the default static property of HomeItem.

It’s pretty apparent, especially once you look at the HTML itself, that it’s doing only a rudimentary analysis mainly based on a hard-coded list of keywords and heuristics like whether words start with capital letters. That’s why it confuses literals (strings & numbers) with type names, function names with property names, and so forth. It’s not the only plug-in to try to fake it with such a simplistic algorithm, but it does the worst job of pulling it off.

It renders keywords in bold (like Xcode), which greatly aids readability.

Since it uses the built-in WordPress Code block as its basis, and doesn’t muck with the fonts, it defaults to whatever the active WordPress theme uses. As shown in this example, with GeneratePress, that’s not even necessarily a monospaced font! Worst, the plug-in has no built-in configuration option for font (although you can use custom CSS to override it).

Pros

• Extends the built-in, standard Code block. This makes it comparatively trivial to adopt if you’ve already got Code blocks on your website (although you may still need to go through and customise some things, such as the language in case auto-detection doesn’t work correctly).
  
  This also makes it easier to switch syntax-highlighting plug-ins, provided that the one you switch from or to also supports the standard Code block, which is sadly a minority of them.

Cons

• No official theming support.
  
  You can use custom CSS to re-theme it, thanks to its use of sensible class names for its spans, but other than fixing its bland default colours you can’t really improve it much, since a lot of the code is emitted as runs of plain text because of the plug-in’s very poor understanding of Swift.
• No global settings – if you decide to change any settings, at any point, you have to manually find and adjust every existing code snippet manually.
  
  This might be considered a positive by some users, where they want existing content to remain as-is. However, some plug-ins offer both a global setting and the ability to override that on a per-case basis, providing more flexibility.
• Very limited settings – just the language (if you don’t want to rely on auto-detection), which line(s) to highlight, whether to soft wrap, and whether to show line numbers.

SyntaxHighlighter Evolved

This is what I was using for years. It’s completely free and open source. It uses a proprietary syntax parsing system based on regular expressions.

Performance

It’s an interesting one, because it actually understands so little Swift syntax that most of it is bucketed together as ‘plain’ text. However, because it renders ‘plain’ text in a colour other than black, it gives the surprisingly convincing (at a glance) illusion that it understands much more than it really does.

Overall its rendering is close to Xcode’s, which is very surprising given its highly rudimentary grammar parser.

It is actually pretty good about identifying keywords – it actually gets async which many do not – but it doesn’t understand them with context, e.g. it mistakes the default static property of HomeItem with the default keyword.

It renders keywords in bold (like Xcode) which greatly aids readability, although note how (unlike Xcode) it messes up the letter spacing as a result (this is a result of the font used – Monaco – and thus can be fixed by overriding that with a better font, e.g. SF Mono).

While it covers up a lot of its ignorance with its clever colour choices, there’s still a few important things that it gets visibly wrong. For example, it:

• Doesn’t understand @-attributes, such as macro and property wrapper invocations.
• Has no idea about the difference between function parameter labels and parameter arguments.
• Doesn’t understand raw strings.

Its choice of Monaco as its font is… interesting, although modern versions of Monaco are thankfully a little smoother than their 1980s ancestor. That’s easy to override, however, via custom CSS in a suitable WordPress-generic stylesheet (the plug-in doesn’t provide any direct way to manipulate styling, beyond choosing from a short list of built-in themes).

Pros

• Most of its settings are global. So changing themes for a whole site is trivial.
• Uses sensible HTML structure and class names, so it’s easy to unofficially re-theme (although it has a very limited vocabulary of grammar, so you can’t greatly improve what you see here).
• Supports end-user editing of the code (with the syntax highlighting updating appropriately). This is purely superficial text editing – there’s no support for interpreting, compiling, or executing the code. So I’m not really sure what the point of this feature is, but I list it here since it is unique to this plug-in (amongst all those I tested).

Cons

• Doesn’t formally support light/dark mode (as do none of the plug-ins tested). Colours are fixed (to whatever theme you choose) irrespective of the end-user’s light/dark setting (again, same as all the other plug-ins). However, one difference versus all the other plug-ins is that this one doesn’t work properly with WP Dark Mode – it remains in light mode even while the rest of the page renders correctly in dark mode.
  
  I strongly suspect the fault lies in WP Dark Mode, not SyntaxHighlighter Evolved, but irrespective it is there and might be a deal-breaker if you’re particularly attached to WP Dark Mode.
• Doesn’t render the syntax highlighting in the Gutenberg editor, so you’re stuck with the generic pre appearance there.
• Uses a custom Gutenberg block type, rather than just extending the standard Code block. So you can’t just upgrade your whole existing site – you have to manually go through and find every existing Code block, and manually migrate each one.
• Doesn’t get updated super often, although it has been around for years and has generally kept up with new WordPress versions, eventually.

Urvanov Syntax Highlighter

A fork of the abandoned Crayon Syntax Highlighter that uses its own syntax-highlighting engine.

It’s open source and free.

I almost didn’t include this because (a) it’s really very broken and (b) it doesn’t really support Swift at all. I strongly recommend against using it, for numerous reasons.

Performance

Pretty terrible, in a nutshell. I’m not going to go into full detail here because the plug-in is largely broken anyway (details shortly, in the Cons section).

Ironically it works better out of the box than if you actually configure it “correctly”; it doesn’t recognise this example as any specific language and falls back to some generic “Default” grammar parser. If you explicitly set it to Swift, the syntax highlighting actually gets markedly worse, and it’s no surprise why – its Swift grammar definition is nearly a decade old, dating back to Swift 1.0 in 2014!

One of its most egregious rendering problems is that it translates various special characters – [, <, >, etc – to their escaped HTML entities. This can be ‘corrected’ in its settings – it has a “Decode HTML entities in code” option – but that’s a hacky bandaid over the bug, that precludes you from actually using HTML entities in your code example (so you can’t use this plug-in for the HTML language itself).

Another rendering annoyance is that it makes the code block’s width 100%, irrespective of the actual width of the code. Most of the plug-ins do that, actually, but it’s much more apparent with this one because of its use of a visual border and alternating line background colours. You can configure a maximum width in its global settings, but (as with most of these plug-ins) there’s no (built-in) way to make it size to fit.

On syntax understanding itself, it basically has none. It simply recognises some fairly general syntax patterns, such as strings, literals, and parenthesis-indicated function calls. It doesn’t recognise most keywords, even.

Pros

• Very configurable – perhaps the most configurable plug-in tested. Beyond just theming options – including the ability to easily change the font from its default of Monaco – it includes options rarely covered by other plug-ins such as margin customisations.

Cons

• Nominally offers a Gutenberg block, but it doesn’t work – you cannot actually edit the textual contents, in the Gutenberg editor, and it doesn’t render at all on the actual published page. Thus you can only use the plug-in by having it take over existing <code> and/or <pre> blocks…
• Takes over all existing <code> and <pre> blocks by default, even those by other plug-ins, and those that don’t contain code at all (e.g. where you were simply presenting monospaced text such as Terminal output). You can configure this in the settings, including turning it off, but given the Gutenberg block doesn’t work, this is the only way to actually use the plug-in.
  
  
  
  I spent some time playing with different combinations of these settings, but many combinations are inexplicably unusable – they just result in broken rendering – and I couldn’t find anything that improved on the default behaviour.
  
  As such, this is an especially all-or-nothing syntax highlighter. It really doesn’t play well with others.
• Since it just takes over existing <code> and/or <pre> blocks, there’s no per-use customisation possible – everything is exclusively controlled through global settings, including the code language.
• By default adds its CSS & JavaScript files to every page load, plus some inline CSS & JavaScript, irrespective of whether the page actually needs it or not. This can nominally be corrected in the settings, via the “Attempt to load Crayon’s CSS and JavaScript only when needed” option, but I didn’t test it (and it’s not encouraging that it’s both disabled by default and uses the word attempt, both suggesting this feature doesn’t work reliably).
  
  And they’re not entirely trivial files, either, even though rendering is done server-side – its JavaScript is 65 KB alone! Its CSS is another 28 KB. With Brotli compression they’re ~18 KB. They compress well in part for the same reason they’re so egregiously large – the use of “urvanov-syntax-highlighter” / “urvanov_syntax_highlighter” prefixes on so many of the names. This bloats up the page source as well, with oversized HTML class names for every snippet of styled code.
• Doesn’t render the syntax highlighting in the Gutenberg editor, so you’re stuck with the generic pre appearance there.

The winner

…is hard to pick unilaterally. Each plug-in has significant limitations or trade-offs. Which is best may depend on your personal preferences and specific needs.

Most of the plug-ins do a pretty atrocious job at actually understanding Swift, and at best for them it’s a question of how well they can fake it through clever heuristics and styling choices. SyntaxHighlighter Evolved warrants an honourable mention in this regard for doing a particularly impressive job despite its very limited brains. There’s a reason I used it for years with relatively few complaints, and if it hadn’t had issues with WP Dark Mode – before I realised WP Dark Mode was buggy anyway and had to be replaced – I probably wouldn’t have bothered doing all this competitive research, and wouldn’t be switching away from it.

The most common engines used by syntax-highlighting plug-ins are Prism.js and Highlight.js / Highlight.php, but frankly they’re bad at Swift – a situation that’s unlikely to change given Swift is such a niche language for them; they’re clearly focused on browser languages like JavaScript, HTML, and CSS. Even that aside, they tend to use client-side rendering which is slower and buggier.

It currently does a somewhat average job in understanding Swift and rendering it pleasingly – just like all the plug-ins tested – but it seems to have the most promising foundation, being based on the same grammar & theme files as are used by Visual Studio Code (and GitHub). So it has the possibility of significant improvements in future; at the very least it would make sense for the Swift community to focus on it since the benefits will be applicable not just to WordPress websites but also Visual Studio Code and GitHub.

Refinements to Code Block Pro

Every light-style theme available with Code Block Pro – including the paid expansion pack – has significant rendering errors for Swift, but after spending an egregious amount of time exploring the themes and experimenting with fixes for them, I’ve concluded that Light Plus is the least bad option. With some crude but simple CSS I’m able to adjust its appearance as shown here, which is loosely styled after Xcode’s default (light mode) theme.

I didn’t do much to accomodate Dark mode, limiting my modifications there to merely using SF Pro (“system-ui”) for comments. I don’t use Dark mode myself, so I might not have a good eye for what looks good there, but the default colours (from the simple inversion by the Dracula Dark Mode plug-in) seem alright to me. And pragmatically, I’d have to overwrite every colour used in the theme in order to ensure no rendering issues, and that’s a whole lot of CSS I don’t want to write nor bloat my page loads with.

I also turn on “Disable padding” in its “Extra Settings”, as by default it uses (a) hard-coded padding dimensions, in pixels and (b) padding, not margins. A strange choice, but at least it has the option to disable it.

div.wp-block-kevinbatdorf-code-block-pro {
	font-family: "SF Mono", SFMono-Regular, ui-monospace, monospace;
	width: fit-content;
	margin: 1em;
	
	& span[style*=\#0000FF], span[style*=\#AF00DB] { /* Keywords */
		font-weight: 675;
		color: #9B2393 !important;
	}
	
	& span[style*=\#008000], span[style*=\#81f179] { /* Comments */
		font-family: system-ui !important;
		font-style: italic;
	}
	
	& span[style*=\#008000] { /* Comments */
		color: #5D6C79 !important;
	}
	
	& span[style*=\#001080] { /* Properties */
		color: #3E8087 !important;
	}
	
	& span[style*=\#795E26] { /* Function names and argument labels */
		color: #804FB8 !important;
	}
	
	& span[style*=\#267F99] { /* Type names */
		color: #4B22B0 !important;
	}
	
	& span[style*=\#A31515] { /* String literals */
		font-weight: 500;
		color: #D12F1B !important;
	}
	
	& span[style*=\#098658] { /* Numeric literals */
		font-weight: 500;
		color: #272AD8 !important;
	}
}

What are other websites using?

I figured it might be helpful to look at what other Swift-code-rendering websites use, to see if there’s any I missed (there wasn’t) and which the community seems to believe is best.

• Swift by Sundell is using Publish and the Splash plug-in. Splash seems to do a pretty good job – clearly better than any JavaScript or PHP syntax highlighters.
• Hacking with Swift is using WordPress and ultimately Prism.js, although I’m not sure through which plug-in (possibly Code Syntax Block).
• Cocoa with Love might be using some Ruby-based platform or static generator, but it’s clear it’s using Rouge for syntax highlighting.
  
  Sidenote: Rouge seems to do a decent job of correctly identifying tokens and their types, although its underlying model looks pretty simplistic (it tends to default to the “n” class by default, meaning “name”, meaning it doesn’t really know if it’s a parameter label, parameter name, type name, etc).
• Donny Wals is using WordPress with the Syntax-highlighting Code Block plug-in, which uses Highlight.php (based on Highlight.js).
• Matteo Manferdini is using WordPress with the GeneratePress theme (same as this site, at time of writing) and ultimately Prism.js, likely through Code Syntax Block.
• NSHipster appears to be statically generated with a bespoke tool written in Ruby using a custom fork of Rouge.
• The old Swift Blog uses… I don’t know. Possibly a proprietary system, for both the platform and the syntax highlighting. I didn’t find any identification or indicators otherwise of any particular library.
• The newer Swift Blog uses… possibly the same mystery platform as the old one. But it does clearly use Rouge for syntax highlighting.
• Swift Evolution Monthly is hosted on Substack and doesn’t do any syntax highlighting at all!
• Swift with Vincent is hosted on Squarespace, which ultimately uses Prism.js.
• Swift with Majid is statically generated using Jekyll and uses Rouge.
• Swiftinit (by Dianna a.k.a. “taylorswift” / “tayloraswift“) uses a proprietary platform (written in Swift). The syntax highlighting is presumably also proprietary.
  
  Sidenote: there’s not a lot of syntax-highlighted code on Swiftinit (mostly it’s in some hidden blog posts from 2022), but what’s there looks pretty similar to what Rouge generates. It does a pretty good job of correctly interpreting the syntax, although there’s not a great deal of apparent fidelity – mostly it’s just dividing things into formal names (types, functions, etc), variables, keywords, and everything else.
• SwiftLee is using WordPress and the Code Syntax Block plug-in, which is Prism.js underneath.
• SwiftRocks is using Bootstrap and Prism.js.
• SwiftUI Lab is using WordPress and the Prismatic plug-in, which is configurable to either Prism.js or Highlight.js underneath; the site has elected to use Prism.js.
• TrozWare is using Hugo and Prism.js.
• Yet Another Swift Blog is statically generated using Jekyll and uses Rouge (though oddly I also see fragments of Prism.js and Highlight.js on the site, although I didn’t see any actual use of them to render code).

If you’re keeping score, that’s (syntax-highlighter-wise):

• Prism.js: 7
• Rouge: 5
• Unknown: 2
• Highlight.js: 1
• Splash: 1

And platform-wise:

• WordPress: 5
• Unknown: 3
• Jekyll: 2
• Proprietary: 2
• Bootstrap: 1
• Hugo: 1
• Substack: 1
• Squarespace: 1
• Publish: 1

It’s notable that not one is using Code Block Pro nor the underlying Shiki engine, even though (with the serious caveats mentioned earlier) they do the best job of actually understanding Swift.

1. Strictly-speaking not for any technical reason, as the plug-ins could run more advanced tooling on the server (as some bespoke CMS’s do), but I have not encountered any WordPress plug-in which does so. ↩︎
2. Technically you can do it with just custom CSS, by overriding your theme’s defaults inside a @media (prefers-color-scheme: dark) block, but this is likely impractical for all but the most simplistic and static WordPress installations – you have to be sure you catch every GUI element and colour. A good plug-in will dynamically rewrite the CSS client-side, ensuring everything is covered. ↩︎

A major reason I purchased an Apple Watch Ultra was for its loudly advertised ability to function as a dive computer, much like some Garmins.

It’s been a rough and disappointing road.

Right out of the gate, it didn’t work. It requires a 3rd-party application, Oceanic+, which didn’t exist at Apple Watch Ultra release time. It was over two months before Oceanic+ was finally released, on November 28th.

As it happens, my dive trip plans were delayed a bit anyway, resulting in my first dive [since purchasing the Apple Watch Ultra] being on that exact day. Hallelujah, I thought. I was able to hastily install the app in the morning, before leaving for a remote, internet-less island for a week.

But then there was the surprise that it basically requires an expensive subscription ($80/year, or even more if you commit to less than a whole year). Without it you don’t get tissue load and NDL tracking – critical functions of a dive computer. I was not aware before purchase, from any of the Apple Watch Ultra advertising or product pages on Apple’s website, that this subscription would be required. It feels surprisingly shifty and dishonest from a company like Apple.

Arguably the above frustrations (and costs) could be overlooked if it actually worked well. Unfortunately, it does not.

I discovered serious flaws with Oceanic+ right from the first dive. Flaws that any qualified diver would immediately recognise, which begs the question of why Apple & Oceanic+ somehow haven’t.

There are two major design flaws in its most basic function, the recording of dives:

1. It doesn’t start recording automatically.
   
   You have to hit the “Action” button to acknowledge a lawyer-smelling disclaimer that you’re “fit to dive”. If you forget, it doesn’t record.
   
   I’m not aware of any other dive computer that does this. e.g. my Shearwater Peregrine autodetects submersion below one metre even if it’s not on. It turns itself on and starts recording automatically.
2. If you ascend above one metre, even just for a split second, it immediately ends recording.
   
   This makes shore entries, in particular, likely to go unrecorded (unless you’re able to swim out to deep water and descend rapidly, which isn’t always an option or the best dive plan). Descents in significant swell, currents, or surge could also fall victim to this design flaw.
   
   So on my first dive I got five “dives” recorded, representing the four times where the swell floated me up to just above one metre (I never actually broke the surface). Even just reaching up momentarily with your watch hand, such as to grab a line or brush away a fin, could trigger it to fail.
   
   Furthermore, there’s no way to merge these together in Oceanic+ – you can either keep them, messing up your dive counts and stats, or delete them, throwing away [parts of] actual dive records.
   
   And on later dives I didn’t always notice it had failed and stopped recording, so it basically didn’t record the dive at all. This will be less of an issue if you’re using it as your only computer, since you’ll be looking at it periodically throughout your dive (I was using a separate dive computer as my primary, since I wisely didn’t trust the Apple Watch Ultra untested).
   
   Again, I’m not aware of any other dive computer that has this flaw. e.g. my Peregrine allows a sixty second grace period before ending the dive (configurable for up to ten minutes).

These two combine to make it unsafe for diving. It might be better than nothing, or acceptable as a backup computer (as long as you’re religious about ensuring it’s recording all the time), but it’s arguably worse than no dive computer at all in that it provides a false sense of security – you might plan many dives in one day, relying on the Apple Watch Ultra to precisely track your tissue loading, but have it fail midway and leave you with a dangerous decision to make.

What makes this all the more frustrating is that there’s a lot of things to like about it otherwise:

• The Apple Watch Ultra screen is so much better than what you find on most dive watches – clear and readable, with relatively low glare, even in harsh daylight. Not to mention that it’s a touch screen, so [when dry, on the surface] it’s faster to change your settings, review your dive log, etc.
• The Apple Watch Ultra is a lot smaller than most dive computers. Even those that are nominally intended to dual-purpose as watches.
• The information display during diving is well-designed and user-friendly (certainly not as powerful as what you can get on other dive computers, but quite sufficient for basic recreational diving).

• The iPhone integration is smoother and easier than with other dive computers – dives appear on your phone automatically (albeit sometimes after a short delay).
• It records the geographic location of the dive, which many dive computers do not.
• Its configurable alerts – e.g. for depth, dive duration, etc – are nice and clear when they trigger underwater, with a clear and prominent visual display and strong vibration. I find that its alert vibration is much more likely to actually get my attention than that of my Peregrine.

It feels like it’s actually close to being a pretty good dive computer & companion app, if not for a handful of bizarrely obvious, serious flaws.

It feels, in fact, like it was very rushed – from the obviously daft design flaws noted above, to even just simple things like bad grammar, poor alignment, and broken layout in the GUI (it smells like they’re using SwiftUI and haven’t figure out how to work around all its layout problems). It seems they put more time into their slick website than their actual product.

And of course there’s the other hint that maybe real-world testing was skipped – the fact that the iOS Oceanic+ app crashes on launch if you don’t have a good internet connection. On a boat, far from land? Or a remote island? Or in Airplane mode? Or just in an area with poor internet connectivity? No app for you. Crash on launch, every time. Forget about entering your dive details into the log while you actually remember them.

This remains the case even after six app updates over a month. Apparently Oceanic+ either don’t care that their app usually crashes on launch, or are incapable of fixing it.

Maybe there’s hope that in time they’ll be able to straighten all this out. But until then, I cannot in good conscience recommend the Apple Watch Ultra for diving. (it remains a fantastic watch for health-tracking and hiking, though)

For completeness, a list of other miscellaneous flaws and limitations:

• Any time you ascend past six metres, it throws up an alert about a safety stop. Which keeps buzzing at you forever, until you hit the action button. It’s hard to overstate how annoying this is when doing shallow dives. It is super distracting and may put you in harms way (e.g. if you’re constantly having to fiddle with the Apple Watch Ultra instead of paying attention to the reef around you).
  
  I simply can’t fathom why they feel the need to alert for this at all. An alert would be warranted for skipping your safety stop, yet it doesn’t do that.
• It vibrates the Apple Watch Ultra frequently without any indication why (nothing changes on the display). Observationally, I suspect it’s something to do with ascending “too fast”, but if so then it’s way too sensitive to small depth changes – it vibrates at me when simply ascending less than a metre (even when tens of metres deep, where a metre makes very little difference in pressure).
  
  Overall, the Apple Watch Ultra is too chatty. It’s a classic boy-who-cried wolf problem waiting to happen.
• It doesn’t show CNS, current PPO₂, [surface] GF, etc. Especially when using enriched air (Nitrox), nearing no-decompression limits, or deep diving, these are important for safety. They are purely software features so it’s especially odd that they’re not included.
  
  Surface GF is arguably the most important of these – it basically tells you how dangerous it is to surface immediately. When everything goes smoothly – and assuming you’re planning safe, conservative dives – you don’t need to worry much about it. But when things go awry it can be critical in helping you make the right decision under pressure.
• There’s no Oceanic+ Mac app, or even a web version, which strongly discourages actually using Oceanic+ as your full dive log. Entering all the details of your dive – gear, notes, etc – is very tedious on an iPhone.
  
  Some other dive computer manufacturers do have Mac apps (e.g. Shearwater, albeit one that’s clearly made in some janky cross-platform framework and looks like something you’d find in X11 in the 90s), and there are a few viable 3rd party options (e.g. MacDive, Subsurface).
• The map it shows, of your entry & exit points, is useless most of the time, because it just shows as flat blue (for water) with no identifying geography. There’s no way to switch it to anything useful, like a satellite view that would actually reveal the reefs, sand bars, atolls, etc.
  
  This is exacerbated by Apple Maps’ limitations. Google Maps, for example, often does show atolls & islands at least, and other surface features. Apple Maps simply lacks actual maps for most of the world’s oceans.

• The iOS Oceanic+ app lets you record what gear you were using, but bizarrely requires you to pick from a pre-defined list and that list is missing gear from major brands (e.g. Aqua Lung, Cressi). Another reason why it won’t be your real dive log.
• There’s no way to import or export dive data. This is both a lock-in concern – your dive data will be deleted if you end your subscription – and also a roadblock to using the Oceanic+ app as your real dive log, unless you have never and will never dive without an Apple Watch Ultra.
• You can’t change the activity type – dive vs snorkelling – underwater, nor after the fact. So if you forget to change it before going for a snorkel, you’ll forever have a bogus “dive” in your log (or you can delete the record entirely, but then you lose record of any free diving you do).
• There’s five entries in the main menu in the Oceanic+ watch app, which are arranged as a scrolling carousel… which is just weird and annoying since they’d fit all on one screen as simple buttons, which would make navigation much faster and easier.
• A lot of actions on the Oceanic+ watch app require more steps than seem necessary. e.g. changing numeric values requires not just selecting a different value but also tapping back to the previous screen (which also feels unnatural, like I’m backing out of the change without applying it). There are menus trees five or more levels deep, whereas it seems like they could be flattened into just two or three levels.

• Relatedly, you can’t edit any of your settings on your iPhone, only the watch. You can view the settings on the iPhone, which just makes it even more baffling why you can’t edit them there. Editing them on the watch is great in a pinch – you might not have your phone with you – but it’s a pain compared to on an iPhone.
• The Oceanic+ iPhone app “Home” screen – what’s displayed when you launch the app – just shows a handful of stats of dubious merit. Minimum temperature over the last four weeks? Who cares. Cumulative total max depth? That clearly has no purpose. It seems like they knew they needed to show the most basic numbers – total dive count and duration – and felt compelled to stuff in a bunch more numbers for some reason. It’s also unclear why they think these are more important than your actual dive logs, or the dive planner.

• There’s supposedly seven watch complications available once you have Oceanic+ installed, but on my watch only two are available (“Max altitude” and “Oceanic Launcher”). This might be because I use a digital time display (the “Modular” face), something Apple seems to hate.
• The battery life is surprisingly short – about five hours of dive time. Given that the Apple Watch Ultra can record workarounds that are 16 hours long (at least – longer if you use energy-saving features), it’s a bit of a mystery to me why it chews through the battery so fast while diving. It’s not even monitoring your heart rate or other health metrics – just water pressure – and the screen brightness tends to be low since you’re underwater in low light.

Here’s a few things which are more just wishlist items (or: things you can get from some other dive computers, though you usually pay a lot more for those than you do an Apple Watch Ultra):

• Gas usage recording. Upmarket dive computers support wireless communication with a dongle that attaches to your first stage regulator. This means you can forgo a whole separate hose and dangly, annoying air gauge, and have a unified view of your dive status. It also means you get more accurate tracking of tissue loading, and more advanced functionality like gas consumption rates (great for extra safety – know if you’re going to run out of air too early – and for optimising your gas consumption over time).
  
  Radio protocols like Bluetooth don’t work underwater – lower frequencies are required. So the Apple Watch Ultra would require an additional built-in antenna. It’s arguably reasonable to omit this in a watch that’s not intended solely for diving, given the cost or other trade-offs it might require.
  
  That said, some air-integrated dive computers use sound instead of electromagnetism, and I suspect it’s not hard to support the necessary, inaudible frequencies in the Apple Watch Ultra’s microphone(s). Maybe this support is already present in hardware, and a transmitter dongle will be released later?
• Multi-gas support. Most dive computers support this, even those that are much cheaper than an Apple Watch Ultra. This is arguably a more “serious” or “technical” feature, that most recreational divers won’t ever need, but it’s also easy to do – it’s purely a software feature.
• The ability to enter key dive details on the Apple Watch Ultra (as opposed to an iPhone), such as gas start & end pressures. It’s all too easy to forget these in-between the dive itself and when you get back to land and your iPhone.
• The dive planner functionality is pretty rudimentary. e.g. you can’t do anything like actually enter a dive depth profile (whether as a squiggle with your finger, to give the rough idea, or importing it from a previous dive at the same site). The GUI is also a bit obtuse, especially in the Oceanic+ iOS app, as rather than showing a simple table or chart of depth vs no-deco times it makes you pick a single depth and gives you a single no-deco time. For planning you often want to consider multiple depth options and pick the right trade-off against dive (or at least bottom) duration.
• It might actually be nice to have some “social” functionality. Not for bragging and other vanity purposes – I’m not talking about inane integrations with Facebook or whatever – but for sharing amongst dive buddies and the like. I suspect there’s some neat, innovative possibilities here (e.g. automatically detect physically- & temporally-nearby dive friends, and be able to automagically see their photos & notes on what they saw on what’s presumably the same dive with you – maybe even add your own notes on theirs like “don’t forget about that Whale Shark eating that Orca!”).

And lastly just some miscellanea:

• Apple / Oceanic say that it won’t record below forty metres, but it does. Thankfully – the last thing you want if you do a deep dive, intentionally or especially unintentionally, is for your dive computer to not record your dive profile correctly.

I don’t regret getting my Apple Watch Ultra – it’s proven a worthwhile upgrade even just for its other features like battery life and a relatively large screen – but I am sad that I can’t actually rely on it for diving. And that I had to spend a lot of extra money to get a dive computer – the Peregrine – that I can rely on.

For reference, I’ve completed about fifty dives with the Apple Watch Ultra.

Addendum (May 2023)

I’ve now had the Apple Watch Ultra accompany me on about 150 dives. Sadly, despite it being a long six months later, little has changed. The Oceanic+ app is still awkward and very rudimentary, with the same data and platform lock-in problems. The Apple Watch component is almost unchanged – same limitations and GUI frustrations.

Two things which did improve at some point:

• Recording now happens when submerged even if you haven’t clicked through the lawyer screen. This is a significant safety improvement.
  
  However, if you go the entire dive and return to the surface without clicking through the lawyer screen, the recording is discarded. So there’s still danger here. You just get (a lot) more time to realise the watch is being obstinate (and you really should be looking at your Apple Watch Ultra at least once during the whole dive anyway, even if it’s just your backup, to ensure it’s working and to check its data against your primary).
• The Oceanic+ app seems to have fixed many of the glaring GUI bugs – e.g. the charts that rendered in the wrong places on the screen (or not at all), inconsistent font sizes and baselines, etc.

I haven’t systematically re-reviewed the Oceanic+ app, so perhaps there’s been additional fixes or improvements too. I’ve barely used it since my initial review, since I can only rely on my primary dive computer (Shearwater Peregrine) anyway. For what it’s worth, I use MacDive on my iPhone & Mac and am reasonably happy with it.

I wish I’d just bought the Shearwater Teric, though – the Peregrine was me hedging my bets and hoping that the Apple Watch Ultra would prove sufficient alone. The Peregrine is good but the Teric is much nicer (and for clear reason by far the most popular dive computer on the six boats I’ve dived from).

Values shown are the average over all trials with worst & best individual results shown in parenthesis.

Commentary

Surprisingly little performance difference

None of the cards tested are among the “known fastest” CFExpress cards, like the Delkin Blacks or ProGrade Cobalts. Nonetheless, I’m surprised at how minor the performance difference is between all of them, especially given there’s an XQD card in the mix.

CFExpress cards are not necessarily fast.

Angelbird AV PROs do not meet their promised performance

The Angelbird card claims a 1,000 MB/s minimum, sustained write speed. The XQD format is incapable of speeds above 500 MB/s. Yet the Angelbird is at best just 40% faster than the XQD Lexar. This suggests either the camera is the limiting factor – unlikely given that others have demonstrated much deeper bursts with other, apparently faster cards – or that the Angelbird doesn’t live up to its claims.

Blackmagic Disk Speed Test with a Pergear USB-C reader indicates the Angelbird almost hits 1,000 MB/s at the start of a sequential read or write, but within a second or two falls down to a sustained speed of only about 700 MB/s. And there’s that 40% difference again, vs XQD.

Average performance correlates with consistent performance

e.g. the Pergear 512 GiB is nominally about the same performance on average as the ProGrade 256 GiB, but the Pergear was much more consistent. The Angelbird was a tad faster & more consistent again.

This also highlights why many trials are important, in order to determine the variance. I’d rather have an on-average slower card that’s very consistent than a “bursty” card that might crap out in a critical moment and cause me to miss the moment completely.

30 & 120 FPS modes are camera limited

There was practically no difference in performance between the cards in 30 FPS & 120 FPS modes.

The bandwidth demonstrated is well below the demonstrated capabilities of all these cards, at just a few hundred MB/s.

All this seems quite conclusive that in these extra-fast burst modes the Z9 is the bottleneck, not the memory card.

Sidenote: The ProGrade card showed occasional glitches (three in total across twenty trials) – where the Z9 would suddenly stop shooting mid-burst, where a split second prior it had still shown a significant amount left in the “buffer” (the rXXX counter). I’m not sure what to make of that – perhaps the Z9 relies on some basic level of performance and the ProGrade can’t consistently meet it, or perhaps something is glitching between the Z9 & the ProGrade card that causes the Z9 to error out and stop working.

Methodology

1/250, 24-70/4 @ f4, ISO 5000.

Z9 firmware 1.11.

I enabled the shutter sound at maximum volume, and held down the shutter until I heard a stutter.

For 20 FPS mode:

• I counted any extra frames after the stutter and subtracted those from the numbers.
• I also tested 1/2500 and saw no meaningful difference in results, and ISO 64 & 25,600 which improved and decreased (respectively) buffer depth by about 10% each (very likely corresponding to the file size differences, though I didn’t check).
• Five trials, each testing each format in turn: lossless, HE*, HE.

For 30 & 120 FPS modes:

• I never heard an extra frame after the first stutter – I don’t know if that means the camera ground to a complete halt or merely that it doesn’t reliably play the fake shutter sound in these modes. The consistency of the results in those modes leads me to believe it’s the former.
• Ten trials, sequentially.

Cards were formatted in camera and empty at the start of each class of testing (20, 30, 120). Images were not erased between trials (empty cards are not representative of real-world conditions).

Autofocus was not engaged during shooting. I haven’t tested it comprehensively, but so far I’ve seen no impact on burst performance from using autofocus (including subject recognition).

In this post, I’m going to compare performance in the image centre between these three telephoto lenses at 400mm:

• Nikkor Z 100-400 (e.g. from Amazon).
• AF-S Nikkor 80-400G (e.g. from Amazon).
• Sigma 150-600 Contemporary (e.g. from Amazon).

Unlike in the first post, where the focus was solely on the 100-400, I won’t provide exhaustive sample images of all apertures for all lenses – that would just be overwhelming. Instead, I’ll just provide the noteworthy cases.

30ft @ 400

The 150-600 is basically the same from wide open (f/6) through to f/8. It might be a tiny bit sharper at f/6 than narrower apertures.

The perceived sharpness of the 80-400 increases slightly when stopping down from wide open, and starts to soften again at f/7.1 and narrower. Its optimal aperture is f/6.3, vs f/5.6 for the 100-400.

Note that in practice I’ve tended to favour f/7.1 on the 80-400, including on 24 MP DX cameras which have higher pixel densities than the Z7 (and therefore should be more sensitive to diffraction, not less). That’s based on a large amount of real-world experience. There’s several possible explanations for the discrepancy, but my guess is that the increased depth of field, of f/7.1 over f/6.3, helps in practice because it:

• Increases the depth of field (sometimes important at close distances or with deep subjects).
• Provides a little more tolerance for focus errors.

Prev 1of3 Next

The 150-600 is clearly the sharpest, followed by the 80-400. The 100-400 is much softer than even the 80-400. The 80-400 is sharper at any aperture than the 100-400 is at any aperture (and the 150-600 exceeds both, similarly).

This was such a surprise that I went back and took many more photos with the 100-400, in a variety of modes (various autofocus modes, manual focus, VR on & off, silent shutter on & off), but the results were consistent – the 100-400 is much softer at 400 than its eight year old predecessor, let-alone the 150-600.

Note: the difference in sharpness is partially obscured by the JPEG compression used for the images in this post, even though I used the maximum possible JPEG quality. All my written statements throughout these tests are based on comparing the NEFs in Lightroom.

12ft @ 400

The 150-600 behaves the same as at 30ft – basically the same from f/6 (wide open) through f/8. Maybe a tiny bit sharper wide open.

The 80-400 gives its best performance at f/6.3 again. As at 30ft, the difference with f/5.6 (wide open) or f/7.1 is slight. f/8 is very slightly softer again, as diffraction more clearly kicks in.

Prev 1of3 Next

Unfortunately the comparison between the three is complicated by the fact that the 80-400 back-focused slightly while the 100-400 looks like it again front-focused a tad. After accounting for that it’s clear that the 80-400 is sharper than the 100-400. But the 150-600 is much sharper than either of them.

6ft @ 400

The 150-600 is out for this particular subject distance because it can’t focus this close.

The 80-400 is slightly sharper at f/7.1 than other apertures. Similar to the 100-400 (which still saw tiny improvement up to f/8, over f/7.1).

Prev 1of2 Next

At this point the comparison is getting tricky, because:

• The 80-400 back-focused again.
• The 100-400 is maintaining its nominal focal length much better than the 80-400. This change in focal length over different focus distances is typical behaviour for lenses – the stated focal length is usually only achieved at infinity; as you focus closer, their effective focal length drops.

It’s pretty close, between the two. There seems to be similar resolution on the image sensor, so the difference in subject detail is solely because of the difference in effective focal length. If you allow for that, then there’s a notable advantage to the 100-400.

MFD @ 400

Note here that the 100-400 can get down to about 3ft, while the 80-400 is not much shorter than the 6ft looked at above, and the 150-600 is way out at 10ft or so.

So unsurprisingly the 80-400 behaves the same as at 6ft – sharpest at f/7.1. Just like the 100-400. And the 150-600 is very similar from wide open (f/6) to f/8, with maybe a very slight improvement from stopping down just a tad, to f/6.3.

Note that I’ve also included the 150-600 at 600, in case you’re interested in comparing the maximum possible magnification across the three lenses.

Note: I don’t know why there’s such significant discrepancies in exposure, particularly with the 80-400. This was reproducible. The same exposure settings were used for all lenses. Possibly the differing fields of view impacted the camera’s metering?

Prev 1of4 Next

Here there’s no contest – the 100-400 is sharpest on the sensor (albeit by only a small margin over the 80-400), but also offers much higher magnification – almost twice what either of the other lenses are capable of. This matches the spec sheets – a maximum reproduction ratio of 0.38x for the 100-400 vs 0.2 for the 80-400 & 150-600.

The 150-600 is the worst by far, for sharpness on the sensor as well as magnification – not only do you have to zoom in to “600” to get similar magnification as the 80-400 does at “400”, but both are basically at something more like 200 if not less.

In fact to my eyes it appears that there’s nothing but empty magnification in going from 400 to 600 on the 150-600.

Conclusion

😧A surprise upset! I had assumed the 100-400 would be at least as sharp as the 80-400, and of course hoped it’d be even sharper. The 80-400 has always had good sharpness at 400 in my experience, so there wasn’t a lot of room for it to be surpassed. Still, that the 100-400 is much softer (at all but the very closest subject distances) is very disappointing.

The only thing the 100-400 has going for it (so far) is with very close subjects – there, the 100-400 is vastly superior, in large part because it can simply focus much closer while simultaneously retaining more of its nominal 400mm focal length. If you expect your subjects to always be less than ~10ft away, the 100-400 is clearly the better lens.

The 150-600 results surprised me, and may be tending unrepresentative, as they don’t match my real-world experience. I do think the 150-600 is a good lens – and excellent value at a quarter the price of either of the other two – but I’ve found it just doesn’t deliver results quite as good – nor as reliably – as the 80-400, except when you utilise its 50% extra reach. I strongly suspect this is mostly due to differences in image stabilisation – the 80-400 has the best image stabilisation of any lens I’ve ever used, while the 150-600’s image stabilisation is average at best.

Granted, this is only in the centre of the frame. Maybe the 100-400 has redeeming image qualities elsewhere in the frame? A subject for a subsequent post, perhaps.

Of course, it’d be nice to see how those two lenses actually compare – I suppose I could keep using the 80-400 and return the 100-400, if the older lens turns out to be better.

Unfortunately California has decided this “weather” thing it’s never had before is the new hotness, and it’s basically rained non-stop for weeks now. So I haven’t been able to use of the 100-400 for real yet. Luckily, I was able to conscript a wild Stitch to help me do some rudimentary tests, in the interim. That’ll be the subject of this and a couple of subsequent posts.

The most important thing I want to know about any new lens is how it performs in the centre across various apertures and subject distances. That way I know what it’s capable of in the best case (the centre) and which aperture(s) to favour. So that’s what this first post is about.

Equipment

• Nikkor Z 100-400 (e.g. from Amazon).
• Nikon Z 7 (e.g. from Amazon).
• Neewer 660-LED constant light panels (e.g. from Amazon).
• Induro AT-313 (discontinued).
• Movo GH800 gimbal tripod head (e.g. from Amazon).
• Stitch (from outer space, via Hawaii).

Methodology

I tested five different subject distances:

• MFD (minimum focus distance) at 100
• MFD at 400
• 6ft at 400
• 12ft at 400
• 30ft at 400

I didn’t measure the actual MFD – all distances above are only approximate anyway, give or take a few inches – but it was something in the vicinity of 3ft, like the specs say. MFD is a bit closer at 100 than 400.

400 is basically the focal length that counts – that’s where this lens will spend the vast majority of its time – thus the inclusion of only one subject distance for 100, nor any intermediary focal lengths.

Stitch was lit (as shown in the photo above) by two Neewer 660-LED panels, set to maximum brightness & running off mains power. Diffusers were not used.

I chose to focus on Stitch’s nose because it has a nice fine-detailed fabric texture, that looked better as a test subject than the low-contrast threading of e.g. his eyes. I also deliberately focused only about a third down on his nose – not in the very centre – so that the centre of the nose, being the closest part to the camera, would be slightly out of focus. That way I could visually confirm that the plane of focus was where I expected and not short of the subject (in the cases where depth of field was so narrow as to matter).

I focused wide open using AF-C single-point (centred). I used a five second delayed shutter release, with pure electronic shutter (“Silent” mode). I did have to touch the camera between exposures, in order to adjust the aperture and press the shutter button, and this is why in some cases images are misaligned by a few pixels.

I used a fixed ISO of 64 in aperture-priority mode, letting the camera maintain constant exposure by varying the shutter speed (which ranged from 1/25 – 1/100). I did not normalise exposure in post – any variation you see in the images could be due to:

• Differences in metering based on differing fields of view.
• Error / inaccuracy in exposure by the camera.

Image stabilisation was disabled.

All the images you see embedded in this post are JPEGs with the quality set to 100%, as rendered from the raws by Lightroom Classic.

The crops are all from the exact centre, and are 1024 square.

All images were recorded as 14-bit lossless NEFs, and imported into Lightroom Classic with no modifications other than:

• Reducing the exposure by 0.75 stops. I exposed-to-the-right to maximise image quality.
• Setting the white balance to 4,500 with no tint. I left the camera on auto white-balance; I could have specified it as some fixed value in-camera, but I knew I could standardise it in post.

This also means that any built-in lens corrections, whether by the camera or Lightroom Classic, were performed. I left all those at factory settings, and I see no purpose in mucking with them since I – like most people – don’t muck with them in real-world use.

Lightroom Classic nominally applied some sharpening & noise reduction, per its defaults, but the settings were the same for all images (40/1.0/25/0 sharpening, 0/-/-/25/50/50 noise reduction).

Finally, I’ve provided the images for every aperture in a carousel, but also an A | B comparison of wide open vs what I feel is the most interesting juxtaposition (usually the sharpest aperture, though not always).

30ft @ 400

Prev 1of4 Next

Almost no change across the apertures. This is either an excellent result or a terrible result, depending on whether it means it’s sharp from wide open or never gets sharp. That’s best judged by comparing it to other lenses – a task for a subsequent post.

There’s a very slight softening starting at f/7.1 (vs f/6.3 or wider), that’s slightly more pronounced – but still very minor – at f/8. This is most likely diffraction softening and as such is expected. On the 46 MP Z7 diffraction becomes the limiting factor in acuity beyond about f/6.3 (in theory).

12ft @ 400

Prev 1of4 Next

It’s very slightly softer wide open, at f/5.6, than at f/6.3 or narrower. It’s less clear if diffraction has kicked in (as the limiting factor) by f/8 – to my eyes there’s very little difference between f/6.3, f/7.1, and f/8.

6ft @ 400

Prev 1of4 Next

Perceived sharpness increases significantly from f/5.6 to f/6.3, and then only very slightly more up to f/8.

However, I don’t see any change in actual resolution – it’s entirely just about contrast. Careful post-processing re. micro-contrast might significantly reduce if not eliminate the difference in perceived sharpness.

MFD @ 400

Prev 1of4 Next

Perceived sharpness improves significantly, steadily, all the way up to f/8 (which is as far as I tested).

As at 6ft, I don’t see any change in actual resolution – it’s entirely just about contrast.

MFD @ 100

Prev 1of6 Next

Perceived sharpness increases significantly between f/4.5 (wide open) and about f/6.3. After that there’s no meaningful change.

Interestingly, unlike at 400 some portion of the perceived sharpness difference appears to be due to actual resolution differences, not just contrast. So this is the only case in any of the tests I’ve done here where stopping down might be strictly necessary for maximum possible sharpness.

Conclusion

I can’t really compare across focal lengths, because the subject changed size (in the frame). It seems to me that the achievable acuity is pretty good, and pretty similar, at all focal lengths.

There was a clear trend w.r.t. subject distance and wide-open performance, i.e. as the distance gets shorter, wide open becomes softer in comparison to narrower apertures. Thus the optimal aperture is (in my opinion):

• MFD:
  • 100: f/6.3 (-1 stop)
  • 400: f/7.1 (-⅔ stop)
• 6ft: f/6.3 (-⅓ stop)
• 12ft: f/5.6 (wide open)
• 30ft: f/5.6 (wide open)

In some cases you do technically get slight improvements in perceived sharpness by stopping down further, but if you have to do so by raising ISO then it is definitely not worth it – the additional noise will outweigh the benefits.

Keep in mind, also, that at 400mm even when there was a difference in perceived sharpness, it was basically only due to changes in contrast. As such, in theory it can be fully compensated for in post-processing with e.g. micro-contrast adjustments. So I definitely wouldn’t stress if I forgot to stop down when my subject came super close.

It’d be great if wide open wasn’t slightly softer-looking at close distances, but as just noted the difference is largely correctable in post. More importantly, at most distances wide open is basically as sharp as any narrower aperture.

In a nutshell, this is an excellent result overall. At most subject distances, at 400, the only reason to stop down is if you actually want increased depth of field.

That all said, the real test is how the 100-400 compares against some of its competitors…

Sorry, we are unable to accept reviews for this product. This product has limitations on submitting reviews. There can be a number of reasons for this, including unusual reviewing activity.

Hmmm… curious.  I tried revising my star rating from 2 to 5 to see if it were so blatantly influenced by that, but it did not make a difference.

Anyway, FWIW here’s my review:

First up, the Blink XT cameras do not work with normal batteries – you have to buy quite expensive Lithium batteries.  Use of any other types of AAs will result in the camera not triggering reliably, failing to record full videos (or at all), etc.  So factor in about $20 extra per camera for a pair of such batteries.  Also, the two year quoted battery life appears to be a joke – I had to replace the first set of batteries after only a month or so.

Second, the video quality is not great.  They’re ostensibly 1080p but it looks both upscaled (probably from 720p) and it appears the video is recorded on the sync dongle, not the camera itself, so it’s subject to any radio interference issues that might exist, which will result in noticeably degraded video quality – or recording corrupting or cutting out entirely.  Overall the video quality, even in the best case, is like that of a very cheap smartphone (as of 2018), or say a 2010 iPhone.

Third, the only way to remotely control the cameras, and view recorded videos, is via mobile apps.  No desktop apps, no website, nothing.  So it’s very tedious to view the recordings, manage them, etc.

Fourth, the mobile app for iOS is not great.  It’s very slow – Cloud-saved videos are never loaded in advance, only on demand, and can take up to a minute to start playing.  It’s also a bit buggy.  e.g. a lot of the time it’ll fail to do whatever you asked, responding instead with a long delay ended with an error message along the lines of “the camera is busy”.

Fifth, wireless range is limited – I have one camera only about ten metres from both my wireless router & the sync module, through one exterior wall, and the video quality is noticeably degraded sometimes.  I tried placing one camera with line of sight about 30 metres away, and it worked (barely) for an hour or two and then never again, until I moved it much closer.

Sixth, motion triggering is inconsistent and lacks important configuration options (like zoning to denote areas to ignore or conversely to focus on).  e.g. for one video looking out the front of my place, it unavoidably has the street in view, which means that even on minimal sensitivity, we get a video & notification every single time a car goes by on the street.  Yet it still won’t reliably trigger when a human walks up to the front door, until they’re right in front of the camera.  Yet it’s nonetheless sometimes triggered by squirrels up to 10 metres away.

So, solidly not recommended.  Not the worst thing ever – the system does function in a very minimal sense, and I’ve managed to get some utility out of it, but it’s definitely disappointing – and many of these errors could surely be easily fixed by better software, firmware, or hardware design (e.g. support for normal batteries).

The goal in this case is just to test how well each raw editor – Aperture 3.6, Capture One 9 Pro, DxO Optics 10, and Lightroom CC 2015.3 – can lift an underexposed photo.  For pedants, note that I’m specifically applying an overall exposure adjustment, not just shadow recovery, though I expect that fundamentally any ‘Shadow’ sliders in these editors are just a strict subset of their ‘Exposure’ sliders.

First, here’s the test image as it first appears when viewed in each of the contenders:

Some differences in how each raw converter operates by default, unsurprisingly. But clearly the photo is massively underexposed. In case you’re wondering, this was just setting up for a macro shoot, and for whatever reason the flashes didn’t fire in this exposure.

And below is the edited version. My goal here was to bring the photo up to a broadly ‘normal’ or ‘correct’ exposure. At first I assumed this would just mean some ‘Exposure’ adjustment applied identically between the four contenders, but it quickly became apparent that their adjustment tools just aren’t equivalent like that.

For reference, the adjustments made for each were:

• Aperture 3.6 – +6 exposure
• Capture One 9 Pro – +4 exposure, +35 brightness
• DxO Optics 10 – +3 exposure
• Lightroom CC 2015.3 – +5 exposure

The additional use of the ‘Brightness’ slider in Capture One was necessary because its ‘Exposure’ slider is hard-limited to ±4, obnoxiously.

Clearly one of these things is not like the other. Or, put another way:

Here’s a zoomed in view of a representative part of the image:

So, Aperture… enough said.

Amongst the other three, there’s lots of room for opinion. DxO Optics has applied much more noise reduction, to the point where it’s quite obvious and (in my opinion) a bit over-done. Capture One and Lightroom have done a similar job, though I think Capture One has done genuinely better at suppressing the banding, and the noise in certain areas – particularly the midtones.

Now, this section of the image is out of focus. A necessary question – given it appears the main difference is simply in the noise reduction being applied – is how well genuine detail is retained. So here’s a second 100% clipping from the image:

DxO Optics happens to have retained the highlights a bit better, which is fine but remember that I didn’t bother recovering highlights at all, which I’m sure all of them would be able to do just fine (since ‘recovery’ in this sense means merely not so massively lifting them out of shadow).

There’s not much else to say here, though. Aperture is incredibly horrible. And the other three behave much the same as we’ve seen before:

• DxO Optics has gone for very strong noise reduction by default, which has actually rendered the small in-focus area not too badly. But really softened everything else, in a slightly blotchy “I’ve been noise reduced” way.
• Capture One has a more subtle look, that’s actually a little crisper than DxO Optics’, but has significantly more noise and banding visible.
• Lightroom goes even further, with a very noisy and very banded rendition that can perhaps give an illusion of extra detail, though there actually isn’t anything there that Capture One & DxO Optics don’t also reveal.

Again, it looks like the difference is primarily in noise reduction. I’m not going to try to ‘equalize’ their noise reduction settings – from experience that’s highly subjective – but I suspect you could ultimately get similar results, to suit your own taste, from any of Capture One, DxO Optics, or Lightroom.

But you’ll never get anything usable out of Aperture, from this kind of scenario. That one’s dead, Jim.

An update on Aperture

“noirdesir” on DPReview’s forums (and Jim M here in the comments) identified Aperture’s problem: that it’s got a fixed blackpoint which is preventing it from actually bring up any real shadow detail.

Unfortunately I wasn’t expecting to add to this post, so I didn’t save a few key tidbits like the crop coordinates for the two 100% views. But FWIW here’s broadly what you can get out of Aperture if you also adjust the ‘Black Point’ alongside ‘Exposure’:

Aperture’s rendition still isn’t as good as any of the other three – it’s much noisier, even than Lightroom’s, and the deepest shadows are still somewhat clipped. The latter may be an imperfect ‘Black point’ setting, though I did spend quite some time playing with it and this was the best that I could seem to get from it, w.r.t. both overall image quality and actually getting roughly the desired exposure.

So after all these years and many images given-up on, it turns out Aperture can actually recover underexposed images to a reasonable degree. It’s just far more fiddly than any of the other raw editors – you have to adjust the ‘Exposure’ slider a little, then the ‘Black point’, and then repeat numerous times to narrow in on the right complementary settings. But even then, the point remains that it still doesn’t do as good a job of it as Capture One, DxO Optics, or Lightroom.

For better or worse, Aperture is dying.  Abandoned by Apple many years ago now, it’s frankly amazing it hasn’t completely broken already, given the steady stream of system updates and such changes since then.  Regardless, it has always had rough edges, and on top of all that I’ve grown increasingly disappointed with its image quality – both fundamental raw rendering as well as with editing.  So, I need an alternative.

Staggeringly, there’s still nothing else out there quite like Aperture.  Lightroom is probably the closest, but it has a lot of design flaws – particularly in its UI – and, from what I hear, perpetual & unpredictable performance issues (not that Aperture is great there either).  But it is undoubtably the de facto standard, and has vastly more community – providing tutorials, presets, plug-ins, etc – which is also valuable.

There’s DxO Optics.  I’ve played with it before and know that it can do an amazingly better job than Aperture (w.r.t. image quality).  It’s a relatively bare-bones program, however, with minimal editing capabilities and not even the pretense of actual image management.

There’s also Capture One, which while undoubtedly the most expensive option out there today, also has a reputation for being the best w.r.t. image quality.  It’s also been around longer than any of these other options.  It has a reasonable set of editing capabilities.  It sort of tries to do image management, though it’s clear it’s not trying very hard, and it has some pretty serious UI issues and bugs in this area.

I spent quite some time playing with each of these three alternatives, trying to develop a broad feel for their respective strengths and weaknesses.  What I found is that they all require compromises compared to what I’m used to from Aperture, and it’s really a Sophie’s choice of which things I’ll miss least.  That’s not a fun choice to have to make.

So I had to ask myself what really matters.  I find myself thinking that I should choose first and foremost based on image quality, on the basis that I spend a ridiculous amount of money on all the other gear necessary to take a quality photographs to begin with, and inordinate amounts of my own time in managing and editing photos – the end result of which is ultimately judged almost solely by the quality of the images that I publish online & print.  And for ancillary features like Flickr export and whatnot, there are other workflow options, even if it’s a few more steps to utilise them.

Thus, this comparison.

I’m presenting this in something of a reverse order, on the assumption that most readers will just want to cut to the chase and see what my findings & advice are.  But I do want to also detail my methodology, so that others can understand and reproduce it – so that’s included at the end.

Note:  yes, there’s also Apple’s Photos, which is just iPhoto’s younger, hipster sibling.  It’s essentially DxO Optics’ inverse – a decent image management app with very rudimentary image editing capabilities.  And it shares Aperture’s raw rendering engine, which I already feel to be decidedly mediocre.  While there are hypothetical options involving things like the DxO Optics plug-in for Photos, along with a small army of not-entirely-existent-yet plug-ins for actual image editing, I’m defaulting that to the very last resort.  Plus it’ll probably be abandoned within a couple of years anyway – as is Apple’s inevitable wont.

Though for the purposes of this comparison – of just the raw rendering engines – I expect Aperture’s results to be equivalent to Photos’.

Conclusion

TL;DR:  Capture One wins by a safe margin, no matter how you look at it.

Specifically, here’s the overall ranking per photo:

That’s seven 1st-place results for Capture One, vs three for DxO Optics, one for Lightroom, and zero for Aperture.

Or, looked at another way, the rankings by average position:

1. Capture One (1.4)
2. DxO Optics (2.3)
3. Aperture & Lightroom (2.6)

In short:

1. Capture One almost always rendered the most fine detail, while simultaneously almost always rendering the least noise.  Its renditions were often lacking contrast, however, and – with a couple of notable exceptions – its colour rendition was relatively muted.
2. DxO Optics was often similarly sharp to Capture One – and sometimes moreso – though it achieved its results less elegantly, with an often ‘over-processed’ look and blotchy noise reduction.  It was the only raw converter which corrected geometric distortion, which may have penalised it w.r.t. sharpness, which I gave more weight to.
3. Aperture & Lightroom often rendered very similar results, which had (typically) significantly less fine detail than the other two renderers, and often produced relatively accurate but aesthetically disinteresting colours and contrast.
   1. Lightroom favours significantly greater sharpening by default, than Aperture, and this also manifests as dramatically more noise in some cases.
   2. Lightroom also tended to err on the side of over-exposure, whereas Aperture was a bit more accurate generally, but occasionally under-exposed.

A few things surprised me in these results, though one above all others:  that Lightroom doesn’t actually do a particularly good job of rendering raws.  This is really unexpected to me because Lightroom / Adobe Camera Raw is by far the most common raw renderer out there, and has plenty of praise spoken about it.  As the closest approximation to Aperture as an actual image manager and editor, I was secretly hoping it would perform well so that I could choose it, other aversions be damned.  Alas, no such luck.

I was also surprised at the performance of DxO Optics – I own an older copy, version 8, and have used it from time to time.  I’ve found it particularly useful – compared to Aperture – for high ISO images, where it does a much better job, at times, in minimising noise and bringing out shadow detail.  But that might be the explanation – the test performed here judged only the initial raw rendering, not key edits like dramatic exposure adjustments (including highlight & shadow recovery).  I strongly suspect DxO Optics would distinguish itself much more from Aperture in editing tests.

I will also add that Capture One’s results, when heavily scrutinised, sometimes felt contrary to my previous anecdotal experience with it.  When toggling between Aperture and Capture One I’d previously seen a huge image quality improvement all round.  Make no mistake – there is a big difference shown in this test.  But my prior dabbles with it had, at the time, seemed more dramatic still.  Its possible the few images I’d compared previously were especially favourable to Capture One.  Or that, once you actually apply some meaningful edits, that Capture One’s advantage over Aperture only increases.  I suspect that is in fact the case, much as I suspect the same for DxO Optics, but again image editing was not tested here.

Results

How to interpret these results

The methodology section, at the end, fully details how these images were processed in each of the contenders, and prepared for web presentation.  Suffice then, for now, to say that:

• I chose ten images that are deliberately not perfect but reflect a reasonable cross-section of my whole photo collection.  I did make some effort to include specific technical scenarios (e.g. high ISO), that not much – my primary focus was on a representative set of images, not a technically diverse one.
• My fundamental test is of how well each of the contending programs presents the raws straight out of the camera.  Nothing more.  Don’t complain.  Maybe I’ll test other aspects later, and you’re certainly welcome to yourself – add a comment at the end with a link to your tests.  But keep in mind the very specific scope here.
• For each of the sample images, I’m using two views:
  • A full view of the photo, to gauge general colour rendition, exposure, etc.
  • A 100% crop clipping from a key part of the image, to really investigate acuity, contrast, and noise.

Keep in mind that if your browser window is narrow (e.g. you’re on a mobile device) you may be seeing a low-resolution view – for best results, ensure your browser window is wide enough to see the images at full size.

The actual results

The Lake

This first image is a random, flat landscape shot.  It was a slightly foggy day when this was taken, with overcast skies and little wind.  Cold, also – not much above freezing.

Prev 1of4 Next

Aperture & Lightroom both render this one truer to how I actually remember the scene being – i.e. genuinely flat & dull.  It’s surprising how similar they are to each other, though Lightroom’s rendition is the dullest.

Capture One has gone with a naturally vibrant look, which I find quite pleasing, even if it is technically inaccurate.  It’s also clearly more detailed [than Aperture or Lightroom’s] even at this reduced viewing size.

DxO Optics is the outlier here, with a surprising, somewhat grungy look.  Far contrastier than the other three, and appearing to my eye perhaps a little over-sharpened.  That said, colour-wise it’s actually not that inaccurate.

Prev 1of4 Next

This 100% view just confirms what was already somewhat visible when zoomed out – that Capture One & DxO Optics are rendering much more detail.  I find Capture One’s rendition more natural and pleasing, but I could see some people favouring DxO Optics’.

In any case, though, they both do a much better job than Aperture or Lightroom.

What really surprises me here is how uncompetitive Lightroom is.  Its rendition has barely any more detail than Aperture’s, which I find very surprising given how popular Lightroom (and Adobe Camera Raw) are.  Nonetheless, it still is that tiny bit sharper than Aperture’s.

Judgement

I firmly prefer the Capture One version – it just looks better to me, plain and simple.  Capture One really brings out a lot of genuine detail, without any artifacting that I can see, and without looking over-processed (to my eye).

I respect Aperture & Lightroom for their ‘honest’ rendition of the scene, but would undoubtedly – were I to fully post-process this image in them –  try to make them look more like Capture One’s version.  And their lack of detail is very disappointing.

Note:  the obvious question is whether you can dig out that same detail, that Capture One has by default, from Aperture or Lightroom.  That’s difficult to answer conclusively, since there are many possible approaches with many possible fine-tuning settings.

I have extensive experience with Aperture (many years and thousands of images processed), and I am confident that I cannot get as good an image out of it, as Capture One or DxO Optics are giving by default.  It simply doesn’t have the detail there in its original raw rendering.

I do not have much experience with Lightroom.  I did do some quick experimentation with it, and was able to get fairly close to Capture One’s acuity, but not without introducing visible sharpening artefacts, never with quite the same really fine detail, and not without a lot of time & effort.  It was nonetheless a bit more capable than Aperture in this respect, though.

And DxO Optics… overall I’m inclined to rank it below the other three, but that’s mainly on the basis that its exaggerated contrast, sharpening, and structure just don’t suite this scene.  But I do feel that, if I were going to put some time into editing, then DxO Optics offers a much better starting position than Aperture or Lightroom – because, again, it has much more genuine detail available to start with.

The Ceiling

This one is intended to represent a common low-light scenario – a high ISO, plus a bit of motion blur due to hand-holding at slow shutter speeds (1/10s in this case, without VR).

Prev 1of4 Next

I actually like Aperture’s colour rendition in this case.  It’s getting close to over-exaggerated, particularly with the reds, but otherwise its solid saturation is pleasing to me.  Lightroom’s rendition is similar to me, though ever so slightly sharper and with higher local contrast.

Capture One’s rendition disappoints me this time around.  The muted colours and lower contrast do it no favours, producing an appearance of lesser detail than Aperture or Lightroom, even though objectively it renders slightly higher detail.

DxO Optics has given the whole image a bit of a red cast, for some reason, and the red walls around the sides are tending towards radioactive.  However, it’s also the only one of the four which actually corrected for the lens’ geometric distortion.  The effect is basically foiled in this case, though, by the circular and symmetrical subject.  And is perhaps contributing to its lack of sharpness – surprisingly, given the results from the previous photo, DxO Optics’ rendition has the least detail this time around.

Prev 1of4 Next

The standout here is Lightroom.  For good and for bad.  It has appeared to render more detail than the others (with Aperture a not distant second), but this is quite possibly something of an optical illusion performed by it’s dramatically higher noise levels.  If you look closely, you’ll be hard pressed to find anywhere with genuinely greater fine detail, compared to Capture One’s or even Aperture’s rendition.  Just a lot of crude over-sharpening.

DxO Optics, on the other hand, has gone entirely the other direction – rendering slightly less noise than the other three, but also significantly less detail.  Possibly its geometric distortion correction has contributed negatively here.  Its rendition is very ‘painterly’ to my eyes, which I do not like at all.

Capture One has rendered more detail than Aperture, and some is genuinely new detail, though otherwise it looks mostly like a simple difference in sharpening defaults.

Judgement

This one surprised me.  While objectively Capture One renders detail the best, at the smaller view size I find I actually prefer Lightroom and Aperture’s renditions.  While I’m leery of the significant noise in Lightroom’s rendition, I personally like to err on the side of detail – and could always choose to carefully noise reduce, which looking at these images I suspect I could do better than the other three are doing with their default settings, and thus maintaining a margin of extra detail.

That said, Capture One’s only real negative is its flatter, less colourful initial rendition, which might be as simple to ‘fix’ as a quick contrast & saturation adjustment.

DxO Optics is the loser in this round, though, due to its clear lack of fine detail.  It’s possible it’d be helped by turning off its geometric distortion correction, but I did not test that.

The Peacock

This one has a lot of fine feather detail, but also a lot of slightly out-of-focus feather detail, so it’s an interesting test of how detail vs bokeh are balanced.

Prev 1of4 Next

I see relatively little difference between the four.  The Aperture one has slightly richer colours – especially compared to Lightroom’s, the most flat – and I particularly like Aperture’s rendering of the Peacock’s neck & body.  In general Aperture has really deepened the blues.

DxO Optics has rendered slightly higher contrast, or at least brighter highlights – see in particular the top of the Peacock’s head.  It’s also again corrected for geometric distortion.  But its also produced the softest appearance at this small viewing size.

Aperture, Capture One, and Lightroom have all rendered almost identical levels of detail when compared objectively.  Though to my eye for some reason Capture One’s rendition seems slightly softer.

Prev 1of4 Next

Aperture’s is the outlier here – noticeably softer than the other three.  DxO Optics’ is sharper, but a little processed looking.  Furthermore, in some patches Lightroom brings out more detail – e.g. the feathers on the head – while in others – e.g. the beak – DxO Optics does a better job.

But they’re all beaten by Capture One, which produces a consistently sharp rendition (albeit with what may appear to be over-processed to some people).

Aperture has also, perplexingly, introduced what look like sharpening artefacts into the background feathers – see in particular the hair-thin (no pun intended) outline of the blue ‘eyes’ on the feathers.  I slightly dislike Aperture’s rendering of the background here.

Judgement

It’s pretty close overall, but I give this one to Capture One.  If I were pushed a bit, I’d rank Aperture’s rendition barely last – despite its pleasing blues – with Lightroom only slightly above, and DxO Optics in second place.

The Cat

I photograph a lot of animals.  Good rendering of hair and fur is critical.

Prev 1of4 Next

DxO Optics has gone for a noticeably ‘stronger’, contrastier rendition.  It looks ‘processed’ (in the negative sense of the word) side-by-side with the others, but I suspect if viewed on its own it wouldn’t.

I find Capture One’s rendition a tad flat, and consequently seemingly a bit soft (even though objectively it’s not).  I’m starting to see a trend here, whereby Capture One could benefit from a tad more contrast by default.

I slightly prefer Aperture’s rendition to Lightroom’s.  Though overall they’re very similar, and I think most of the difference comes down just to colour temperature – Lightroom’s being a truer neutral white-balance, while Aperture’s is warmer.  Lightroom has also applied more contrast than Aperture, too.

Prev 1of4 Next

Capture One’s rendition stands out to me as the best, by some margin.  Capture One has done a noticeably better job of rendering the fine fur, in a detailed but still very natural way.  Its rendition has genuinely more fine detail than any of the others produced.

In contrast, literally and figuratively, DxO Optics has again gone for a more ‘processed’ look.  Despite its obviously stronger sharpening, it’s actually rendered slightly less detail than Capture One.

Curiously, though, Lightroom seems to have done a better job rendering the eye.  There’s significantly more fine detail in there, particularly within the iris under the reflections.  Capture One and especially DxO Optics have lost detail there.  But it comes at the expense of visible noise, which is not present in the others’ renditions.

I’m surprised how well Aperture stands up for itself in this particular case.  I’ve long been frustrated with Aperture’s poor rendering of hair & fur, but in this specific example it doesn’t do a terrible job.  While not the best, it’s done just as good a job as Lightroom at bringing out genuine detail, and done so with less noise.

Judgement

Though I do like DxO Optics rendition when viewed small, at the pixel level it hasn’t done nearly as good a job as Capture One, and Capture One is a quick contrast adjustment away from the same nicely balanced look.  In fact DxO Optics is probably in last in this one, due to its over-sharpened look with no more actual detail than Aperture or Lightroom.

Aperture & Lightroom are very close, with the difference really just being in the level of basic sharpening applied.  Neither stands up to Capture One, though, which is the clear winner.

The Deer

The wildlife shooter’s bugbear – a cute subject too far away, in too little light, with way to much stuff going on around it, visually.  This one’s got high ISOs, camera motion blur, and relies especially on fine detail because it’s invariably going to be cropped a lot.  The rendering of the busy, only slightly out-of-focus background is also critical.

Prev 1of4 Next

Frankly, with such a noisy scene – both image noise and subject noise – there’s very little in it between all four contenders.  I have a very slight preference for Capture One’s colour rendition – it’s pulled down the highlights in particular, to produce slightly richer, more pleasing greens.  Aperture is not not far behind.  DxO Optics & Lightroom have gone for relatively dull colours – DxO Optics especially.

Prev 1of4 Next

Worth noting is that none of the four can save this particular image.

I think overall Capture One has done the best job of balancing detail with noise.  While I do like the level of detail Lightroom has rendered, it’s done so – as with The Ceiling – at the expense of much more noise than the others.  That said, Capture One has done a particularly poor job of rendering the fur on the deer’s neck, such that even Aperture bests it there.

Lightroom has also rendered the background and surrounds noticeably busier – Capture One is my favourite of the four, in this aspect, followed by Aperture, and then DxO Optics.

Judgement

Capture One clearly wins, but by a small margin, and it’s a hollow victory because it’s still not good enough to compensate for the mediocre source raw.  The other three are close enough to be called tied, and sensitive to personal preference (particularly w.r.t. Lightroom’s much noisier rendition).

The Harrier

A pretty typical bird-in-flight shot – which I ostensibly try to eschew as both cliché and difficult to capture, but which is nonetheless represented in its fair share of my library.  There’s something in the challenge of capturing a wild animal in its fast motion.

Prev 1of4 Next

As with the previous image, the actual subject is so small in the frame that the differences there are insignificant.

Something about Lightroom’s rendition of the out of focus background is more pleasing to me than any of the others’, though it’s a very small difference.

And Capture One has rendered the greens noticeably richer, in a not unpleasant but still subjective way.  It does make the Harrier pop much more off the background, which is a big plus in this kind of photography.

Prev 1of4 Next

Capture One does the best job to my eye, though the differences are minor.  Perhaps its biggest differentiator is the relatively low noise – the background is noticeably less noisy and thus more pleasing.  Though that’s also something that’s relatively easy to selectively noise reduce, in a shot like this.

Objectively, however, Lightroom has brought out the most genuine detail.  The Harrier’s breast, for example, has actual feather detail in Lightroom’s rendition, detail which is simply gone – visibly smeared out, as if by overly-aggressive noise reduction – in Capture One’s rendition.  Aperture & DxO Optics actually both also do a better job of preserving that detail, though at the expense of higher noise levels than Capture One.

I do like how DxO Optics has emphasised the detail in the harrier’s head, with its slightly stronger sharpening, though it looks like a fairly straight-forward trade-off with noise, and in fact on the feathers more generally I see more detail from Capture One.

Aperture’s rendition is the worst, with both relatively high noise and relatively little feather detail – with the notable exception of around the face, where it bests Capture One.  Lightroom is not much better, with more detail but also the most noise.  However, Lightroom renders the noise as very even, very fine-grained.  Aperture’s also high noise is a little blobier.  For less than 100% viewing, Lightroom’s noise will likely average out better than Aperture’s.

Judgement

It’s a toss-up between Capture One and Lightroom – low noise vs more detail, respectively.  DxO Optics comes in third, with its slightly more aggressive processing that is nonetheless still reasonable and pleasing in this case.  Aperture comes in close last, mainly just on the basis that it has relatively ugly noise (and plenty of it) compared to the level of detail it brings out.

The Gopher

A very typical close-up wildlife shot.  Depth of field is an issue, backgrounds are noisy, and ISO is creeping up into the midranges.

Prev 1of4 Next

Capture One has rendered this was unusually flat, in stark opposition to DxO Optics which has gone for a highly-processed, vibrant look.  Though a bit strong, I do like the general direction of DxO Optics’ rendering w.r.t. contrast & clarity – look at the teeth, for example, to see how much more attention they draw in DxO Optics’ rendition.  It’s not realistic, but it does have an aesthetic I could get into (with some refining editing).

Capture One’s rendition is noticeably flatter, which can lead you to think it has less detail overall, though objectively this isn’t true.

Lightroom and Aperture are similar – colours are realistic if a bit dull by conventional standards; acuity appears reasonable.  Aperture has under-exposed slightly, to my eye.

Prev 1of4 Next

Capture One has done the best overall job, to my eye, w.r.t. fine details.  It’s rendered significantly more fine detail in the gopher’s fur, to the extent that it’s made the depth of field effectively quite a bit larger.  But its sharpening has started to over-emphasise the speckled highlights in the fur, which renders that part of the fur less attractive than Lightroom or Aperture’s renditions.

DxO Optics has actually done a pretty respectable job in this case.  It hasn’t actually rendered any more genuine detail than Capture One, and as we’ve seen here previously, its results tend to look more artificial and ‘over-sharpened’, but its more aggressive and stylised lighting adjustments have done well here – bringing out good mid-level detail; achieving a better overall exposure than any of the other contenders; and really drawing attention to the eye.

Lightroom’s rendition is rather flat, in obvious contrast to DxO Optics’, well, contrast.  In most other respects, it’s very similar to Aperture’s – the main difference being that Lightroom has more sharpening applied, for more apparent (but not genuine) detail and correspondingly more noise.  In any case, Aperture & Lightroom’s renditions are obviously lacking in fine detail compared to the other two’s.  Lightroom’s is also a tad over-exposed.

In regards to noise, there’s not a dramatic difference between the four of them, though the pattern seen so far repeats – Lightroom renders the most noise, DxO Optics the least – though with coarser, less attractive noise for what is left in there.  Capture One does a rather good job of keeping noise fine-grained and minimal – without compromising detail – while Aperture does a notably poorer job of it, comparing favourably only to Lightroom.

Judgement

It’s a toss-up between Capture One and DxO Optics.  I suspect that, with quick & minor edits, you could turn either into a nice mid-ground, with DxO Optics’ more pleasing lighting (possibly just a quick jolt of the ‘Clarity’ slider) and Capture One’s more natural fine detail & noise.  The difference is certainly within the bounds of reasonable personal preference.

There’s not much in it between Lightroom and Aperture, but Lightroom’s slightly higher noise and slightly washed-out appearance punt it into last place.

The Granite

This is representing all the lazy holiday snaps.  This particular one is just a single shot towards a large panorama, so ignore the disinteresting subject and awkward framing.  It’s also a bit over-exposed, which is not atypical in mid-day-sun landscape photography (nor, especially, in panoramas where the dynamic range can be especially high).

Prev 1of4 Next

It’s quite subjective in this case, but I am drawn to DxO Optics’ version first and foremost, despite its lower vibrance.  Overall exposure is also a bit low, but it’s brought out the most detail in the over-exposed clouds, rendered the sky a pleasingly deeper blue, and the trees and granite mountains with more contrast.  The underexposure & reduced vibrance (saturation & luminosity in the greens) shows up particularly in the grass in the midground, but that’s trivial to address with a quick edit.

Aperture has rendered the white clouds closer to actual white, which I prefer over the slightly duller renditions by Capture One & Lightroom.  In fact it’s produced an overall higher contrast rendition than Capture One & Lightroom, which I find more pleasing overall.  That higher contrast has also given the appearance of greater detail.

There’s not much going for Capture One nor Lightroom in this case.  In fact Lightroom’s rendition seems noticeably softer than any of the others’ (possibly just due to the lower contrast).

Prev 1of4 Next

Now we can see that there’s actually a pretty dramatic difference in fine detail between the four.  While Aperture’s rendition looked surprisingly good relative to the others’, it looks like that was really just a result of its higher contrast – when it comes to true fine detail, it has none.  It looks positively out of focus compare to Capture One & DxO Optics’ versions.  And the same goes for Lightroom, which yields very similar results to Aperture.

DxO Optics has done a rather good job in this case of bringing out detail without looking over-processed, as it has tended to in the other pictures.  It beats even Capture One this time around, though the difference between those two is small compared to the big loss of detail going down to Aperture or Lightroom.

Judgement

I think DxO Optics wins this one.  Not by much – as noted, Capture One’s rendition is similar and either could likely be turned into the other with quick & simple edits.

Aperture & Lightroom are clear losers here.  They render dramatically less detail.  Aperture at least redeems itself somewhat with a more pleasing overall look – that, when viewed relatively small, has good contrast and good apparent detail.  Shoving Lightroom to clear last.

The Sunrise

This is a relatively specialised scenario – a pseudo ‘night’ scene but at base ISO – but I felt it worth including because, frankly, I’m frequently disappointed with sunset photos – both mine and those I see online.  But particularly mine, which I’ve always suspected is Aperture’s fault…

Prev 1of4 Next

And I think I might be onto something there.  The first thing I notice is the big halo around the sun that only Aperture sees.  Ugly.

DxO Optics has brought the shadows up noticeably – it shows that I was shooting this down the length of a valley, for example, with trees & rocks on the side.  Consequently there’s a bit less contrast in its rendition, and the sun’s glow seems to bleed over the silhouette more than in the others, though I wouldn’t characterise this is objectively good or bad – and to my taste, I’m indifferent.

Lightroom has also tried to bring up the shadows a bit, though not so strongly.

But truly the key aspect of this type of photo is colour.  And that’s also the most subjective.  I can’t even decide which of the four I prefer in this respect.  It’s certainly true that DxO Optics’ is the warmest rendition, and Capture One’s the coolest.  If I were forced to choose I’d probably favour Aperture or Lightroom’s colour.

Prev 1of4 Next

Looking closer just emphasises Aperture’s terrible work.  And it’s noisy.  In an ISO 100 photo.

In fact noise is visible in all four photos, despite this being at base ISO.  Disappointing.  Presumably this is actual sensor noise from the camera – no camera is perfect in this respect, even at base ISO – though given the nature of this photo, noise reduction could be applied very aggressively without detriment.

There’s also banding visible in all four photos.  Aperture’s rendition appears to have the least offensive banding, surprisingly, though it’s quite possible it’s just most obscured by the higher noise.  DxO Optics has done the best job in the sky, though perhaps not as good as Capture One in the silhouette, where DxO Optics’ characteristic blotchy noise rendering stands out more.

DxO Optics has done the best with the high contrast edge of the sun, though.  Aperture’s rendition of this is awful, as previously noted, and even Capture One & Lightroom struggle a bit with it, adding an extra halo around the edge.  Of those two, Lightroom’s is least offensive at it’s at least pretty smoothly graduated, while Capture One’s has some slight banding.

Judgement

This is perhaps why I dislike sunrise & sunset photos so much – nobody can render them well, to my eye. It’s difficult to pick a favourite from these four… but, I do find myself dislike DxO Optics’ version the least.

The Valley

A slightly higher quality landscape photo, than the touristy happy-snap style represented previously.  This one’s exposed correctly, has a decent subject and framing, and is at base ISO with a high shutter speed, so detail should be good, but possibly hampered by the great subject distance.

Prev 1of4 Next

Not a big difference between the four.  DxO Optics’ rendition stands out the most, as being brighter overall – mainly due to it lifting the shadows most.  It’s also done a good job with overall contrast – producing properly white clouds without losing any detail, and presenting pleasing global contrast despite the lifted shadows.  It also has notably more detail than the others’.

Capture One’s rendition has stronger colours, though you’d be forgiven for not noticing immediately.  If you compare it closely with Aperture’s, though, it makes Aperture’s rendition look a bit gloomy.

DxO Optics has also corrected for geometric distortion in the lens, though again the effect is subtle and might be missed, and doesn’t really affect the photo’s aesthetics.

Lightroom’s rendition is the flattest, and least pleasing to my eye.  Though Aperture’s slightly under-exposed rendition is a bit dark and unattractive too.

Prev 1of4 Next

DxO Optics has brought out the most fine detail, though in doing so it’s produced an over-processed appearance.  Capture One does a better job of bringing out detail which, while not quite as crisp, is much more natural looking.  In any case, the difference between them appears to be just the strength of their sharpening – actual level of detail is the same.

DxO Optics’ rendition of the slightly out-of-focus foreground rocks is quite good, however.  The extra contrast it’s applied has benefited it significantly, in addition to the stronger sharpening working well in this case.

Aperture & Lightroom, as per usual, bring out significantly less detail, though in this particular case Lightroom has done a better job than Aperture.  In the face of the Capture One & DxO Optics versions, though, you might not notice the difference.

Judgement

Capture One wins this round.  It has nice colour, and relatively pleasingly-rendered fine detail.

DxO Optics comes in a not-distant second with nicely lifted shadows and good detail, albeit at the expense of appearing over-sharpened when you look too close.

Aperture and Lightroom share last place.  Aperture has a nicer rendition w.r.t. contrast if not colour too, but Lightroom has brought out slightly more detail.

Methodology

The basic process was:

1. For each contender:
   1. Import the original ten NEFs into it.
   2. Tell it to export the ‘processed’ versions by whatever process each app has (e.g. in Aperture it’s “Export Versions…”, in Capture One it’s “Process”, etc).  Export as an 8-bit TIFF in AdobeRGB (1998) colour space.
2. Run a simple batch process in Photoshop or GraphicConverter to open each TIFF, scale it to 1024 on its longest side, and then save as an 8-bit TIFF again.
3. For each image, identify an appropriate 1024×1024 crop and use GraphicConverter’s batch processing capabilities to open each of the original TIFFs, crop to that area, and then save again as a TIFF.
4. Run another batch process in GraphicConverter to combine each set of four 1024×1024 TIFFs (both sets – the scaled down and the cropped versions) into a single TIFF, for the 2 x 2 or “four-up” views.
5. Batch convert all those TIFFs into JPEG2000 format (lossless) for web display.
   
   Note: many years later, in 2023, I replaced the images on this page with WebP versions (also lossless). This increased their size slightly (WebP isn’t as efficient as JPEG2000) but meant that virtually all modern browsers can show the images, rather than basically just Safari.
6. Run a full calibration using a ColorMunki Display (with default settings).
7. Compare all those JPEG2000s or TIFFs on a 27″ 2011 iMac.

And that’s it.  Pretty simple, but time consuming for the various stages of conversion.

I started doing the batch processing with Photoshop, but it was glacially slow and difficult to use, so I switched to GraphicConverter midway through.  File sizes and metadata might differ, but there should be no difference in the actual visual results as both have proper colour profile support (with no conversions being performed) and the image formats in question are all lossless.

Why look at only a 1024 x 1024 section for 100% viewing?

Because I didn’t want to have to scrutinise each photo so intently – as it was I spent hours comparing the final results, in order to make my notes & judgements.

Why AdobeRGB (1998)?

It’s the colour space I work in and export my images in.  Even amongst those that export in sRGB or similar, more limited colour spaces, most are working in AdobeRGB during editing (whether they realise it or not).

I briefly considered other options, like ProPhoto RGB, but aside from the fact that I use AdobeRGB today, with no plans to change, AdobeRGB (1998) appears to be the highest common standard amongst these four contenders.  And I strongly wished to avoid using an external converter, as that introduces room for favouritism (colour space conversion is surprisingly complicated, and conversions from different origin spaces to the same destination might introduce unintended differences).  It’s also unrealistic, as I expect the vast majority of people don’t perform an external colour conversion or adjustment step.

Why not use DxO Optics’ “PRIME” noise reduction?

Three reasons:

1. It’s not enabled by default, and is virtually impossible to adjust using only the tiny little preview window they give you.
2. It takes a really long time to render the output images.  This compounds the only workaround available to problem #1, above, which is to actually export the image over and over again in order to narrow in on decent settings.
3. Frankly, in the brief tests I’ve run, it doesn’t actually perform better than the default noise reduction algorithm in DxO Optics.  In fact, for one of my images it did noticeably worse – removing no more noise but killing significant detail.

Why not turn off DxO Optics’ geometric distortion correction?

Because it’s on by default.  The same question could be asked of any and all the other options each contender offers.  Granted the distortion correction seemed to have a relatively pronounced effect on DxO Optics’ output, but that’s what it feels is the best trade-off, clearly, and some people may find it a valuable feature, so I don’t want to discount it.

Why an old iMac?

Because Apple haven’t released a newer model compelling enough for me to upgrade.

I would have preferred to perform the test on a ‘Retina’ display, but I had to work with what I have.  I do intend to revisit the images on some other devices – including mobile devices like an iPad – to see if there’s a meaningful difference in appearance.

Why lossless compression?

The files are quite big, despite being compressed with WebP, the most efficient lossless format broadly available across browsers in 2023. They could be made much smaller with lossy compression, but then you wouldn’t know how much of what you’re seeing is the actual raw converter’s doing and how much is compression artefacts.

Why WebP?

I also tested JPEG2000, AVIF, PNG, and TIFF – and originally offered versions in all of these except AVIF, for browser compatibility purposes.

JPEG2000 compresses best – slightly but consistently better than the next best, WebP – but is basically only supported in Safari.

AVIF surprisingly performs universally worse than WebP and JPEG2000 for lossless compression (it tends to do better for lossy compression).

PNG was a pretty distant 4th place, followed by an even more distant TIFF in last. This is expected – PNG is pretty good for low detail images, especially artificial things like screenshots or simple digital drawings, but quite bad for everything else. TIFF is barely compressed at all (arguably part of its nature as a format which prioritises ease & speed of local use on computers that are presumed to have fast storage and lots of RAM).

I switched to WebP and deleted all the others, in 2023, in order to save space – all those lossless-quality files in the varied formats were taking up gigabytes of space on my web server!

This is not unique to the Sigma 105, by any means.  Nikon’s own 70-300, for example, has the exact same obstruction and also will not mount to any Nikon teleconverter (or at least, not any of the current models, of the 1.4x, 1.7x or 2x).

This is very disappointing, and an odd decision by Sigma – it was they, after all, who deliberately included the obstruction on the rear mount.  The teleconverters would mount just fine otherwise – there is just enough clearance to the rear element.

In contrast, Nikon’s competing 105 macro doesn’t have the obstruction on the mount, apparently, as it’s listed by Nikon as officially supporting use with Nikon teleconverters.  [I have not personally verified this]

I have heard, though haven’t verified first-hand, that the Sigma teleconverters do not have the same protrusion, and so will happily mount to any lens on which they fit (i.e. where their front element doesn’t collide with the rear element of the lens).

My point of comparison is primarily the Nikon AF-S 80-400 VR.  That’s my go-to lens for most things, and certainly the things you’d use a 600 for.

In a nutshell, not nearly worth what it costs, even second hand and decades old.  I was surprised.  I assume the more modern models, particularly the current VR one, are massively better.

At a quick glance (I haven’t gone through all my test photos yet) the new Tamron 150-600 F/5-6.3 Di VC USD appears about as sharp wide open as does this Nikon 600/4.  At equivalent apertures (e.g. both at f/6.3, or f/7.1) it’s a little harder to judge… in part because the Tamron has:

• VC (VR in Nikon parlance).
• Much more reliable and accurate autofocus.
• Way less mass, and that makes it easier to get the shot to begin with.  You can fairly easily hand-hold the Tamron, for example, while with the Nikon 600/4 it’s unreasonable to do so for more than ten seconds at a time.  Even on a monopod the 600/4 is unwieldy, and I missed a lot of shots just struggling to get it into position and held steady.

Which altogether mean that you get many times more keeper photos with the Tamron than the Nikon, even if maybe the Nikon is maybe very slightly sharper at f/6.3.  If you’re shooting wildlife, as I am, you’ll take a reliable, sharp-but-not-pixel-perfect-sharp option over a slightly sharper but unreliable one, any day.

• SanDisk Extreme Pro 95 MB/s 32 GiB
• SanDisk Extreme Plus 80 MB/s 32 GiB
• SanDisk Extreme 45 MB/s 16 GiB
• Lexar Professional 600x 128 GiB

I chose not to test as many cards as last time, when I tested the D7100.  Partly because I hope that anyone spending the money on a Nikon Df is using a good quality card to go with it, and partly because the initial results made it fairly clear that performance correlates between the cameras pretty well.  Also, the Df was generously on loan to me so I had to be selective about how I used my time with it.

Test setup

Same test setup & method as before, in the Nikon D7100 test.  The only difference is that picture area was set to FX, not DX.

At ISO 100 the average file size was right on 19.8 MiB.  That rose to 25.6 MiB at ISO 800, and then to 27.4 MiB at ISO 6,400.

The results

ISO 100

Points of interest

• Look at that big sexy buffer!  My D7100 is having severe performance anxiety after seeing this.
• More seriously, note how consistent the shots are when initially buffer-bound.  Much more consistent than the D7100.  There’s no reason for the D7100 to drop frames and stutter when there’s buffer space available – and the Nikon Df proves it.
• The SanDisk Extreme Pro 95 MB/s 32 GiB takes the crown for average speed, by a noticeable margin – it gets 31 shots at full speed and then ~2.3 FPS after filling the buffer, vs the ~29 to ~1.9 FPS of its younger sibling the SanDisk Extreme Plus 80 MB/s 32 GiB and the Lexar Professional 600x 128 GiB.
• Props to the SanDisk Extreme 45 MB/s 16 GiB for consistently pulling ~27 + ~1.7 FPS.  When you consider its reliability in contrast to the Lexar’s unreliability, and the fairly small margin between the two in performance, it’s surprisingly competitive.
• Note the inconsistency of the Lexar Professional 600x 128 GiB.  I double-checked my data on this to be absolutely certain, and it’s no mistake – it really does have these very noticeable glitches.  (I also noticed these, audibly, when recording the shots – it’s quite obvious when it suddenly stops taking photos for a good second or so)

ISO 800

Points of interest

• More inconsistency from the Lexar Professional 600x 128 GiB. :S
• Overall things slow down a bit, and pretty consistently across all the cards, by a little over 10%.  The Lexar Professional 600x 128 GiB appears to slow down relatively little, at just under 10%, but I suspect that’s because it simply didn’t happen to stutter as much in the ISO 800 runs.
• The Lexar Professional 600x 128 GiB just edges out of the SanDisk Extreme Plus 80 MB/s 32 GiB for average shot rate, at ~27 to ~1.5 vs ~27 to ~1.4.  But only sometimes, due to its problematic stutter.

ISO 6,400

Points of interest

• Generally similar to ISO 800 – unsurprising given the mere ~7% increase in file size.  The Lexar Professional 600x 128 GiB continues its stuttering, while the SanDisk Extreme Pro 95 MB/s 32 GiB continues to confidently dominate.
• About the only interesting change is that the Lexar Professional 600x 128 GiB no longer provides an increase in effective buffer capacity over the SanDisk Extreme Plus 80 MB/s 32 GiB and SanDisk Extreme 45 MB/s 16 GiB.  Though it does still provide a higher shooting rate after the buffer fills.

Compared to the D7100

Here I’ve re-scaled the Nikon Df‘s results to the first 10 seconds of shooting, to match the D7100’s.  It also gives a better impression of just how much bigger the Df’s buffer is.

Points of interest

• There’s a much bigger difference on the Nikon D7100 between the SanDisk Extreme 45 MB/s 16 GiB and the other three cards, than on the Nikon Df.  This suggests that either the Df is better at utilising slower cards, or – and I think this is in fact the case – simply less demanding and less able to utilise faster cards.
  
  With the SanDisk Extreme Pro 95 MB/s 32 GiB the Df’s write rate is right about 46 MB/s, whereas the D7100’s is ~56 MB/s.  It appears that the Df is limited to ~46 MB/s.  I posit that the Df supports only UHS-I SDR50 or DDR50 – either way providing a theoretical bandwidth of 50 MB/s – whereas the D7100 supports UHS-I SDR104 – providing a theoretical bandwidth of 104 MB/s.
  
  I believe the reason the Nikon D7100 doesn’t achieve 104 MB/s is because it’s actually limited by the card – a faster SD card should yield ~3 FPS, in theory (vs the ~1.9 FPS it achieves with the SanDisk Extreme Pro 95 MB/s 32 GiB).  I guess now I’ll have to find such a beast…  in theory something like the Transcend R95 MB/s W85 MB/s 64 GiB fits the profile.  I might have to acquire one for testing…
• The D7100 is “losing” in FPS only because its files are bigger.  If you shoot in 1.3x crop mode you get ~15.4 MP, comparable to the Nikon Df‘s 16 MP, and thus presumably similar file sizes.  I expect you’d then get noticeably higher frame rates from the D7100 than the Df.  I may now go test the D7100 doing exactly that…

Conclusion

Unlike the Nikon D7100, this is viably a four-horse race.  Because the Nikon Df seems limited by a slower SD card interface, you don’t see nearly as much benefit from the fastest cards.  This makes it an interesting value proposition – the Extreme Pro 95 MB/s’s typically retail for about twice the price (per GiB) of the Extreme 45 MB/s’s, yet on the Df give you only one extra shot every two seconds (or four extra shots “in the buffer” before slowing down).  i.e. a ~20% performance increase for a ~100% price increase.

Likewise the Lexar Professional 600x 128 GiB seems slightly hampered.  It can’t quite get ahead of the SanDisk Extreme Plus 80 MB/s 32 GiB like it does on the D7100, so it loses that counter-balance to its unreliability.  It does still have a non-trivial price difference in its favour, however.

Consequently, my ranking of the four cards is slightly different to that for the D7100.  The SanDisk Extreme Pro 95 MB/s 32 GiB unsurprisingly takes first place, again, but this time its little brother the SanDisk Extreme Plus 80 MB/s 32 GiB comes in a respectable second – the Lexar Professional 600x 128 GiB concedes the position and falls back to third place.  Leaving, as before, the SanDisk Extreme 45 MB/s 16 GiB in fourth place.  But feeling like a bit more of a viable contender than it did in the D7100.

It does beg the question, however:  how slow can you go?  Would the SanDisk Ultra now actually be attractive?  I regret not testing it in the Df, in hindsight, because it’d probably put in a relatively good showing.  But I’m confident in saying it’s still a noticeably slower card, and I see no reason why its horrible lack of reliability would be in any way improved in the Df, so I continue to recommend against the SanDisk Ultras, and any like “no-name-brand” or so-called “budget” SD cards.

My final rank, based primarily on performance and reliability:

• A+ SanDisk Extreme Pro 95 MB/s 32 GiB
• A    SanDisk Extreme Plus 80 MB/s 32 GiB
• A    Lexar Professional 600x 128 GiB
• B    SanDisk Extreme 45 MB/s 16 GiB

See also

• My earlier evaluation of these exact same cards (plus others) in the D7100.
• Reviews of the same cards by The Wirecutter, with differing results in some cases (likely because they used a Canon T4i – performance does vary by camera, clearly).
• Chuck Steenburgh’s exhaustive review of no less than 37 (!!) SD cards, in a D7100, but using a different methodology.
• An extremely comprehensive albeit slightly dated database of cameras (Nikon & Canon) and SD, CF & XQD cards, by Rob Galbraith.

• SanDisk Extreme Pro 95 MB/s 32 GiB
• SanDisk Extreme Plus 80 MB/s 32 GiB
• SanDisk Extreme 45 MB/s 16 GiB
• SanDisk Ultra 30 MB/s 16 GiB
• Lexar Professional 600x 128 GiB
• Maxell MaxData 16 GiB
• SanDisk Ultra MicroSD 64 GiB
• Samsung MicroSD 32 GiB

Note that the last two are MicroSD cards, not regular SD cards.  I threw them in because I had them and because they’re out there and surprisingly much cheaper per GiB than regular SD cards, so if they perform as well…

Be mindful of the capacity differences.  Flash-memory-based devices usually – but not always – improve in performance as their capacity increases.  This can be complicated if a like-branded range of cards vary their NAND flash process significantly (e.g. moving to TLC at higher capacities, from MLC).  Ultimately it’s possible that the Lexar Professional 600x 128 GiB, for example, gets a bit of an “unfair” advantage by simple virtue of its size.  Alas, I can only test what cards I actually have (though if you buy any of them from Amazon by following the links in this post, I’ll receive a small commission which I can use to acquire further cards for testing).  And in any case, “fair” is subjective given the vastly differing prices for these cards – one might argue it’s only “fair” to compare them at the same price point, with an intrinsic advantage to those that provide more capacity at that price.

Test setup

Nikon D7100 with the Nikon 50/1.8G, on a tripod, pointing at my computer screen.  On that was played (full-screen) a time counter (a trivial app I wrote in all of ten minutes).  The counter displays nothing other than a flat grey background and the counter itself in big black letters.  Consistency is crucial between shots to ensure the camera is doing the same type and amount of processing, and that the file sizes are as consistent as possible.

Camera settings were:

• Continuous High shooting mode.
• 14-bit lossless-compressed RAW.
• DX area (i.e. not 1.3x crop).
• Auto white balance.
• Matrix metering.
• Manual focus (switched both on the lens and the camera body).
• Standard (SD) picture control.
• AdobeRGB colour space.
• Active-D Lighting was off.
• Long Exposure Noise Reduction was off.
• High ISO Noise Reduction was set to Normal.
• Exposure Delay Mode was off.
• For the ISO 100 shots, f/1.8 @ 1/500.
• For the ISO 800 shots, f/3.5 @ 1/500.
• For the ISO 6,400 shots, f/10 @ 1/500.
• Only one card in the camera at a time – the card under test – and in slot one.
• Image review off.

Note that these aren’t all the default camera settings.  They’re what I typically use, more or less.  The 1/500 shutter speed was simply the fastest I could reasonably do, exposure-wise, at ISO 100 – the faster the better to freeze the clock on screen.

I have not tested JPEG capture.  It is faster and thus more tedious to test as it takes longer just to exhaust the camera’s buffer and get down to actually measuring the SD card’s performance.  And I never shoot JPEG myself.

Method

1. Insert empty card under test.
2. Set ISO 100, f/1.8, 1/500 (Manual mode, Auto-ISO off).
3. Start timer.
4. Hold down shutter button for about eleven seconds.
5. Wait for SD activity LED on the back of the camera to turn off.  Wait another five seconds for good measure.
6. Repeat steps 3 through 5 twice more.
7. Set ISO 800, f/3.5, 1/500.
8. Repeat steps 3 through 6.
9. Set ISO 6,400, f/10, 1/500.
10. Repeat steps 3 through 6.
11. Insert card into computer and read each image in sequence, entering the value of the timer captured by each shot into a spreadsheet, which aligns them so that the first shot always corresponds to t = 0.

Note in particular that I didn’t erase the SD card at any point during the test itself – only at the beginning.  I have reason to believe that may be a source of a little error – during testing I saw evidence that some cards are very sensitive to their utilisation, w.r.t. performance.  But as you’ll see from the results below, there was no consistent tendency for the second or third runs to slow down.  I will be exploring performance vs utilisation at a later date, however.

At ISO 100 the average file size was just a little under 30 MiB.  At ISO 800 it rose to around 37 MiB.  At ISO 6,400 it was just over 40 MiB.  Thus whatever difference in in-camera processing there may be is also conflated with the differing data rates.

The results

ISO 100

Points of interest

• You would expect consistent behaviour for the first five or six shots, because those should all fit into the camera’s RAM buffer.  But as you can see there’s quite clearly substantial variation there – and in some cases, like the SanDisk Ultra 30 MB/s 16 GiB, completely dropped shots.  I don’t have an explanation for this – I’m reporting what I saw.  My tentative hypothesis is that the camera starts flushing the buffer quite quickly, but in a way such that some kind of delay or ‘hiccup’ on the SD card’s part can prevent it taken further shots, despite room remaining in the RAM buffer.
• The SanDisk Ultra 30 MB/s 16 GiB shows a very strange behaviour – it not only causes the camera to drop shots during what should be the safe, predictable buffer period, but in one case you can see it actually somehow caused the camera to take one shot faster than it’s supposed to be able to – just ~100ms after the first.  This seems inexplicable, so of course I checked the results for typos or other obvious errors.  My only hypothesis is that a random glitch hit my computer and caused the on-screen timer to freeze temporarily – just for a fraction of a second – giving the impression less time had passed than had really.  I never noticed any glitches while watching the timer, which I did for every single test run from start to finish, and I ensured my computer was otherwise completely idle during testing to avoid just such issues.  So I don’t think, if this is even the root cause at all, that it’s a systematic issue (especially given that several of the cards measured as very consistent, implying an accurate and consistent timer).  Nonetheless I am thinking about what else I could use as a timer instead, that wouldn’t suffer from such potential issues.
• Unsurprisingly [to me] the MicroSD cards performed distinctly worse than full-size SD cards.  But what is interesting is that the Samsung MicroSD 32 GiB outperformed the full-size Maxell MaxData 16 GiB, slightly.  The SanDisk Ultra MicroSD 64 GiB, on the other hand, comes in as not just the slowest of the lot but unpredictable to boot.
• The SanDisk Extreme Pro 95 MB/s 32 GiB takes the crown for average speed, but only barely – its younger sibling the SanDisk Extreme Plus 80 MB/s 32 GiB is close behind, but surprisingly (given its significantly lower cost per GiB) it’s the Lexar Professional 600x 128 GiB that only barely misses first place.  However, note how the Lexar misses a shot completely in one of the test runs.
• But the SanDisk Extreme Pro 95 MB/s 32 GiB‘s speed comes at a stark cost – its shot intervals are very unreliable.  Only the SanDisk Ultra MicroSD 64 GiB does worse in this regard.

ISO 800

Points of interest

• Now we start to see that RAM buffer stretched just a tiny bit too far – that sixth shot is now tending to come in just a little bit late.
• Overall things slow down a bit, and pretty consistently across all the cards, by about 25%.  This isn’t surprising given that the file size has increased by about 25-30%.  However, the SanDisk Extreme Pro 95 MB/s 32 GiB notably bucks this trend, slowing down by only 10%.
• The SanDisk Ultra MicroSD 64 GiB now yields much more regular performance, but the SanDisk Extreme Pro 95 MB/s 32 GiB retains its consistent inconsistency.

ISO 6,400

Points of interest

• In some ways not a huge difference from ISO 800, which isn’t surprising given the file size has only increased slightly.  But there’s a lot more inconsistency now – witness the Maxell MaxData 16 GiB, Lexar Professional 600x 128 GiB & SanDisk Ultra 30 MB/s 16 GiB all dropping shots entirely (including again in the ostensibly buffer-only period, in the case of the SanDisk Ultra 30 MB/s 16 GiB).  This was particularly surprising for the Lexar given its reliable performance prior, which is why I did an additional three runs to try to reproduce the glitches.  As you can see, I couldn’t, but clearly there’s some unreliability there.  In real-world use I have seen the Lexar Professional 600x 128 GiB drop shots like this, though it is very rare.
• The SanDisk Extreme Plus 80 MB/s 32 GiB is now just that little bit faster than the Lexar Professional 600x 128 GiB.
• The SanDisk Extreme Pro 95 MB/s 32 GiB maintains its significant and impressive performance delta, over all the other cards, as it established it at ISO 800.

Conclusion

It’s really just a three-horse race, between the SanDisk Extreme Pro 95 MB/s 32 GiB, the SanDisk Extreme Plus 80 MB/s 32 GiB, and the Lexar Professional 600x 128 GiB.  But there is a clear winner, and that’s the SanDisk Extreme Pro 95 MB/s 32 GiB.  It has noticeably better average continuous shooting speeds – especially as ISOs / file sizes increase – albeit with significant and consistently inconsistent shot-to-shot latency, which may annoy some people.  I reason, however, that when you’re holding the shutter down like this you’re really spraying-and-praying, one way or another, so you’re not prescribing precise shot times to begin with.  And I can’t say whether the tested behaviour of holding down the shutter button is representative of pressing the shutter repeatedly in rapid succession – it’s quite possible the behaviour is very different.

Second place I give it to the Lexar Professional 600x 128 GiB, but only just.  It performs a little bit faster overall, but less consistently, than the SanDisk Extreme Plus 80 MB/s 32 GiB.  What gives it the edge, however, is its vastly superior value – at time of writing it’s a full 50% cheaper at the 128 GiB capacity point (and cheaper albeit less dramatically at lower capacities).

Which leaves the SanDisk Extreme Plus 80 MB/s 32 GiB in third.  But if you’re looking for strict reliability, and/or are less sensitive to price, then you could choose it over the Lexar.

After that, there’s a pretty significant drop in performance to the middle of the pack – the SanDisk Extreme 45 MB/s 16 GiB and the SanDisk Ultra 30 MB/s 16 GiB.  Between those the SanDisk Extreme 45 MB/s 16 GiB is by far better.  The SanDisk Ultra 30 MB/s 16 GiB is an unreliable card.  Not just as shown in this tests; I’ve used several over the last few years, but increasingly briefly as I’ve learnt that they’re not just slow but prone to freezing for long periods, corrupting data, and generally sucking.  I strongly recommend you never use them.

That said, you can do worse:  the Maxell MaxData 16 GiB and both the MicroSD cards – both the SanDisk Ultra MicroSD 64 GiB and the Samsung MicroSD 32 GiB – turn in comically bad performance.  They were frustrating to test because each individual burst of shots took longer to flush to the SD card than the entire three-run set on the faster cards.  Don’t ever use them.

My final rank, based primarily on performance and reliability:

• A+ SanDisk Extreme Pro 95 MB/s 32 GiB
• A    Lexar Professional 600x 128 GiB
• A    SanDisk Extreme Plus 80 MB/s 32 GiB
• B    SanDisk Extreme 45 MB/s 16 GiB
• D-  SanDisk Ultra 30 MB/s 16 GiB
• F    Maxell MaxData 16 GiB
• F    SanDisk Ultra MicroSD 64 GiB
• F    Samsung MicroSD 32 GiB

See also:

• My review of some of these exact same cards in a Nikon Df (in particular to see the contrast in performance between two ostensibly same-generation cameras).
• Reviews of many of the same cards by The Wirecutter, with differing results in some cases (quite possibly because they used a Canon T4i – performance does vary by camera).
• Chuck Steenburgh’s exhaustive review of no less than 37 (!!) SD cards, also in a D7100, but using a different methodology.  His results broadly agree with mine but are less detailed.
• An extremely comprehensive albeit slightly dated database of cameras (Nikon & Canon) and SD, CF & XQD cards, by Rob Galbraith.

As you can see, on my particular D5200 it has an overall tendency to back-focus (negative adjustment values mean “the subject was closer than AF thought”).

It took a good two or three hours to arrive at these settings, using a variety of home-made focus targets.  Calibrating for infinity is particularly difficult, both because it’s difficult to find a suitable target that is that big, and because the depth of field is very high at great distances.  On the upside, the latter at least means that small calibration errors don’t really matter.

It’s also annoying how huge the jump is from 0.5 metres to infinity, which is basically your entire practical working range, and it does feel like the necessary adjustments for true infinity are substantially different to those for two metres.

I also discovered that there is substantial shot to shot variation in AF accuracy.  This could be the same problem that was seen in reviews of the Canon version of this lens, or for all I know it could just be normal variation for this kind of lens (i.e. large aperture).  I do have a Nikon 50/1.8G but I’ve never tested it in the same way (because I’ve never really had any issues in practice).

In fact, I didn’t actually intend to run this calibration to begin with it all.  It’s only because I discovered that there was a strong back-focus in general, while just playing with it, that I realised I’d have to do something about it.  That -8 makes the difference, in a typical two metre portrait distance, between someone’s eyes being in focus and the back of their head (and 35mm @ f1.8 means that’s a big difference).

Relative to that, the random shot-to-shot focus variation is about four units.  So even fully adjusted, a good third or more of the shots have the ears in focus instead of the eyes.

In all my past experiments with focusing I’ve found that phase detection (i.e. viewfinder use) is actually more accurate more consistently than contrast detection (live view).  My first impression with this new lens is that that cannot possibly be true, when using this lens.  I guess we’ll see.

This test, of the coolest names built-in dictation.) Nope, not important.

If you’re..Reasonably built night, That was true Samaritan and settle.

Go ahead, try to figure out what I actually said.

Hopefully you can see, even in this tiny preview, that at least one of these things is not like the others.  I’ll give you a hint: two of these were taken with a circular polarising filter.  Two different filters – a cheap ProMaster one and an expensive B+W Käsemann one.  Hopefully, then, you can figure out which two were using the circular polarising filters and which filter is which.  Here, I’ll help you out with a couple of 100% crops:

As you can see, the circular polarisers do indeed reduce the glare and improve large-scale contrast, but the ProMaster one absolutely ruins the image, while even the very expensive B+W Käsemann causes noticeable loss of acuity.

Part of the reason may be the differing ISOs – 280 vs 1100.  You can see a bit of graininess in both polarised shots.  That’s only part of it, though, and not a big part – two shots consistently with [or without] the filter at these two ISOs show quite little difference for a busy scene like this.

Another, and bigger, part of the reason the cheap one did so poorly is because the camera mis-focused when using it.  Consistently.  The camera seemed to focus as normal – just as fast, and it was just as certain it was in focus.  But it wasn’t – not by quite a long shot.  If you rotated the filter to its least effective position, focused, then rotated it back and took the shot, the results were a little better.  Focus is about right then, but image quality is still poor.  The B+W Käsemann causes systematic focus error sometimes too, requiring the same sort of shenanigans to work around.

I’m not sure why this was particularly a problem right there and then.  Shooting Half Dome instead, a mere forty degrees away, showed no such issues with autofocus (though loss of acuity was still present to some degree, with both filters).

So apparently you need to be very cautious about using circular polarising filters.  Cheap ones are crap.  Really crap.  A waste of money.  Expensive ones are useful, but shouldn’t be used unless genuinely necessary – keeping in mind that the above “unfiltered” shot can be made 80% equivalent to the better filtered one by simply bumping contrast, saturation and a few other things in post.  While I’m hard-pressed to see a significant difference in acuity when looking at the full photo scaled down (the first example), between no-filter and expensive-filter, you don’t have to crop it very far or view it very large to start seeing non-trivial differences.

A few notes on my method:

• I took three to five shots for each case, and picked the best ones in each set for this comparison.
• All used the same aperture (f/5.6) at the same focal length (400m) at the same shutter speed (1/640).
• Taken on a Nikon D5200 in Sport mode.
• All were hand-held albeit with VR on, and some were slightly motion-blurred, but these three best cases look fine to me in that regard.
• Aperture was used for RAW conversion.
• Full-size JPEGs are available here, here and here.  Original NEFs at request.
• When I say “no filter” I technically mean “UV filter”, as this is the one lens I own where I think it’s worth protecting the front element.  I haven’t done an objective evaluation of the optical effects of the UV filter, but it’s an expensive B+W one and I’ve never had reason to doubt its performance.  Note that the shots with the circular polarising filters are with one or other of those instead of the UV filter, not stacked atop.

Both cards are 32 GB models.

The SanDisk Extreme Pro allows for 21 shots in 10.0s, and takes another 13.8s to finish recording those.

The Lexar Professional 600x takes 11.4s for the same 21 shots, and another 14.0s to finish recording those.

I didn’t experience any stuttering in shots when using the SanDisk Extreme Pro, but did encounter one instance of stuttering – a fairly minor one – with the Lexar.  I have not previously seen either of these cards stutter, neither in tests like this nor in real-world use, so I think it’s a rare anomaly.

In both cases you can get only four shots at the advertised continuous shooting speed, at which point it slows down to a steady pace – the SanDisk maintaining a ~10% faster pace than the Lexar; ~1.8 vs ~1.6 FPS.

The difference between the two cards is much less significant than between either of them and e.g. the SanDisk Ultra line.  The SanDisk Extreme Pro seems to have a slight advantage, and is roughly the same cost as the Lexar, so I’ll give it first place, but in reality I’d be – indeed have been – happy using either of these cards, and haven’t noticed a practical difference.

Note: these aren’t the same settings I previously used to compare the Lexar Professional 600x to the SanDisk Ultra, nor the same camera body or lens.

Update: using Blackmagic Disk Speed Test the SanDisk scores 63.6 / 86.3 MB/s, for write and read respectively.  The Lexar gets 41.0 / 84.6 MB/s.  Using a 15″ 2012 Retina MacBook Pro.  That’s about the difference I expected based on their specs and advertising.  That you don’t get a 50% faster continuous shooting speed in a real camera doesn’t surprise me – I doubt the camera can always meet the bandwidth capacity of a high-end card, nor that there aren’t other bottlenecks waiting right behind SD write speed anyway.

• AF-S DX VR Zoom-Nikkor 18-55mm f/3.5-5.6G (not to be confused with the newer VR II version)
• AF-S DX VR Zoom-Nikkor 18-105mm f/3.5-5.6G ED

Conclusions

Which to get?

Neither lens is clearly better than the other, technically.  They have similar features and each exceeds the other in at least some areas.  But the 18-55 is slightly smaller, significantly lighter, and much more consistent in its performance.  Consequently I rate it as better value, given it’s significantly cheaper.

But, if you actually want the extra telephoto range (and the slight, undocumented wide-angle improvement) the 18-105 is a decent replacement (though in the 55-105 range you can get better quality from something like the Nikon 55-300, if you’re willing to swap lenses).  On the other hand, if you spend most of your time at the wide end of these lenses, the 18-55 is undoubtedly better.

That said, I’m only intending to keep one, and I haven’t decided which it’ll be yet.  I expected the 18-105 to be an unequivocal replacement for the 18-55, and as such I’m a bit disappointed.

Sharpness

Both lenses are pretty decent in theoretical sharpness, as tested here.  Not pixel-perfect, but high enough that a 100% crop is pretty decent.  The reality is that the differences between them are very small compared with the difference between perfectly steady “studio” shots versus real-world, hand-held use.

The difference in centre sharpness is small at all focal lengths, but the 18-55 does win almost all the time.  The differences at the edges, however, can be dramatic – with the 18-105 doing particularly poorly at shorter focal lengths.

Both lenses have surprisingly dramatic variations in sharpness across the frame in a somewhat random manner – e.g. some corners are better than others at one focal length, but their relationship can be completely different at another.  There can be significant sharpness variation back and forth multiple times across the frame, with no obvious bias like left-side-always-sharper or similar, nor any apparent relationship to actual distance from the lens.  I’m a little bit flustered by this.  I don’t know how reproducible it is or have any idea what the cause is.

Interestingly, despite it generally being a wash between the two, the 18-105 does achieve significantly higher peak, localised sharpness.  The problem is it’s not in the centre, and it’s not even a predictable spot, so I don’t know that it’s of any real use.

In terms of focal length, both are sharpest at 24mm.  45mm and 55mm are softest.

Autofocus

Neither lens displayed a bias for my particular camera (focus calibration wasn’t a deliberate aspect of my testing, but I didn’t see any evidence of consistent front or back focus with either lens, nor any favouring of one lens over the other).

Phase-detection autofocus is significantly more accurate than contrast-detection autofocus, most of the time (~70% in my limited sampling, and worse ~20% of the time).

Colour

The 18-105 had slightly better colour much of the time.  This means both stronger colours in certain hues, as well as colours that are overall closer to true life (at last according to my ColorMunki-calibrated iMac screen).

Note: I’ve found colour to be the most subjective and fungible aspect of a photo, so I don’t give this metric much weight in evaluating the lenses.  Both produce excellently-coloured images by any practical measure.

Contrast

The 18-105 had noticeably better contrast much of the time.  This was, curiously, somewhat independent of its relative sharpness.  In particular, the 18-105 did a particularly better job reproducing blacks accurately – the 18-55 never really gave a pure black anywhere in the frame (despite the smaller aperture at some focal lengths).

Chromatic aberration

The 18-55 has only slight aberration at short focal lengths, and none at all at mid-to-long ones.  It’s a very impressive lens in this regard.  The 18-105, on the other hand, has some quite significant aberration at shorter focal lengths, which only reduces to what I consider mild aberration by about 35mm.  The 18-105’s chromatic aberration is not just greater in terms of spatial shift, but also significantly more intense.

Geometric distortion

The 18-105 has more geometric distortion – especially barrel distortion at the wide end.  Both lenses have essentially no distortion at mid range, but the 18-105 picks up some slight pincushioning as it gets longer, while the 18-55 remains excellently neutral.

I did not measure the complexity of the distortion, so I can’t comment as to how easy it is to correct.  There was no waviness or non-linearity visible to the naked eye.  I use Aperture generally, so I can’t correct it anyway.  Grrr.

Aperture

The 18-105 has an on-paper ~0.3-stop advantage from 35mm on, which translates into a visible but minor improvement in illumination.  However, I also noticed that the 18-105 produces ever so slightly brighter images even at the same aperture  – on the order of about 5%, max.  The net result is that the 18-105 is ever so slightly brighter at the wide end, steadily increasing to a genuine ~0.3 stops brighter at 55mm.

Vignetting

I didn’t test for it.  Neither lens had obvious vignetting at any focal length, and if they did it’d be subjective as to whether it’s even bad to begin with, and easy enough to correct in any case.

Vibration Reduction

Not tested.  But, I did have it enabled on both lenses initially, until I realised that the 18-55 was not producing a consistent framing – it would shift significantly between viewfinder and live-view modes, and slightly between shots within the same mode, even though the camera was very firmly locked in place.  The 18-105 didn’t seem to have any such issues.  Since I, like I suspect most people, just tend to leave VR on all the time, this might be something worth considering.  The shift was significant enough that even if you’re not trying to take repeated, identically-framed shots, setting up the frame precisely for a single shot might be difficult.

Method

Note that this was done simply, quickly and not at all in a statistically reliable way (i.e. no multi-sampling, neither of lenses nor of shots).

1. Set camera (D5200) up on tripod with infrared-remote-triggered shutter, shutter delay after mirror up, and everything locked very firmly.
2. Manual mode, ISO 100, constant lighting via three CFLs.  Maximum aperture.  Focal length specified using markings on the lens barrel (or, for the extreme wide and tele ends, by rotating the zoom ring as far as possible).  Shutter speed set based on appropriate exposure at 18mm, and increased by one step for each increase in focal length (to vaguely represent necessarily higher shutter speeds, to see if the difference in maximum apertures ends up making a noticeable effect).
3. Attach first lens.
4. Focus [using phase detection in centre point] using shutter button half-press, take photo with remote.
5. Switch to live view mode, take photo with remote (which forces focusing first in centre point, using contrast detection).
6. Swap lenses.  Set new lens to same focal length.  Repeat steps 4 & 5.
7. Move to next focal length.  Move tripod so that roughly the same frame is made as at the prior focal length.
8. Goto step 4.

My test scene was a shelf of a bookcase, starting at about 50cm away at 18mm, and ending up about 2.5m away at 55mm.  The centre focus point was over the spines of two books, with sharp and contrasty writing on both.  Both books were at the same distance from the camera.  At some point I hope to compare the two with a test scene that’s at a much greater distance, to see how they perform for e.g. landscapes.

Note that I deliberately compared the lenses at wide open, which isn’t always the same aperture, because:

1. Most people shoot wide open most of the time.
2. The differences in this case were small anyway.

Detailed observations

18mm

The 18-105 in fact goes slightly wider.

They have the same maximum aperture (f/3.5).

The 18-105 has noticeably more barrel distortion – the 18-55’s is fairly subtle, whereas the 18-105’s is quite obvious.

The 18-55 is noticeably sharper for the most part, both in the centre but especially [relatively speaking] at the extremes of the frame.

The 18-105 has better contrast in places, and arguably better colour (mostly stronger).

Chromatic aberration is significantly stronger on the 18-105, both in terms of intensity and spatial shift.

24mm

They have the same maximum aperture (f/4).

The 18-55 still has very slight barrel distortion, but the 18-105 has essentially none.

Sharpness is about equal, but interestingly not consistent across the frame on either lens.  The 18-55 has a slight advantage in the very centre, but this could be luck given the wild variation across the frame.

The 18-105 generally has better contrast – but not in all places in the frame – and colour is about equivalent overall, with some parts of the frame doing better than others for one lens vs the other.

Chromatic aberration is the same as at 18mm for both lenses – i.e. the 18-55 is significantly better.

35mm

The 18-105 has a slightly larger maximum aperture (f/4.5 vs f/5 – a 0.3 stop advantage).

The 18-105 has very slight pincushion distortion, while the 18-55 has essentially no geometric distortion.

The 18-55 is sharper in the centre, but the 18-105 is slightly sharper overall.  The variation in sharpness across its frame is significantly greater than the 18-55’s.

The 18-105 has noticeably better contrast in many places.  It is as good or better throughout the frame.  It has slightly better colour.

Chromatic aberration is worse on the 18-105.  The 18-55 has no chromatic aberration anywhere in the frame.  Note however that the chromatic aberration that is present on the 18-105 is not nearly as bad as at shorter focal lengths, and is in absolute terms fairly mild.

45mm

The 18-105 has a slightly larger maximum aperture (f/4.8 vs f/5.3 – a 0.3 stop advantage).

The 18-105 has noticeable pincushion distortion, while the 18-55 has essentially no geometric distortion.

The 18-55 is slightly sharper in the centre, but the 18-105 is significantly sharper overall.

The 18-105 has better contrast in many places.  It is as good or better throughout the frame.  It has noticeably better colour.

Chromatic aberration is worse on the 18-105.  The 18-55 has no chromatic aberration anywhere in the frame.  Note however that the chromatic aberration that is present on the 18-105 is not nearly as bad as at shorter focal lengths (below 35mm), and is in absolute terms fairly mild.

55mm

The 18-105 has a slightly larger maximum aperture (f/5 vs f/5.6 – a 0.3 stop advantage).

The 18-105 has slight pincushion distortion, while the 18-55 has essentially no geometric distortion.

The 18-105 is noticeably sharper in general; very slightly sharper in the centre.  The 18-55 is more consistent across the frame.

The 18-105 has better contrast in many places.  It is as good or better throughout the frame.  It has noticeably better colour.

Chromatic aberration is worse on the 18-105.  The 18-55 has no chromatic aberration anywhere in the frame.  Note however that the chromatic aberration that is present on the 18-105 is not nearly as bad as at shorter focal lengths (below 35mm), and is in absolute terms fairly mild.

All the following use “JPEG Fine” except where otherwise stated.

At ISO 100, with noise reduction & distortion correction enabled, it manages just ten shots in ~2.8 seconds before slowing down.  It hits 21 shots total after another ~5.7 seconds (so 8.5s total), and completes writing all 21 shots to the Lexar Professional 600x 32 GB after another ~14.5 seconds.  So that’s ~23 seconds in total for 21 shots.  This is slightly better than shooting RAW, where you get nine shots before it slows down, and it takes an additional eight or nine seconds to finish writing to the SD card.

Disable noise reduction, and that jumps to twelve shots in ~3.4 seconds, the remaining nine in ~4.6 more seconds (~8.0 total), and completes the writes after another ~18.4 seconds.  So ~22.4 seconds for 21 shots.

Turn noise reduction back on but disable distortion correction, and something really interesting happens.  You get 100 shots.  And then it won’t take any more.  At all.  You have to let go of the shutter and start again.  I’m guessing there’s some kind of safety mechanism which forces no more than 100 shots at a time, in case you accidentally leave it on, shoved in your bag, and don’t particularly want it to fill your entire SD card with the inside of the lens cover (or break the mirror off trying).

It takes 26.4 seconds to shoot those hundred shots.  Give or take less than a few hundred milliseconds.  And 97 seconds to save them all.  It’s interesting that that equates to just under 3.8 shots per second, not the 4 that Nikon advertises.  I tested this repeatedly and the numbers were exactly the same every single time, to the precision shown (noted uncertainty comes from my stopwatch).

So turning noise reduction off again doesn’t help anything.  In either case you can take photos effectively non-stop, in back-to-back 100-shot bursts.  I got bored after three or four hundred – if there is in fact a limit, you’re not going to hit it in reality.

Now, use ISO 6,400, and things return to “normal”, which is a lot less impressive.  With noise reduction and distortion correction, you get seven shots.  That’s exactly the same as when shooting RAW.  It takes two seconds for those seven shots, and another ~10 seconds for the remaining fourteen, with a total write time of ~28.6 seconds.  That’s about three or four seconds faster to flush the buffer than when shooting RAW, but otherwise roughly the same.

And so it goes when toggling noise reduction or distortion correction – essentially the same “buffer capacity” whether RAW or JPEG, with writes slightly faster to the SD card, but not significantly.

So, long story short?  So far as buffer capacity goes, if you’re shooting at high ISO, it doesn’t make any meaningful difference whether you shoot RAW or JPEG.  And if you’re shooting at very low ISO, it still makes little difference unless you’re willing to turn off distortion correction, in which case it makes a massive difference.

And when you do hit the “buffer capacity” and start being write limited, then there’s actually a consistently significant difference – RAWs can be written at about 0.75 FPS regardless of ISO setting, while JPEGs run up to 1.95 FPS at ISO 100, but only 1.35 FPS at ISO 6,400.  Unless you turn off distortion correction, in which case you can get up to 3.0 FPS.

Tangentially, something else I found interesting was that the camera is incapable of shooting at it’s full 3.8 FPS if the shutter speed drops too low.  And not just to 1/4 or slower, which would be obvious, but much sooner, at 1/15 at least.  You’re lucky to get 3 FPS then.  But 1/60 is apparently fine for full 3.8 FPS.  Apparently the mirror settle time is quite significant.

Test setup:  Nikon 55-300 @ 55/4.5 switched to manual focus (and slightly out of focus), VR on, in Program mode in a dimly lit room, framed roughly the same (closed blinds, if you must know).  The camera thus chose to shoot at ISO 6,400 and ~1/80.

Both cards typically achieve seven shots before “filling the buffer”.  In repeated trials the Lexar was able to get that as high as nine, just once, while both were able to hit eight perhaps a quarter of the time.

The Lexar then shoots at about 0.75 FPS.  All told 21 shots take 32 seconds to capture and completely flush to the card (of which ~19 seconds is pure write time).

The SanDisk shoots at about 0.5 FPS, with 21 shots taking over sixty seconds to capture and completely flush (of which ~35 seconds is pure write time).

Tangentially, and sadly, on a 2011 iMac’s built-in SD card reader they both perform essentially the same – limited by the SD card reader’s pitiful performance of at most 20 MB/s.  The Lexar might have a slight edge in writing, within that 20 MB/s limit, but both cards are far from their limits most of the time.  Stupid iMac.

It’s also a bit of a crappy performance from the camera itself.  Nikon’s own advertising (not to mention the camera’s official manual) state that it can fit eighteen RAWs in its buffer, but with the small-print caveat of being only at ISO 100 with noise reduction and distortion correction turned off.

Switching to Shutter-priority mode (1/500), at ISO 100 (thus producing a completely black image in my room, but representing a reasonable sunny outdoors config), the SanDisk was able to achieve nine, sometimes ten shots before the buffer filled.  Turning off automatic distortion correction gave it maybe one more.  Turning off noise reduction gave it another one, bringing it to at best twelve.  Pretty far from the eighteen Nikon claims.

The Lexar is actually able to get close, achieving seventeen pretty reliably.  Turn noise reduction back on, however, and that goes down by about three.  Bizarrely, turn on automatic distortion correction and it goes down to nine, which is both a dramatic drop for a pure black exposure – hint: there is no distortion! – and actually less than the SanDisk.  It was in fact barely better than at ISO 6,400.

The bottom line is, in realistic use the D3200 is capable of maybe ten shots at its advertised 4 FPS.

And the winner of the two SD cards?  The Lexar does have a clear advantage, even if you’re not filling the buffer immediately.  It flushes faster so you can do more frequent short bursts of four or five, which is much more typical of my use.  And it feels much more dramatic in practice than the numbers suggest.  It was also much more consistent – those 0.75 FPS were very evenly spaced, whereas the SanDisk had gaps of up to several seconds (which I’ve been very frustrated by in practice repeatedly).

Worth the price difference?  ~$30 vs ~$60.  Hard to say when comparing them in a vacuum.  But when you consider that the camera gear is worth way more than $30 to begin with, and capturing the right moments can be highly valuable, then $30 seems a pretty ridiculous corner to cut.  From now on, I’ll be choosing high end cards.  And possibly investing in a real SD card reader, one that doesn’t suck arse.