Spektrafilm (dev branch) analog film simulation module

[piratenpanda]

This module brings the spektrafilm project (https://github.com/andreavolpato/spektrafilm) to darktable. Spektrafilm simulates analog film processes and applies them to digital images.

This module has been derived from the spektrafilm project and tries to stay as close or exact to the algorithms used there.

Currently it looks like this:

Film and print stocks can easily be selected via drop downs. Further settings are then handled inside the respective tabs (currently untranslated).

Default settings are Portra 400 and Portra Endura which transform your image from

to

Currently almost every film/paper combination from the spektrafilm dev branch is working except for Kodak 2302. Grain, Halation and Diffusion models are working as well.

Discussion thread and the python script needed to create the necessary spektrafilm data for darktable can be found here: https://discuss.pixls.us/t/spektrafilm-darktable-module-sort-of/58744/

Current dtdocs PR darktable-org/dtdocs#993

[Arecsu]

This is just amazing, love this

[Arecsu]

Right now there is a problem where, if I load up an already existant photo + XMP settings from my database, the module won't show up and I will get this in the CLI:

   312.1009 cannot get iop-order for spektrafilm instance 0
   467.4585 cannot get iop-order for spektrafilm instance 0
   467.4784 cannot get iop-order for spektrafilm instance 0

I have to edit a new image from a clean slate in order for the spektrafilm module to show up.

Other than that, working awesome. This is the scariest, closest film simulation look and feel I've ever got from any photo editing pipeline, in any software. And oh god did I spent a crazy amount of time on it. Main reason I fell in love with Darktable was because I could get really close to it with the existent modules. AGX, Diffuse and Sharpen, LUTs... Until I came across spektrafilm, and now this module... it is a game changer. There's currently no way to achieve these visuals otherwise. Props to @andreavolpato!

[piratenpanda]

@Arecsu should be fixed with the latest commit

[Arecsu]

@piratenpanda Thank you!

You may be interested in Arecsu@f2ce151, which I made on top of your PR

I've created this pre-compression boost as I find myself reaching out the tone curve module very often to push the histogram to the right when I use spektrafilm, because it tends to aggressively limit the highlights ceiling in some cases. This slider should preserve the characteristics of the module, gently pushing or pulling the histogram.

Feel free to test it and incorporate it into your PR in any case!

[Arecsu]

Hey, I found another reference: this Davinci Resolve OFX based on spektrafilm and exposing far more options, in a nice workflow as well:

• https://spektrafilm.114c.de/
• https://github.com/chaert-s/spektrafilm-ofx

I think the UI/UX and the options exposed by it are more appealing here in darktable for this module, as well as the logic behind them.

Here at 5:45 you can see it being used. It does seem comprehensible and with many interesting sliders and selectors as well.

[piratenpanda]

Thanks for the input. I'd like to move design/implementation discussions to the pixls thread to make it easier to follow :)

[TurboGit]

@piratenpanda : I would edit the first message to give a high level description of what this does, what is the goal and maybe some screenshots with before/after to illustrate the points.

[piratenpanda]

@TurboGit initial update done. Thanks!

[TurboGit]

Another pass... some more questions.

[TurboGit]

Those hashes are references to the on disk .json / lut, right?

So has for LUT3D module, the module's parameters is not self contained?

My question : Would it be possible to have all stored into module's params? What is the size of the data needed?

[TurboGit]

Here my concern is that for a scene to display final step it is not good to have to rely on external data.

[piratenpanda]

Per-image data: one film + one paper profile, packed as raw float32 with the JSON overhead stripped: ~32 kB. The bulk is density_curves_layers (256×3×3), density_curves (256×3), log_sensitivity, channel_density, base_density, midscale_neutral_density (81×3 each). And that's the current state. Will only get bigger as spektrafilm evolves.

Shared data: identical for every image, so it can't live in params at all sensibly: the hanatos2025 spectral upsampling LUT, CMFs, spectral locus, 8 illuminant SPDs, 4 brands × dichroic filter curves, the neutral print filter database, and per-stock coupler/grain/halation tuning. That's the whole pack.json plus spectra_lut.f32.

So even the per-image half is ~32 kB of params per history item, and it still wouldn't be self-contained without the shared half.

We could add the data to /data like noiseprofiles? And add the python script to create the data to /tools maybe?

[TurboGit]

We could add the data to /data like noiseprofiles? And add the python script to create the data to /tools maybe?

If we can do that it would be perfect. An XMP will be self contained then as all XMP (except LUT3D) currently.

[Arecsu]

I think having them as external data (not embedded to the module code) is good for two reasons:

1. If someone wants to reference the data in isolation to the code, maybe they want to create their own print and film stocks and need a reference to point out without having to point out to the source code of darktable
2. Following the previous point, for them to be able to load and the community to share / experiment with new print and film stocks in an easier way, having a directory where they can drop them and have darktable to load them, similarly to the LUT module in some way maybe?

There could be default data that comes with Darktable installation, like the current film stock and print papers from the module, and then data added by the user somehow in some directory

Hopefully I'm not mistaken this discussion and what I'm saying is related to the topic 😅

[TurboGit]

Profiles aren't content-hashed yet, if a stock's measured curves are revised the name is unchanged and the render silently differs

Ok, so from version to version we are going to break edits :( Not good... I would say that this should be fixed in spektrafilm, a hash should always refer to the same "object".

So we have the option to ship it as darktable data alongside noiseprofiles and the kernels, this means adding: spectral LUT 5.7 MiB, 31 stock profiles 2.8 MB, plus 70 kB of constants to the tree. That's not my decision to make.

It's a lot indeed... Alternatively the module could download the data at first use if not yet downloaded. Probably the way to go if you ask me at this stage now that I have a better understanding about the data. That's to be done once for all dt instance (download into $HOME/.local/share/darktable/spektrafilm). This is a bit like what is down for AI modules but automatically in the spektrafilm case.

But I fell that we have many things to clarify to ensure a proper Darktable integration. So let's continue the discussion.

[piratenpanda]

Ok, so from version to version we are going to break edits :( Not good... I would say that this should be fixed in spektrafilm, a hash should always refer to the same "object".

Yes, maybe I didn't properly word it. This would need keeping spektrafilm files constantly available or at least downloadable so we can do something like:

XMP records: lut_hash = 565f4ec4, profiles_hash = a1b2c3d4
darktable ships: spektrafilm/0.3.3/ spektrafilm/0.4.0/
on load: resolve hashes → 0.3.3 set → identical render

The mechanism should make sure it doesn't spam the user's folders but also keep data readily available

[piratenpanda]

@andriiryzhkov does the AI component offer a reusable fetch mechanism? Like if spektrafilm version x.y. is not in the user's folder download the data from git repo xyz?

[matze]

spectral LUT 5.7 MiB

Drive-by comment, fpzip could cut it down to 1.17 MiB but not sure if that is a) enough and b) worth the additional dependency.

[piratenpanda]

Latest code does the following:

• Prefer pack data in config folder
• If none is found and the image has not been edited yet, the module does show a download data button only, downloads the latest pack data currently from https://github.com/piratenpanda/darktable-spektrafilm and let's you start editing. This also downloads the correct hash for older edits when no data is found and such an image is opened first.
• If a hash of a previous/old version is found in the xmp data, it shows a version mismatch and offers to download the appropriate hash from the git repo

This ensures color, film and paper data match the edit and stay consistent.

What is not yet implemented or needs to be discussed further is what happens when spektrafilm's algorithms for something else change. E.g. Grain, halation, new couplers for new paper/film data, etc. A drop down like filmic's color science versions could fill that gap but would of course add even more complexity to the module.

Current min pack version is 2, before release we can of course set this to one if the format and mechanism has been finalized.

[anoderay]

Regarding the discussion about including the spektrafilm data pack: IMHO, we don't currently have any other module that depends on an active internet connection to work out of the box. Especially for opening older edits offline. (Yes, the AI features require a download, but they don't affect existing edits.)
A possible compromise: bundle the latest data pack by default, and fall back to the newly implemented download functionality only when an older edit references a data pack version that isn't bundled.

Given how actively spektrafilm is being developed, I also think it would make sense to include a version switcher for the filmic-style presets as already discussed.

[da-phil]

Nice module, thank you for taking on the task to bring spektrafilm to darktable!
After having had another look at the original python implementation, I wonder if we also want to establish a couple of (unit)tests (in src/tests) to ensure functionality doesn't silently break when changes are made to the code.

[piratenpanda]

Nice module, thank you for taking on the task to bring spektrafilm to darktable! After having had another look at the original python implementation, I wonder if we also want to establish a couple of (unit)tests (in src/tests) to ensure functionality doesn't silently break when changes are made to the code.

I ported the unit tests. Currently no pack data is in this PR but as darktable will ship the most recent one the tests are already in place currently looking at /data/spektrafilm. Will update once we know which version will be shipped with darktable or at all.