Looks very appealing tbh - i’d be esp. interested in comparisons with Darktable’s filmic development mode.

The opinionated workflow in particular looks awesome - see my comment above on finally designing a way to use darktable; this overhead was something i had to do from necessity, not an enjoyable yak shave.

As far as filmic versus Filmulator, both of them can compress highlights while retaining colors, but Filmulator does it by simulating the depletion of developer while filmic has a whole bunch of math to maintain hue and saturation while rolling off the highlights pleasingly. Filmulator also enhances local contrast, which as far as I know filmic does not.

[Edit: I really appreciate the pun in the Github Wiki intro page]

Any plans to provide mac downloads in the near future?

But if I want to put a little extra effort in I may use RawTherapee for noise reduction (still working on that for Filmulator), Hugin for stitching, and GIMP for local adjustments such as fixing sensor dust, cloning out distractions, or dodging/burning.

But someone is working on adding that to darktable for Sony at least, and once that's more stable I might yoink that code.

- Unless there's a really strong reason I'm not aware of, don't bother with DNG conversion. If Camera Raw can convert your raws to DNGs, Lightroom should be able to work with your raws directly, eliminating a step.

- I use presets heavily when working with multiple images of the same subject, or from the same shoot. As long as exposure parameters don't vary wildly from shot to shot, this lets me perform most edits just once, on the first shot I edit, and then apply them to several others. From there, minor tweaks usually get me to done. (In most cases, I just crop, adjust per-channel hue/sat/lum, and tweak any edits from the preset that need fine-tuning for the image I'm working on.)

- This one might be a little controversial, but it's been by far the largest single improvement to my development workflow: Get a Loupedeck+ or some other closely similar editing console - specifically, something that's designed to work OOTB with Lightroom, and not something that needs a lot of assembly and customization to be usable.

Yes, a Loupedeck+ or similar will restrict your choice of software to that supported by the device manufacturer, and Lightroom's always going to be the best supported because it is universally the standard. And, yes, a Loupedeck+ costs $250, and the market goes up from there. It's still worth every penny.

The programs we're talking about here are complex, and they have complex UIs. Operating those UIs by means of keyboard shortcuts and mouse pointer sucks rocks. I know because I tried it, and I learned to do it, and the whole while I hated it and hated Lightroom and hated developing my raws because of how slow and picky and painful a process it was. Even with presets, I could at best manage a few photos an hour, and each hour was more frustrating than the last, to the point where the foreknowledge of the editing burden began genuinely impairing my desire to take pictures at all.

Getting a Loupedeck+ made such a difference that trying to describe it tempts me to cliché. Since this is HN, I suppose I'd put it thus: It was like going from using Notepad++ to using Emacs - except that where Emacs required a year's learning curve to achieve the kind of proficiency that made the effort worthwhile, getting proficient with the Loupedeck took less than a day.

I found it astonishing how much better the whole experience was when I had all of the develop-mode controls literally at my fingertips. Instead of endless fiddling about with a mouse pointer to select, hold, and precisely adjust a tiny slider, now I just turn a knob until the value is where I want it. For everything. The worst it gets is that, for some less commonly used controls, you have to hold down a button while you turn the knob. But it's a physical button on the actual device and, as with all the others, your fingers quickly learn where it is - which is a less obvious but very real benefit in its own right: with a physical editing controller, muscle memory comes into play.

Reading back over what I've just written, I suppose I sound a bit of a zealot on this subject, but I don't actually mind. It's a fair representation of how I feel. I genuinely cannot overstate the extent to which I've found having a physical edit controller to improve my experience of editing raws in Lightroom.

Obviously I favor the Loupedeck+, but it doesn't have to be that one - although I have to say, $250 is pretty cheap compared to literally anything else in the photography space, and in terms of value per dollar I legitimately do consider it right up there with the D850 body I use for macro work. The point is, get something, and get something that works out of the box. You won't regret it.

