TL;DR: I made Darktable styles which look quite close to what Fujifilm does with its Film Simulations on X-series interchangable (and non-interchangable, I suppose) lens cameras. Get the styles on the dtsolve overview page.
Table of Contents
TL;DR: I made Darktable styles which look quite close to what Fujifilm does with its Film Simulations on X-series interchangable (and non-interchangable, I suppose) lens cameras. Get the styles on the dtsolve overview page.
Table of Contents
Motivation
Before I got my Fujifilm camera in 2023, I had been shooting with a 2000s-era Canon camera. The JPEGs produced by the Canon were usually okay, but not stunning, which made me do postprocessing on them using darktable fairly often. With the Fujifilm X-T4, I faced a much different challenge: I was unable to get close to the visual appeal of the out-of-camera (OOC) JPEGs using darktable, to the point that I mostly stopped using the RAW files by early 2024.
The reason for that is what Fujifilm calls "Film Simulations". Apparently, they sampled film stock and made magic which made their JPEGs look as if shot on that specific analogue film. The styles range from highly saturated styles aimed at landscape photography ("Velvia") via solid standard profiles ("Pro Neg Hi") to completely monochrome ("Acros"). Those film sims can be selected at will and the live view in the viewfinder and on the LCD shows a realistic preview of what the photo’s JPEG will look like.
This is actually a good thing first and foremost: it saves a lot of time! I can do a lot of development right in the camera, especially since it not only supports the film sims themselves, but allows tweaking them further, with options like tone curve adjustments, saturation changes and even a basic "local contrast" filter ("Clarity").
But, there are two downsides: lack of flexibility in the cases where postprocessing is actually needed and, in particular for newcomers, a bad user experience.
More flexibility
Sometimes there are situations where the JPEG just does not cut it. There can be two main reasons for this:
- A snapshot taken quickly, leading to suboptimal exposure, wrong film sim, bad white balance etc.
- The want to do extra or more complex processing, such as masked edits in order to remove light pollution or sharpening/blurring specific areas.
Some of this can be addressed by sending the files back to the camera and re-exporting them using the Q button. That way, one can either just tweak the initial recording parameters (such as white balance, film sim, tone curve etc.) or even do a high-resolution (16-bit TIFF) export of the image, which in theory lends itself to quite a bit of additional processing.
The 16-bit TIFF files are, however, huge (158 MiB on the 26 MP sensor of the X-T4, while a compressed RAW is around 20-30 MiB). Also, this process is cumbersome. First you have to copy the files back to the camera, then you have to fiddle with the buttons to reexport it. Afterwards you need to copy the files back and check if the result pleases and otherwise repeat the entire process1.
Better user experience
The other reason for doing this was that I did not like the first user experience people have with darktable. When you import a RAW file in darktable, it shows you the embedded thumbnail by default, which looks (almost, or exactly) like the OOC JPEG.
Once you open the picture in the darkroom though, it looks very different. Typically it is much blander, both in terms of colour and in terms of contrast.
I envision a future where darktable can apply a style which matches the look of the OOC JPEG almost exactly by default, giving the user a solid starting point for further edits.2
Enter: the styles.
The styles
These styles were created by letting a numeric solver tune the darktable parameters until the result got as close as possible to the corresponding OOC image. No Fujifilm code has been reverse engineered for this.
The styles do not reproduce the original look completely. Due to the nature of how they are made (using already-existing darktable modules), a 100% reproduction of the original style would be quite unlikely to be possible for any given style. However, most of them come close enough to pass for the real thing, unless in a side-by-side comparison.
Nonetheless, let’s do the side-by-side comparison below.
Tip: This section works best with JavaScript enabled, because it will allow you to more interactively compare the images.
The left side is always the OOC JPEG and the right side is the RAW processed with the styles (plus lens correction, setting the white balance to "as shot in camera", and setting the exposure module to +0.7 EV without any other compensations).
Acros
Astia
Classic Chrome
Classic Neg
Eterna
Eterna Bleach Bypass
Monochrome
Pro Neg. Hi
Pro Neg. Std
Provia
Reala Ace
Velvia
Comparison to similar projects
There have been others who did similar things in the past. To my knowledge, all of these attempts have been based on creating look-up tables (LUTs). These look-up tables map an input colour to an output colour and thus allow to apply all kinds of visual effects to an image.
LUTs have, however, two important downsides:
Effects which are baked into a LUT cannot easily be tweaked, since applying a LUT is an all-or-nothing type of thing. This is most problematic in the case of film simulations, because they include the crucial tone mapping step of the editing workflow.
During tone mapping, the brightness curve of the input RAW image is adjusted to produce a pleasant, often contrasty image. In darktable, tone mapping is typically handled by the filmic rgb, sigmoid or AgX (new in 5.4) modules.
A LUT which includes the tone mapping step cannot be mixed with a darktable module which does tone mapping. That means that parameters which configure the tone mapping are baked into the LUT and cannot be (easily) tweaked when the LUT is applied, for example for a slight reduction of contrast in the highlights.
(Colours, on the other hand, can typically be tweaked nicely even when a LUT is in use, e.g. using the rgb primaries or color balance rgb modules.) 1.
LUTs cannot be (easily) packed into redistributable dtstyle files. While some LUT types are actually embeddable, normally darktable just references the path to the LUT file. That complicates redistribution of the styles significantly, in particular when LUT effects are supposed to be mixed with non-LUT effects.
The styles created here do not use any LUTs and are thus very malleable.
What’s next
There are three key areas where I want to build on this work:
Some styles are not yet perfect and need more refinement to be released. In particular, Nostalgic Neg is currently unsolved and it does not look like it can be done with darktable as it is today. 1.
So far, the in-camera tone curve adjustments and dynamic range modes are not supported yet. This is currently WIP. 1.
In the future, I want darktable to apply the styles automatically to any Fujifilm RAW image based on its EXIF metadata. This will require some extensions to darktable itself and/or its Lua API to make the necessary information available to tools like apply_camera_style.lua.
Once the infrastructure for that is there, I want to have the styles packaged with darktable, so that any darktable user can profit from them.
And of course, anyone3 can go ahead and use dtsolve to produce their own dtstyle files for their favourite look. And the basis does not even have to be an OOC JPEG, it can be anything for which you can obtain a RAW reference image (for example, you could solve against some LUT you downloaded to make it malleable).
Finally, I’ll publish a "making of" of the styles which I have shared here. That post will be very technical and aimed more at hackers than at photographers. Stay tuned if you are part of that intersection.
There is also the FUJIFILM X RAW STUDIO software which automates the process, but it is not available on Linux (not even with Wine). ↩ 1.
In fact, darktable 5.0.0 has started shipping styles and a Lua module which supposedly help with that.
Unfortunately, the styles shipped with darktable are sometimes far off the actual OOC image. This project is part of an effort to change that. ↩ 1.
Okay, not anyone, I suppose. dtsolve requires a Linux system and is not the most user-friendly tool there is (nor do I intend to make it that—but others are free to). ↩