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

Making Prosoft Hear work again with iTunes 12.6

The only reason why I stick with iTunes is that I have been suckered into it from the start when it still was a pretty good application for managing an offline collection of music files. Lately, the app has shifted towards cloud-based stuff and artificial stupidity algorithms that try to suck all the joy out of being your own virtual DJ. It is still usable for its original intent however so I haven't tried to move to an alternative… yet.

Lately, Apple has done two more stabs at endlessly annoying me and making me regret that even my alarm clock is tightly coupled to iTunes by means of Koingo's Alarm Clock Pro. The first thing they did was break the visualizer plug-ins, in the typical Apple fashion that has since many years made me shy away from developing anything specific for OS X. This fashion is of course doing it in total silence, without warning anyone or even mentioning it in the release notes. Starting with iTunes 12.6 the visualizer menu simply only shows the two built-in visualisers, ignoring any installed plugins. I am pretty glad I never took the effort to polish up my now obsolete Spectrograph plug-in. Maybe I unconsciously saw it coming.

The second thing they did, and what this post really is about, is that they also broke the Hear audio enhancer from Prosoft. I heavily rely on Hear to make listening with headphones more enjoyable. When properly set up, Hear can make even the cheapest headphones sound like expensive Sennheisers. Or in my case, make mid-priced Sennheisers sound like an explosion of aural bliss. It can also squeeze extra fidelity out of simple Bluetooth speakers or other sound systems. Great was my frustration when I noticed the controls had no effect anymore after iTunes had sneakily upgraded itself to 12.6.1, and it was even greater when I saw on the Hear product page that Prosoft officially does not support iTunes anymore. That's right, they admit that their product primarily geared towards enhancing your music experience, does not work with the de facto standard for music playback in Mac OS. I commend them for that, but it doesn't make the fact less annoying.

My guess is that iTunes has become yet another application in the row of ‘sandboxed’ apps like Safari, which are nailed shut to avoid exploits from malware and the like. After all, iTunes is linked to a store and the store is linked to credit card details. Why this also has to break the ability to manipulate the audio stream, beats me. I contacted Prosoft and they are looking if the problem can be fixed, but I'm not sure if they'll be able to circumvent the sandbox restriction.

However, I noticed that applications like Nicecast still work fine with iTunes. This made me pretty confident that I can still make the audio go through Hear after all, albeit by means of a pretty clumsy roundabout. And indeed, after the necessary cursing and kludging I made it work as follows.

Making it work

The strategy is quite simple: re-route iTunes' audio output through another non-sandboxed program that plays the stream on standard output. We can do this by means of two different free, open source projects: SoundFlower and Audacity.

1. First install SoundFlower, the current 2.0b2 release from mattingalls' GitHub seems to work fine, at least in El Capitan. Don't bother with trying to get the Soundflowerbed application to work, you don't need it.
2. In your Sound system preferences, set the ‘Soundflower (2ch)’ device as output device.
3. Open Audacity and select the ‘Soundflower (2ch)’ device as the microphone device. Select the ‘Built-in Output’ as your output device.
   
4. In Audacity's preferences, Recording, enable ‘Software Playthrough’.
   
5. Drag both the input and output volume sliders in the top-right corner of Audacity's main window to maximum. Now press ‘Click to Start Monitoring’ and start playing some music. You should see Audacity's VU meter start to move, and hear the sound as usual. You may need to give the Hear control panel a kick by toggling the on/off button or nudging a slider to make it hook itself to the audio output, but it should work.
   

Of course this has some disadvantages, like needing to keep Audacity open, and a noticeable extra delay on the audio as well. You will have no sound at all if you break any component in the whole chain. This can be pretty annoying if like me, you use your Mac as an alarm clock (it will be trying to wake you with silence which results in you being late for work). Moreover, when you switch back to direct playback through internal speakers, two things require attention. First, your volume will be at 100%, which can lead to unpleasant surprises if you forget to turn it down. Next, when you have switched back to internal speakers in the Sound control panel and plug or unplug something from the headphone jack, OS X will once more switch back to Soundflower output, and you must again select internal speakers.
In other words, not only do you need a whole ritual to set up this workaround, you also need to do a little dance to tear it down. For all these reasons I hope Prosoft manages to find a solution. I wouldn't mind if it would simply implement this workaround under the hood and have some extra delay, if only it is reliable.

This hack does have some extra advantages however, for instance Hear will also work with Safari or any other sandboxed application's audio. And, if at any time you would want to record what's playing, all you have to do is hit the record button in Audacity.

Transmission-daemon: never set peer limit to 0

In older versions of Transmission(-daemon), it was possible to set ‘peer-limit-per-torrent’ to 0 in settings.json, which would supposedly mean “unlimited number of peers”. A few versions ago however an industrious programmer found it necessary to make the limit literal and suddenly the “0” really meant “zero peers”. This caused Transmission to sit there, doing nothing, without giving any hints. It took me quite a while to figure this out. Even just a small warning in a log would have saved me a lot of precious time, dear developers…

