Show HN: Filmulator – a streamlined, open-source raw photo editor(filmulator.org)
filmulator.org
Show HN: Filmulator – a streamlined, open-source raw photo editor
https://filmulator.org/v0-11-0/
49 comments
There's nothing inherently wrong with darktable and RawTherapee and such having tons of choice in image processing, but I made Filmulator "opinionated" because among open-source photo editors it's an unfilled niche.
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.
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.
Thanks a ton, this is incredible! Compressing output dynamic range and enhancing local contrast are basically all I ever use Lightroom for, so I'm looking forward to giving this a spin instead. Opinionated tools are fantastic when your opinion lines up with that of the tool author, haha.
[Edit: I really appreciate the pun in the Github Wiki intro page]
[Edit: I really appreciate the pun in the Github Wiki intro page]
"Filmulator does it by simulating the depletion of developer" - can you explain this part?
It’s referring to the depletion of the chemicals one would use when developing a photo in a dark room.
Thank you for creating this!
Any plans to provide mac downloads in the near future?
Any plans to provide mac downloads in the near future?
I don't own a Mac, so I would need someone to either provide builds to me, or to help set up macOS CI builds somewhere.
I haven't tried it yet for my own projects, but I'm wondering if https://github.com/popey/sosumi-snap might work for such purposes. That said, I totally understand you, and am not sure if I care enough about Mac anyway personally.
Part of the issue is that I don't yet know what I don't know about building on Macs, and so it could eat up potentially weeks or months like the Windows build did.
Do you mind talking a bit more about your workflow? I have good cameras but I haven't found a workflow I find ergonomic enough, between copying RAW files off camera, converting them to DNGs to work with Lightroom 6, and editing after that - I feel I'm not doing things optimally. How do you go from taking pictures to having something print/show worthy?
I use Filmulator exclusively for about 98% of my photos, and it does everything from copying off the card and simultaneously backing up to saving a JPEG to disk.
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 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.
Glad to see that noise reduction is on the roadmap! Does Filmulator support embedded lens profiles? I enjoyed using Filmulator btw, its default output are just lovely.
It doesn't support embedded ones currently, only Lensfun.
But someone is working on adding that to darktable for Sony at least, and once that's more stable I might yoink that code.
But someone is working on adding that to darktable for Sony at least, and once that's more stable I might yoink that code.
Not OP, but I am a dedicated amateur of several years and a less than complete absence of skill [1] [2] [3]. Asked the same question, I'd answer like this:
- 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...
- 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 loupedeck you mention looks very interesting! I just found https://petapixel.com/2017/06/12/going-open-source-make-loup... which is rather interesting on using a MIDI controller for photography editing which I'm going to look into further, as the loupedeck is a bit pricey for me at the moment.
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 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?
I'd love to try the Nikon 85mm tilt-shift macro, but it is extremely pricey and I don't know if it would suit me, not least because the sense I get is that tilt-shift takes a lot of setup for which I doubt I'd have time. Of the shots I linked, only the yellowjacket held (relatively!) still in one place for long enough that I might have had a chance; the others were far more typical in that they hardly ever stopped moving and I had to take what shots I could get. These were all done with a Nikon 105mm f/2.8 VR II, courtesy of my local camera store's used gear counter; for macro use, the VR and AF capabilities are totally superfluous, but the optics are excellent, it has a good working distance even at 1:1, and the extra features are handy for using it as a long prime and portrait lens.
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.
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.
Extension rings force lenses to operate far from their original design parameters, so they often result in tons of spherical aberration, field curvature, or astigmatism.
Some lenses work okay with them, others do not.
If you want more extreme macro, Laowa has some rather wild lenses, like their 25mm.
Some lenses work okay with them, others do not.
If you want more extreme macro, Laowa has some rather wild lenses, like their 25mm.
5:1? That is wild! I didn't know about that one, but they do also have a 100mm 2:1 for $450, which is surprisingly affordable - less new than I paid for my used 105.
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...
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...
Lightroom 6 can deal with the raw files it can deal with. Anything newer than the last update needs DNG conversion. (The same thing applies to ACR in Photoshop CSX - it's happy to work with compatible DNGs, which can be created with Adobe DNG Converter, but raw support stops several years ago when your ACR engine stopped receiving updates.)
I like to convert to DNG for future proofing. As a standardised file format, I have a lot more confidence that I'll be able to open DNG files in 10 or 20 years, compared to proprietary RAW formats.
ok, this is cool: it actually simulates the physical process of how film developer chemistry "spreads/gets used"
https://github.com/CarVac/filmulator-gui/blob/master/filmula...
https://github.com/CarVac/filmulator-gui/blob/master/filmula...
I tried it out and it's pretty great. I could see getting through
a bunch of photos pretty quickly.
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.
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.
A white balance sampler was already the next thing on my list, if that's what you mean by "white point selector".
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.
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.
Yes, I meant white balance sampler. Thanks again for sharing this.
This is super cool. I had no clue that there were these interesting effects from the development process, it's a great write up you have in the wiki.
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
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
I like the software, but I'm not entirely sure about the Comparisons page. I mean, are the top images just default raw->jpeg conversions of some kind?
Because I'm quite sure I'd be able to achieve the same final result in Affinity Photo (which is what I use, Mac here).
Is it that Filmulator gets me there with less fiddling? Or does it give me less sliders to mess things up with?
Is it that Filmulator gets me there with less fiddling? Or does it give me less sliders to mess things up with?
Yes, it very little fiddling and there's fewer sliders to lead you astray.
Many many thanks, after so long without much movement in open source photography tools things are truly becoming exciting! In case someone wants to build the it using Nix I have pasted a quick and dirty port below. Not sure if I am willing to act as maintainer in Nixpkgs given my lack of experience with Qt and the tool itself, but hopefully it can prove as a starting point for someone that is or perhaps even if someone wants to build it on macOS (it does not look that difficult to adapt it for Mac):
# 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;
}> It can easily fix clipped highlights even on skin.
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"?
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"?
Well with the raw histogram you can evaluate exactly the extent of the raw clipping, which is good for honing your exposures later.
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
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
[deleted]
Am I the only one who likes the originals better:
> https://filmulator.org/comparison/
> https://filmulator.org/comparison/
beauty lies in the eyes of the beholder. So yeah it is possible the originals may look better :)
I've been using stand developing with my Tri-X film, and delight in the results, so the thought of being able to get similar results with my digital work sounds great. Thanks!
I wish you had some screenshots on the page
When MacOS build wikk be available?
When someone with a Mac makes one. I don't own a Mac nor know how to package for them.
I saw the Halide code in there, is that used in the main line or just an experiment?
Just an experiment from long ago.
got a windows defender error message when I tried to install it
Ugh, not again. It has false detections from time to time. I have to submit it to them to clear it.
What's the detection signature it purports to find? Something like "Win32/Wacapew.C!ml"
What's the detection signature it purports to find? Something like "Win32/Wacapew.C!ml"
I think for me it was not so much a concrete report, but rather the usual "this file is not commonly downloaded, please don't run it". This is bound to happen with every single version you release, unless you sign them, in which case the reputation for "commonly downloaded" belongs to the signing key instead, so subsequent versions will not show a warning again.
any opnions compared to RawTeraphee?
I see nobody answered this… so I'll answer with the caveat that I'm the author and thus biased. But I did use RT before making Filmulator, and I still use it in conjunction occasionally.
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.
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.
> RawTherapee… gives little guidance as to what's best for what
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.
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.
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.