HDR photos with a smartphone, built-in versus my own method

On this blog, I have published some examples of HDR photos before, which I created manually by relying on auto-bracketing features in digital cameras and combining the multiple exposure photos using Luminance HDR. One could argue that this is obsolete because pretty much every smartphone camera app nowadays has a HDR feature built-in. As I will show below however, this often leaves much to be desired and it still makes a lot of sense to produce HDR photos the manual way, be it with the smartphone camera or a ‘real’ camera.

My most recent smartphone is a OnePlus Nord, but its built-in HDR is a general nuisance. It only engages when it believes there to be a need for it according to some vague heuristic. Even when it claims to be enabled, sometimes the result shows no HDR at all, probably because it failed to find matches between the images. The latter usually happens when HDR is most needed, when taking photos of sunsets that result in high contrast.

This made me look for an alternative camera app that offers exposure bracketing, such that not only could I make HDR photos when I want to, I can also make them the way I want instead of having to rely on the half-baked algorithm built into the native camera app. I found Open Camera, which proved a great solution.

In this blog post I will compare some HDR photos taken with both the OnePlus camera app (and one with Open Camera's HDR), and HDR photos of the same scene produced with my own workflow, as explained in the article on my website which I recently updated.

Example 1: OnePlus' HDR versus mine. As usual with the built-in HDR tonemapping in smartphones, it tries hard to show details everywhere by pretty much steamrollering the intensities into one flat dull result. The overall image is too bright, lacks saturation, and does not represent the scene how I experienced it. My HDR image might look a bit dark in comparison, but it much better represents the sensation of the actual scene when viewed in its own on a big screen.

Example 2: again, the OnePlus HDR makes things too bright and it looks more like a daytime shot with some colour filter than a shot taken at sunset.

Example 3: same remarks as above.

Example 4: again, the OnePlus HDR makes the sky a dull mess, while all the interesting things are happening there.

Example 5: this time, the OnePlus HDR has roughly the same overall brightness as mine, but local details are lacking, especially in the darker areas where everything is just clipped to black.

Example 6: here I first show the result from the OnePlus camera app, then the built-in HDR of the Open Camera app, and finally my own HDR. The first 2 are similar although the Open Camera result has some artefacts that I sometimes also experience with Luminance HDR when I didn't use a sufficiently large range of exposures to capture all intensities in the scene. But again, the automated HDRs are too bright and have a yellowish tint that does not correspond with how I experienced the scene.

Example 7: again OnePlus versus mine, and again the colours in the OnePlus image are washed out and despite its overall higher brightness, details in the darker areas are lacking compared to my image.

Example 8: (added 2022/08/14) this was a particularly challenging image due to the enormous dynamic range. Obviously, the OnePlus app only takes 2 or maybe 3 photos with a rather limited exposure range, and lost the subtleties in the sky colours. The result looks harsh and overly bright. I switched OpenCamera to 5 shots with an exposure range of ±3 stops, which allowed to capture the scene as it was. I had to tweak saturaton more than usual to end up with a result that matches how I experienced this scene in the real world.

Conclusion

Again, if you want to make HDR photos the same way as I do, check out the article on my website. One of the things that makes it fun to process one's own HDR photos, is the fact that it brings back a bit of the magic that used to be experienced when taking photos on film, and only seeing the results later on when the film had been developed. It is not exactly the same thing, but producing the HDR image from the raw bracketed photos does have a bit of a feel of “developing” the images.

Making G'MIC Qt GIMP plug-in work in the 2.10.30 Mac version

If you are using the G'MIC-Qt plug-in for GIMP on Mac OS, especially the one from aferrero2707, you may have encountered this error after upgrading to a recent GIMP build:

GIMP says: “Plug-in crashed: "gmic_gimp_qt",” and warns about the dying plug-in possibly messing up GIMP's internal state.

Running GIMP from the Terminal yields a bit more information:

dyld: Library not loaded: @rpath/libintl.9.dylib

  Referenced from: /Users/username/Library/Application Support/GIMP/2.10/plug-ins/gmic_gimp_qt

  Reason: image not found

The Resynthesizer plug-in build from the same author suffers from the same problem.

It seems that these builds of the plug-ins rely on the presence of a dynamic library file ‘libintl.9.dylib,’ most likely in the GIMP application bundle itself. But, my current build of GIMP only includes libintl.8.dylib. Judging from a related issue report on GitLab, there never has been a true version 9 of this library and the number 9 was due to a mistake in the gettext library, which explains why the version number seemingly decreased.

Until someone creates a new build of the plug-ins, there is a relatively straightforward workaround: shove a copy of the libintl file into the G'MIC and Resynthesizer plug-in library folders, and give it the expected name. This ensures the plug-ins will always find this library regardless of what is in the particular build of GIMP.

There are 2 ways to obtain the dylib file:

1. [Slightly harder for those unfamiliar with low-level workings of Mac OS]
   Open your GIMP application bundle (either by right-clicking the app icon, or by using the Terminal), and find the libintl.8.dylib file, normally in Contents/Resources/lib/.
   Copy this file and rename the copy to libintl.9.dylib.
   This works because there is no significant difference between the version 8 and purported version 9 of the file.
2. [Easier but not that safe]
   Directly download it from wherever you find it on the web, and hope it is trustworthy. (This particular one works for me, it is 77584 bytes in size and has an MD5sum of 2a88ed7a2d8901fd0e75401e761b24d2.)

Place the libintl.9.dylib file inside the GMIC/lib folder where you installed the G'MIC plug-in, most likely ~/Library/Application Support/GIMP/2.10/plug-ins/GMIC/lib/, then restart GIMP and it might work.
Same for ResynthesizerPlugin/lib/.

Black & Decker 90515265 blade clamp can be used on the POW 1004

In a nutshell: you can use the Black & Decker 90515265 blade clamp as a spare part for the Powerplus (Varo) POW 1004 jigsaw.

This blade clamp on my old POW 1004 crumbled into pieces when I tried to use the saw after it had been sitting idle for many years. The part is made from the typical cheap metal alloy that is often used for casted parts. I don't know what metal this is, but it is like the equivalent of papier mâché and it seems to degrade over the years.

I was about to toss the whole saw because it was very cheap anyway, but I did a quick search for spare parts anyhow. I didn't find any spares for it, but this 90515265 Black & Decker part kept popping up amidst the results and it looked awfully similar in shape. I took the gamble and ordered two. Lo and behold: it just fits. It has an extra protrusion that makes it a tight fit and I milled just a tiny bit off the saw's body just to be sure, but this is not actually necessary.

I guess the reason why this fits is because many of these cheaper saws use the same internal components from some generic Chinese manufacturer. Not sure if this poorly made clamp part is a case of planned obsolescence or just poor design, but anyhow now we know how to avoid another piece of e-waste.

The B&D part looks much better designed with some extra reinforcements, but I still recommend not to overdo the tightening of the saw.

(and now in Dutch…)

B&D 90515265 zaagklem past op de POW 1004

In een notendop: u kan de Black & Decker 90515265 klem voor zaagblad gebruiken als vervangstuk voor de Powerplus (Varo) POW 1004 decoupeerzaag.

Deze klem op mijn oude POW 1004 verbrokkelde totaal toen ik de zaag probeerde te gebruiken nadat hij een paar jaar ongebruikt was gebleven. Dit onderdeel is gemaakt van de typische goedkope metaallegering die vaak gebruikt wordt om gegoten vormen te maken. Geen idee wat voor metaal het is, maar het lijkt het equivalent van papier-maché en schijnt bros te worden over de jaren.

Ik stond op het punt de ganse zaag weg te smijten omdat hij toch goedkoop was, maar ik besloot desalniettemin een snelle zoektocht te doen naar reserve-onderdelen. Ik vond niks voor dit model, maar dat 90515265 Black & Decker onderdeel bleef terugkeren in de resultaten en leek wel heel hard in vorm op het kapotte deel. Ik deed de gok en bestelde er twee. En kijk eens aan: het past gewoon. Er is een extra uitstulping waardoor het erg dicht bij de behuizing komt, en voor de zekerheid heb ik een klein beetje van de plastiek weggedremeld, maar dat was eigenlijk niet nodig.

Ik denk dat dit past omdat veel van deze goedkope toestellen dezelfde ingewanden gebruiken van een of andere generieke Chinese fabrikant. Ik kan niet zeggen of deze slechte klem een geval is van geplande veroudering, dan wel of het gewoon een slecht ontwerp is, maar nu weten we in elk geval hoe we nog een stuk e-afval kunnen vermijden.

Het B&D onderdeel lijkt veel beter ontworpen met extra verstevigingen, maar ik raad toch aan om het niet te hard aan te vijzen.

Apple made system calls horribly slow in the 10.14.6 update. Thank you, Apple!

After installing the Mac OS 10.14.6 update from the end of September 2020, I noticed something wasn't right. A simple Perl script that scanned a directory for all files and that invoked the stat system command for every file, had become way slower than before. I'm not sure if the same would have happened if it had relied on Perl's own stat() call, but this script needed the shell command because it can offer information that Perl's own stat couldn't provide.

Also when running a homebrew update, it seemed way slower than usual. It looks like Apple had messed something up w.r.t. system calls from within scripts, and perhaps other programs as well, although I didn't notice anything in regular apps. I knew this was likely to be reported by a gazillion developers and fixed soon, so I didn't bother. That horribly slow script of mine was annoying though, so I started seeing if it couldn't be improved.

The problem here was that the Perl script did the obvious thing of invoking a new instance of stat through backticks, for every single file it encountered. That's a lot of overhead. Until now the overhead wasn't bad enough for me to be sufficiently annoyed, but Apple's “update” had now pushed this way into the zone of bad words and gnashing teeth. The solution was pretty obvious: reduce the overhead by reducing the number of system commands. Luckily this could be done: the stat command does accept multiple files as argument, and returns the results as multiple lines in the same order as the arguments.

So, all I had to do was postpone the invocation of `stat` and build a queue of file paths, and execute the aggregated system command whenever it reached a certain size. In theory I could wait until the command line was about to exceed 262144 bytes (minus some margin to allow environment handling), which is the maximum system command length as reported by “getconf ARG_MAX.” In practice, I used a lower limit of 16 kBytes because above a certain threshold, the gain becomes pretty negligible anyway.

The result was that for a particular run, the script went from a 120 second runtime to 3 seconds. After Apple fixed the performance issue in a supplemental 10.14.6 update, the runtime became sub-second. So in the end I guess I should thank Apple for forcing me to refactor my script and making it way more efficient. Maybe every operating system should now and then introduce a temporary penalty on certain operations, or a limit on resources, just to force developers to be less lazy and actually improve their software instead of writing sloppy code and letting the machine just brute force it…

Cosmic Frontier: Override, a remaster of Escape Velocity: Override

A year ago I posted how it is still possible to enter your registration code in EV Nova, by jumping through some hoops. If you want to play the previous instalment of Escape Velocity however, Escape Velocity: Override, maybe this will soon be possible again without any need for special magic, in a brand new reincarnation of the game.

A Kickstarter campaign has been launched to rebuild the EV: Override game engine for current operating systems. Due to legal reasons, the game will have a different name: Cosmic Frontier: Override. One of the persons on the team for this Kickstarter is Peter Cartwright, who was the scenario designer for the original EV Override game.

The remaster will feature the original scenario, augmented with new content like new ship types and new mission strings. Depending on your backer level, you can influence this extra content, like having your own starport bar or ship variant. At the time of this writing, the campaign is just beyond its 50% funding mark, with 19 days to go. I'd really like to see this succeed, so if you are a fan of games like Escape Velocity and you have about $10 (or more) to spare, head over to the Kickstarter page and make your contribution.

The Dreaded Butterfly Keyboard: trying to postpone the inevitable

In a nutshell: If you have an Apple MacBook Pro or other machine with the dreaded ‘butterfly’ keyboard and it starts to exhibit problems, you options are:

• If you experience the problem of a certain key sometimes not reacting, try detaching the keycap (important: do not try this without first reading the “How to” section below for instructions). After looking—with a magnifying glass—for obvious dust, hairs, or crumbs and carefully removing any with precise tweezers, blast the mechanism with air from multiple directions, and reassemble the key.
• If you experience the problem of a key producing multiple keystrokes per press, first do the above, and after reassembling the key, hit it many times as hard as you're comfortable with. Just type a piece of text like a madman, and there's a good chance that the key will behave afterwards.
• If the above doesn't help, or problems occur too often, or you are not comfortable with taking the keys apart, and you have bought the machine less than 4 years ago, your better option is to go for the Keyboard Service Program.

The full story

A few years ago I was kind of forced to buy a new MacBook Pro, because my previous one, a 2011 model, had the dreaded GPU failure—another design flaw by Apple albeit lesser known than the keyboard debacle. Given the high price and the rumours about the bad keyboard, I seriously considered buying a Thinkpad or other PC laptop, but it looks like I am still too much locked into the Apple ecosystem to take that step. I hoped that the newer design with the extra silicone ‘flaps’ built into the keyboard, would make it reliable enough that it wouldn't develop problems in the situation where the MacBook Pro would be sitting 95% of its lifetime. But that was too much wishful thinking.

Even despite the fact that this laptop sits on a Griffin Elevator in a normal room with regular levels of dust, some keys did develop problems within less than one year. The down arrow key was first, it would sometimes miss a press. Then the same started happening with the Return key. I found a very useful page on iFixit Answers that showed how both thes keys were assembled, and this allowed me to detach them without destroying them. I then blasted the insides of the mechanism with air like crazy, and that has effectively remedied this problem.

A while later however, another problem started showing up: some keys, especially the ‘E,’ started producing double and sometimes even triple presses. The extra press would often come late enough that typing ‘bed’ could result in ‘bede.’ I again took off the ‘E’ key and inspected the internals, but all I found was a tiny hair that was only visible with a 10× magnifying glass. I gave the key the same treatment as the others, but it kept on exhibiting the multiple keystrokes problem.

It seems to me that this key repeating problem is not caused by dust particles. It rather looks like the contacts become unreliable, maybe due to an oxide layer forming on them? The keyboard can become pretty hot when the machine is under heavy load during an extended period, like when running a modern game. Maybe this degrades the contact surfaces? This theory is further corroborated by the fact that I eventually did manage to make this problem go away, by simply punching the key much harder than usual. Percussive maintenance does work, even on delicate modern machines…

The good news is, after a class-action lawsuit, Apple has started a repair program that allows to bring in your machine if it obviously exhibits these problems with the keyboard. They will then replace the keyboard, which usually means replacing the whole top assembly. As explained in this video by Louis Rossmann, theoretically it is possible to replace only the keyboard, but only with very specialised tools because the thing is actually riveted into the case and in many machines you need to detach the glued-in batteries without rupturing them and setting your workshop on fire.

And by the way, I fully agree with Rossman that I expected a machine this expensive to at least be as reliable as a much cheaper one with similar specs, and also much more serviceable. Where are the days when Macs were modular machines that could be entirely taken apart without even needing a screwdriver?

Even though the repair program is free, the downside of course is that you will have to do without your computer for a few weeks. So if you are only having mild problems with the keyboard, it may be a better option to first try to remedy it yourself, but only if you feel confident enough that you won't make things worse.

How to detach the keycaps without destroying them

If you want to have an attempt at detaching the keycaps yourself, BE VERY CAREFUL. Do not simply yank on the caps from any direction, or you will break little hooks and the cap will be forever loose. The trick is to slide a thin piece of plastic in between the cap and the butterfly mechanism (see SHOVE in the pictures below). Do not go too deep, try to keep the plastic as horizontal as possible to ensure it does not go under the butterfly hinges themselves. Then shift the plastic towards the clips (called slide in the pictures) to detach them. For most of the regular keys, the cap is attached with two clips at its top end, and two hooks at the bottom. For these keycaps, start the SHOVE in the middle of the left and/or right edge, as indicated with the arrows in the photo below, then slide upwards. Once one of the clips is detached, you can usually keep sliding across the upper zone of the cap to detach the other clip as well.

A piece of cut-up blister packaging works well for this purpose, but a thin guitar pick (plectrum) should also work well. The longer keys like backspace will typically have 3 clips instead of 2.

For other keys, the procedure differs only in the place where you have to shove the pick and in which direction you should then slide it. For the ‘up’ arrow key, the clips are at the right. For the ‘down’ key, the clips are at the left. For the tall European style of Return key, the clips are at the left, and there are 3 of them. I have borrowed the photos from the iFixit page to illustrate this. Note how the whole mechanism of the return key has been detached in this photo, this is not how it is supposed to be.

To reassemble, slide the hooks back in their place, then re-engage the clips by pressing on the zone where they reside.

The space bar is notoriously difficult. If you feel you need to take it apart, consider going for the Apple repair program instead. If you break things, you won't be able to benefit from the free repair.

And of course, the usefulness of the repair program is very debatable. The replaced keyboard will suffer from the same flaws. I wish there would be a replacement program where I could exchange my inherently flawed MacBook Pro for a considerable rebate on a late 2019 MacBook Pro with its reliable scissor keyboard.

A final piece of advice

If it isn't already obvious: never do anything in the vicinity of your butterfly keyboard equipped machine, that could cause any small particles to fly around. Or, cover the keyboard with a sheet of paper if there is any such risk.

Recently, the backspace key started acting up. Something had obviously got inside the mechanism, but with the naked eye I couldn't see anything suspicious. Even after repeated sessions of removing the key cap and blowing air, it kept feeling strange and sometimes did not respond to presses. I then took a flashlight and magnifying glass, and finally saw that some tiny piece of something had got under the mechanism. It was a pain to remove because Apple's silicone flaps that were supposed to keep junk from getting inside, now made it hard to get the junk out. I eventually managed it with extra fine tweezers, and it proved to be a tiny piece of clipped fingernail any other keyboard wouldn't care about. So, don't clip your fingernails in the vicinity of the keyboard…

True Tone display abruptly changing tint? Try not covering the sensor!

On various forums, one can find complaints about the True Tone display of the more recent MacBook Pro models suddenly changing tint, or the intensity of the screen flickering. Some of those forums will tell you to disable the True Tone or Night Shift feature. If you don't care about those features, it's an effective workaround, but it is kind of stupid to buy a machine with all these advanced features and then disabling them.

I have also experienced this, and found no rhyme or reason behind it—until now.
I'm pretty sure there are some other causes for this problem, including hardware or software faults, but before you go bringing your MacBook Pro to a service center, you might want to check the following first.

Many people cover the camera built into laptop screens with a sticker or something else, for reasons of privacy and/or security. The problem is that the True Tone sensor is very close to the camera. If your sticker is large enough, it will partially or fully cover the sensor. Even if that's not the case, maybe you often do use the camera, and then have to park the sticker somewhere, and a convenient place is right next to the camera—possibly right on top of the sensor.

When covered, the sensor will receive much less light than it should, possibly filtered in some strange way, and this can cause the True Tone system to react wildly to tiny changes in ambient light. I still don't understand why the adaptation algorithm allows such quick changes at all, but one can't really blame the system for starting to act weirdly in a very poorly conditioned situation.

The sensor is very hard to see, which is why most people are unaware that it exists at all, let alone avoid covering it. On my MacBook Pro model (2018 15 inch), the sensor proves to be at 17 mm to the right of the (more visible) camera, as can be seen by shining a strong flashlight across it. You may want to verify on you particular machine where the sensor really is situated.

So the morale of this story is: if you have any thingamajig that covers the camera, make sure it stays well away from the sensor. If you then still have strange variations in the tint of the display, then you may start worrying about a deeper problem. As a matter of fact, in my case the problem still occurs occasionally. It looks like the sensor gets confused in situations where there is little light, or rather weak light coming from a direction mostly parallel with the screen surface. What usually helps in such cases, is to provide a stable source of light closer to the computer, so just turn on a lamp.