Transmission-daemon: zet de connectielimiet nooit op 0

In oudere versies van Transmission(-daemon) was het mogelijk om ‘peer-limit-per-torrent’ op 0 te zetten in settings.json, wat dan zogezegd “onbegrensd aantal connecties” zou betekenen. Een paar versies geleden echter vond een ijverige programmeur het nodig om de limiet letterlijk te nemen en “0” betekende plots echt “nul connecties”. Dit zorgde dat Transmission op zijn gat bleef zitten niksen zonder een hint te geven waarom. Het heeft mij behoorlijk wat tijd gekost om hierachter te komen. Zelfs maar een simpele waarschuwing in een log had wat van mijn kostbare tijd kunnen redden, beste programmeurs…

More HDR

Since my previous post about HDR, I bought a more professional camera with both a larger, less noisy sensor, and a more advanced bracketing function. The camera is a Panasonic Lumix DMC-GX1 with the standard ‘pancake’ powered zoom lens. I still mostly follow the steps explained in my article about Luminance HDR, but with this camera the preprocessing step is almost always unnecessary. Here are some results, enjoy…

Sinds mijn vorige post over HDR heb ik een meer professionele camera gekocht met een grotere, minder ruizige sensor, en een meer geavanceerde bracketing-functie. De camera is een Panasonic Lumix DMC-GX1 met de standaard ‘pannenkoek’ power-zoomlens. Ik gebruik nog steeds grotendeels de workflow die ik uitgelegd heb in mijn artikel over Luminance HDR, maar met deze camera is de preprocessing-stap bijna altijd overbodig. Hier zijn een paar resultaten, geniet ervan…

Photography 101: avoid taking a photo with the sun shining into the lens. Puh!

Fotografie voor beginners: vermijd het nemen van foto's waarbij de zon in de lens schijnt. Puh!

The Arenberg castle near Leuven. Mind the crane, soon it will be impossible to take a photo like this without the new IMEC aquarium office building sticking out behind it like a sore thumb, courtesy of the great Flemish spatial planning and a certain mayor's delusions of grandeur.

Het Arenbergkasteel nabij Leuven. Let op de kraan, dankzij de fantastische ruimtelijke planning in Vlaanderen, en de grootheidswaanzin van een zekere burgemeester, zal het binnenkort onmogelijk zijn om een foto zoals deze te nemen zonder het nieuwe IMEC kantooraquarium dat de achtergrond verpest.

 I predict that if I will be taking a photo at this exact same location in ten years, it will be filled with asphalt roads and multiple specimens of the typical fake rustic villas that are prevalent in Belgium, as well as some of the newer-style shoeboxes.

Mijn voorspelling is dat als ik over tien jaar een foto neem op exact deze zelfde plek, hij gevuld zal zijn met asfaltwegen en meerdere specimens van de typisch Belgische faux-rustieke villa's en de recentere stijl van bewoonbare schoendozen.

 This was a royal pain due to the animated ‘raindrop’ lights hanging from the trees, which caused significant differences between the three differently exposed photos. These differences became ugly artifacts when creating the HDR image the straightforward way. The only solution was to manually erase all differences such that the lights were consistent between the three different exposures. I shortly tried Luminance's “Anti-ghosting” tool for this, but I could not get it to work, so I used the good old GIMP.

Dit liep niet van een leien dakje door de geanimeerde ‘regendruppel’-lichten in de bomen. Deze veroorzaakten grote verschillen tussen de drie foto's met verschillende belichting, wat dan tot lelijke artefacten leidde in de HDR-foto. De enige oplossing was deze verschillen manueel uit te vegen zodat de lichten consistent waren tussen de drie belichtingen. Ik had even geprobeerd de “Anti-ghosting” functie van Luminance hiervoor te gebruiken, maar ik kreeg het niet aan de praat dus ik heb de goeie oude GIMP gebruikt.

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.

Schrödinger's tarball (or ZIP file)

Ever so often I download a piece of software or source code packaged in a .tar.gz, .tgz or .zip file and unwittingly unpackage it inside a directory that already has a lot of other stuff in it. What I expect if I untar a file called CoolSourceCode.tgz, is that it will contain a directory CoolSourceCode with everything else inside it, for instance:

CoolSourceCode.tgz contents:
CoolSourceCode/
CoolSourceCode/Makefile
CoolSourceCode/cool.h
CoolSourceCode/main.cpp
CoolSourceCode/stuff.cpp

What I often get however, is a load of loose files at the root of the archive, like this:

CoolSourceCode.tgz contents:
Makefile
cool.h
main.cpp
stuff.cpp