(Side note: You can customize a Loupedeck+ through its driver software, although I've never felt the need to modify the defaults. Also, I'm not a paid reviewer, nor have I received any consideration from Loupedeck; I'm just an extremely satisfied customer who uses it to develop everything, including the images in the pages linked below.)

(edit: I didn't notice you mentioned Lightroom 6, which may explain the need for DNG conversion. In my opinion, $10 a month is worth getting a Lightroom with current camera support; I don't love the subscription model any more than anyone else, but I'm willing to tolerate it. That said, as far as I know, the Loupedeck+ driver software does support Lightroom 6, so everything on that subject above should remain valid for your use case.)

[1] https://aaron-m.com/2019/07/08/polistes-metricus

[2] https://aaron-m.com/2020/08/09/vespula-maculifrons-priocnemi...

[3] https://aaron-m.com/2021/01/23/auplopus-architectus-metallic...

The photos you linked are really impressive, I'm curious how you managed such large DoF with the macro shots. I've only used macro rings before but found the DoF very shallow, do you use a tilt-shift lens out of interest?

The DoF just comes from stopping down a lot. The P. metricus shots are at f/32; the V. maculifrons I shot at f/25, and the spider wasps at f/22. The tradeoff with increasing ratios is diffraction vs. a more forgiving DoF; as I've gotten better at nailing focus by eye (and usually on eyes, which makes it easier due to their structure), I've found myself able to work with a wider aperture and a narrower DoF - that list is a progression in time, as well as in aperture width; the P. metricus shots are from mid-2019, the A. a. metallicus ones from late 2020. (The P. metricus and V. maculifrons were also shot on a crop-sensor body and the others on full-frame, which also makes a difference, including in DoF.)

You do need to add light at such narrow apertures, of course. I use three SB-R200s on a ring mount, with a controller on the hot shoe - a pretty pricey setup admittedly, but also one well suited to my particular use cases, including quick setup and teardown since everything has to fit in a backpack - I don't leave my cameras behind at home, they're no use to me there. For a rig that doesn't need to be put together and taken apart on a daily basis, you can do as well and much cheaper with a Lepp bracket and a couple of Ebay flashes plus an RF controller.

I don't know what to make of macro rings, if I'm honest. Even with a decent set that shouldn't have light leaks, I always end up with soft, hazy, weirdly defocused shots that just don't clean up well. I'm pretty sure it's not my technique, but I've seen enough good shots made with rings that I have to assume I'm doing something wrong and just haven't yet been able to work out what it is. It hasn't been a huge issue, but I'd like to figure it out someday, not least because a teleconverter is a really expensive way of adding magnification.

Some lenses work okay with them, others do not.

If you want more extreme macro, Laowa has some rather wild lenses, like their 25mm.

Granted I might still (eventually...) go with a TC-20 E III since it's only 10% more and I can also use it with my birding lens, but absent that constraint, I'd definitely be thinking hard about that Laowa 100mm.

edit: Well, I can use a 2x TC with my birding lens if I don't mind losing autofocus, anyway - the ones fast enough to AF with it all cost as much as a car...

https://github.com/CarVac/filmulator-gui/blob/master/filmula...

If I may, a couple things I are sorely missing for me:

- White point selector

- Incremental changes to sliders with keyboard and/or mousewheel

- Output settings (jpg name, size/quality, scrub EXIF, etc.)

Thanks for sharing.

For sliders, maybe I can have the scroll wheel adjust the sliders while you hold ctrl... I'll think about it. I'm probably not going to have keyboard focus for the controls, though.

Output settings... I'll probably replace the Save TIFF button with a Save As button that lets you select what and where to save. Not sure when I'll get to that, I have some other things I want to prioritize.

I ran through the docs but haven't tried it yet. One question/feature request, is there a cli mode available? I'd love to be able to set up some automatic pipelines to develop my photos, using a couple of pre-configured settings. If I could save some settings & then run those settings from the cli on a photo, that would be most excellent.

Edit: existing issue for a cli-driven interface exists at https://github.com/CarVac/filmulator-gui/issues/119

Is it that Filmulator gets me there with less fiddling? Or does it give me less sliders to mess things up with?

  # vim: set ts=8 sw=2 sts=2 et:
  
  # Needs post-20.09 nixpkgs for `lensfun`, I have nixpkgs checked out and import it when building:
  #
  #   nix-build --no-out-link -I nixpkgs=$HOME/repo/nixpkgs -E 'with import <nixpkgs> {}; libsForQt5.callPackage ./default.nix {}'
  
  { pkgs ? import <nixpkgs> { }, cmake, curl, exiv2, libarchive, libjpeg, libraw
  , libtiff, mkDerivation, pkg-config, qtbase, qtquickcontrols2 }:
  let
    librtprocess =
      pkgs.librtprocess.overrideAttrs (oldAttrs: rec { version = "0.10.0"; });
    # “[Use the] latest git version for Linux and MacOS.”
    lensfun = pkgs.lensfun.overrideAttrs (oldAttrs: rec {
      version = "202012142";
      src = pkgs.fetchFromGitHub {
        owner = "lensfun";
        repo = "lensfun";
        rev = "4672d765a17bfef7bc994ca7008cb717c61045d5";
        sha256 = "00x35xhpn55j7f8qzakb6wl1ccbljg1gqjb93jl9w3mha2bzsr41";
      };
    });
  in mkDerivation rec {
    version = "0.11.0";
    pname = "filmulator-gui";
    src = pkgs.fetchFromGitHub {
      owner = "CarVac";
      repo = "${pname}";
      rev = "v${version}";
      sha256 = "0gdw4mxawh8lh4yvq521h3skjc46fpb0wvycy4sl2cm560d26sy6";
    };
    sourceRoot = "source/filmulator-gui";
  
    nativeBuildInputs = [ cmake pkg-config ];
  
    cmakeFlags = [ "-DCMAKE_BUILD_TYPE=RELEASE" ];
  
    buildInputs = [
      curl
      exiv2
      lensfun
      libarchive
      libjpeg
      libraw
      librtprocess
      libtiff
      qtbase
      qtquickcontrols2
    ];
  
    meta.broken = builtins.compareVersions qtbase.version "5.15" < 0;
  }

How it is doing it? Are the highlihts technically really clipped - as in one channel (probably red) goes all the way up on the whole patch? Or is it just careful enough no to clip during "development"?

But the key is a highlight color inpainting algorithm borrowed from RawTherapee that reconstructs color channels based on the unclipped channels. On skin you get very smooth gradients at the edge of clipped areas and the highlight reconstruction is particularly free of artifacts.

But that needs to be brought into a reasonable brightness range for output. The tone mapping from the film simulation works well on skin to preserve color when darkening highlights.

That particular photo has both the blue and green color channels clipped, but the red channel let Filmulator reconstruct plausible data flawlessly. Here's the raw histogram from that file: https://i.imgur.com/NLZeM5h.png

> https://filmulator.org/comparison/

Weird DNGs converted by other software (floating point, multi image composites) often don't work either.

What's the detection signature it purports to find? Something like "Win32/Wacapew.C!ml"

RawTherapee does no photo management. Filmulator does.

RawTherapee has many ways to achieve a given result, with tons of flexibility, but gives little guidance as to what's best for what. Filmulator only has one tool for each job, and is much less flexible overall—but it's easier to learn.

RawTherapee can edit jpegs and tiffs. Filmulator only edits raws.

The UI philosophy for Filmulator is to never add things before making them fully usable and easy to learn. I like to point to the cropping tool as a significant pain point in RawTherapee that I was able to implement more elegantly in Filmulator.

Not sure about that. RawPedia is chock full of information relevant to pre-production (calibration, etc.), photography and post-production techniques, along with advice on development tool usage. I’ve learned a lot from it, which will stay with me even if I move away from software itself. It’s one of those tools with educational documentation that doesn’t just explain what the tool does but actually teaches a lot about the problem domain (similar to docs for DCamProf, which has the same maintainer).

> RawTherapee can edit jpegs and tiffs. Filmulator only edits raws.

Most software can consume DNG but almost nothing, except for camera firmware, can produce it. RT’s ability to edit 16-bit TIFFs output means it can participate in diverse workflows with other raw processors.

(For example, I use Siril to combine multiple exposures, and then can still apply a RawTherapee profile with all the numerous curves, Lab, film emulation, CIECAM and other power tools that get my pixel data into output-referred image state. Of course, some controls behave differently with a 16-bit TIFF than when a DNG image, but it’s not that difficult to adjust to that.)

Filmulator, on the other hand, can’t be used other than at the very beginning of the workflow, which takes away from its flexibility.

That said, RT sort of stands alone so far, and more open-source software that can compete with it can only be appreciated as far as I, a happy user, am concerned.