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/.

GIMP 2.8 gripes

I have used Photoshop since one of the early versions when it came as a freebie with a UMAX flatbed scanner (yes, a time when Photoshop was given away for free, I am that old). When the price of Photoshop started rising to astronomical levels and when I started using Linux more often, I tried GIMP and gradually became accustomed to its unusual interface. It did most of what I required, except higher bit-depth editing. Eventually I almost completely ditched Photoshop and do pretty much everything in GIMP.

Now I have been using GIMP for years, and I have seen it evolve. This evolution was always gradual and most of the time it was subtle between versions. With version 2.8 however, there are some not so subtle changes and some of those rub me in a pretty wrong way:

1. The sliders: there are many, many people complaining about these. They are completely non-intuitive. Apparently the sliders are invisibly divided in different regions that cause different behaviour, which has to be guessed from the cryptic changing arrow cursors. I refuse to follow a tutorial or read a manual just to use something essential as a slider. And what's up with stuffing the text display inside the slider? These things violate the KISS principle in a way that makes me hurl and would make Steve Jobs cry. I simply gave up and now always enter the numbers manually, which also requires quite a bit of skill because of the risk of grabbing the sliders instead of clicking the editable text.
2. Brush size: previously, absolute brush size depended on two factors: their actual size (radius or bitmap size) in the preset, and a scale factor in the brush settings. The upside of this was that it was possible to create presets for commonly used brush sizes. Simply click a brush and off you go, if you wanted a custom size then adjust with the scale slider. What they now did is decouple the radius from the presets: each brush shape is normalised to one-pixel radius. Defining three circles at radii of 5, 10, and 20, is almost pointless because those three brushes will behave identically. The size must be set manually with — yes indeed — the awkward sliders, each and every time a different brush size is required. What used to be as simple as clicking one preset in the palette has now become: a) clicking the desired shape in the palette, b) having a go at the horrible sliders and giving up, c) trying the up/down buttons and giving up because they use ridiculous 0.01 size increments, c) having a fight with the slider to obtain access to the size edit field, d) typing the desired size. After some experimenting I found out that for brush shapes that do not fit in a square, the radius is determined by their largest dimension. For instance, to paint a brush shape defined at 24×35 pixels at its original size, the size must be set to 35. Now, the radius or bitmap size in the preset has not become entirely useless. There is a small obscure button to the right of the size field that will set the brush to its ‘native’ radius. Hence the old behaviour can be mimicked with two clicks. This may not seem like a big deal but I heavily rely on pixel-accurate brush presets for a lot of my editing. I am already annoyed by the amount of clicking around I need to do in GIMP, therefore every additional click is an added nuisance. My suggestion: clicking a brush preset while holding some modifier key (shift, alt, …) should both select the brush and set it to its native size.
3. The default brush is the clipboard brush: I almost never use the clipboard brush and if nothing was copied, nothing is brushed. And of course, if something is in the clipboard it is rescaled to the default size of 20 pixels thanks to what I described above! Doesn't it make a lot more sense to select the plain circular brush upon starting GIMP?
4. Separate save and export: the ‘save’ dialog now only allows to save in GIMP-specific formats. For all the rest, a different dialog called ‘export’ is needed. The point is, this dialog is identical in design and function to the save dialog, only it needs to be accessed from a different menu item. What is the point of this? Hidden propaganda for the XCF format?
5. Brush dynamics: to replicate the old “fade out” feature, I had to take a journey through many unintuitive windows. Eventually I arrived at something that behaves like the old fade, only it felt like I had to configure things backwards to make it work. I guess the new dynamics controls are an improvement if I would actually have something with pressure sensitive input, but was it too much asked to add a simple ready-to-use preset that mimics the simple old “fade out”?
6. Weird tool behaviour: sometimes the ‘move’ tool suddenly switches to path mode, which makes me wonder why I cannot move anything until I look at the tool window, or the ‘select’ tool switches to subtract mode for reasons unknown. There are other weird things like the arrow keys suddenly acting as “zoom in/out” even when the move tool is active. It seems like there are hidden key bindings and hidden states. One of the things I dislike about GIMP compared to Photoshop is that I often have to mash my keyboard and mouse just to do a few simple things that required one keypress and one mouse click in Photoshop, because in GIMP keys behave differently depending on what window in the interface has focus. With this version, this dependency on contexts only seems to have got worse.
7. Fuzzy select: I have always found the ability to adjust the threshold on-the-fly of the magic wand (fuzzy select) or similar colour tools to be one of the greatest features that sets GIMP apart from other editors. The way in which the selected regions are highlighted has now changed however, with two consequences: one, unless when zoomed in single-pixel regions are not visible in the selection. This is very annoying because I often use these tools to detect and remove single-pixel noise. Second, the updating of the selected area when changing the threshold has become horribly slow. I cannot tell whether this is inherent to the new system or due to the slow display update bug in the OS X version, but it has made working with these tools a hassle.

The whole redesign gives me the impression that a few newcomers have joined the project and imposed their specific ideas of image editing upon everyone. My impression is corroborated by reports from other people who say that the developers, apparently in a bout of arrogance, feel that GIMP 2.8 is perfect and everyone who dislikes the new design is a noobish amateur. I guess I must also be a n00b with my more than eighteen years of graphics editing experience.

Of course there are some plus points as well to the new version, like a native Mac OS X build, the text editing system, and layer groups. If only there was an option to switch back to plain sliders, and to instantly set brush size to the native radius when choosing a preset, then I would happily adapt to the few other minor things that bug me — if the obvious bugs would get solved too.

I also experience very slow canvas redraws for large images and when using the magic wand tool, but I suspect this to be a bug in the OS X build.