The result is that all these files are then spewed and littered across the other files in my directory, with a risk of overwriting existing files that happen to have identical names.
Of course I can avoid this by first looking at the contents of the archive or always unpacking it in a new empty directory. Now, it seems to me that every time I take those precautions, the archive has been properly packaged with a main directory. If I am too lazy to do it however, boom! I am mercilessly punished. I therefore believe the contents of each tarball I download are in a quantum state of having both a top-level directory, and not having it. When I observe the contents or prepare for the worst, it collapses to the first state, if I fail to observe it, it collapses to the second state.
The bottom line is: before tarring, zipping or whatever-ing an archive, please avoid tampering with quantum mechanics. Put your files in a single main directory and compress that directory as a whole.

Schrödingers tarball (of ZIP-archief)

Regelmatig download ik een softwareprogramma of broncode die verpakt zit in een .tar.gz, .tgz, .zip of een ander gecomprimeerd bestand. Zonder nadenken pak ik dit ding dan uit in een folder waar al een hoop andere bestanden inzitten. Wat ik verwacht als ik een archief getiteld CoolSourceCode.tgz uitpak, is dat het een folder CoolSourceCode bevat waar al de rest in zit, bijvoorbeeld:

Inhoud van CoolSourceCode.tgz:
CoolSourceCode/
CoolSourceCode/Makefile
CoolSourceCode/cool.h
CoolSourceCode/main.cpp
CoolSourceCode/stuff.cpp

Wat ik vaak krijg echter is een hoop losse bestanden in de ‘root’ van het archief, zoals:

Inhoud van CoolSourceCode.tgz:
Makefile
cool.h
main.cpp
stuff.cpp

Het gevolg is dat al die bestanden dan uitgespuwd en rondgeslingerd worden tussen de bestaande bestanden in mijn folder, met een risico op overschrijven van bestaande bestanden die toevallig dezelfde naam hadden.
Natuurlijk kan ik dit vermijden door eerst de inhoud van het archief te inspecteren of het altijd uit te pakken in een nieuwe lege folder. Nu, het lijkt mij dat telkens ik zulke voorzorgen neem, het archief mooi verpakt is met een hoofdfolder. Als ik echter te lui ben om dit te doen, boem! Ik word meedogenloos afgestraft. Daarom geloof ik dat de inhoud van elke ‘tarball’ die ik download in een kwantumtoestand verkeert van zowel een top-level folder te hebben, en ze niet te hebben. Als ik de inhoud observeer of mij voorbereid op het erste, vervalt de toestand naar zijn eerste mogelijkheid, bij het onvoorbereid uitpakken vervalt ze naar de tweede mogelijkheid.
Wat ik natuurlijk gewoon wil zeggen is: alvorens u een hoop bestanden samenpakt in een ZIP, TAR of ander archief, vermijd a.u.b. deze kwantummechanische problemen. Maak eerst een hoofdfolder, steek al de rest daarin, en comprimeer de hoofdfolder als één geheel.

HDR photography with Luminance HDR and a cheap camera

If your camera has an ‘auto bracketing’ feature, it can take multiple shots of the same scene with different exposure values. Normally people use this to select a single photo with the best exposure afterwards, and throw away the others. However, it is possible to do more with this: by combining the information from all those photos, a single ‘High Dynamic Range’ photo can be created. This allows to capture much larger differences in light intensity within a single photo. There are some commercial packages that can do this, but there is also a great open-source alternative called Luminance HDR (formerly Qtpfsgui).

On my website you can find an article that explains how I use Luminance HDR to create HDR photos with a simple point-and-shoot camera that supports auto bracketing (a Panasonic Lumix DMC-FX37). Below are a few examples of the kind of results I obtained from this.

HDR-foto's maken met Luminance HDR en een goedkope camera

Als uw camera ‘auto bracketing’ toelaat, kan hij meerdere foto's van dezelfde scène nemen met verschillende belichtingen. Normaal gebruiken mensen dit om achteraf de ene foto met de beste belichting uit te kiezen en de rest weg te gooien. Het is echter mogelijk om hier meer mee te doen: door de informatie van al die foto's te combineren kan één enkele foto met hoog dynamisch bereik (High Dynamic Range of HDR) gemaakt worden. Dit laat toe om een veel groter bereik aan lichtintensiteiten weer te geven in één enkele foto. Er zijn hiervoor enkele commerciële pakketen beschikbaar, maar er is ook een uitstekend open-source alternatief, Luminance HDR genaamd (voorheen Qtpfsgui).

Op mijn website kan u (in het Engels) een artikel vinden dat uitlegt hoe ik Luminance HDR gebruik om HDR-foto's te maken met een eenvoudige compacte camera die automatische bracketing ondersteunt (een Panasonic Lumix DMC-FX37). Hieronder vindt u enkele resultaten die ik hiermee behaald heb.