Tested again and slider loupes are OK now. Thanks!
How do you like what it can do in darktable? Any good results, or just trying it out?
Whenever I’m using it in darktable I’m constantly comparing it against what I expect from Filmulator and that strongly guides my processing tendencies, I’d like to see someone else’s interpretations of its capabilities.
Not yet, did test it in my coffee/lunch break at work, so only boring lab images. If I find time I will test it at home with more suitable pictures.
Now that darktable has also moved to an RGB pipeline, would it make sense to resurrect this idea?
I know we have filmic, but filmulator often produces well-retained contrast, saturated but not over-saturated colours, and natural-looking highlights with out-of-the-box settings, which take me the combination of several modules with filmic et al.
2 Likes
It very well could be worthwhile for users to have the option to use Filmulator in a full-featured editor as well as in its own simplified UI.
I wonder how much the old module would have to change… anyone in the darktable crew have any advice?
It would still have the same issue as before in that it has a whole-image ROI, thus slowing down the editor…
3 Likes
I’d still prefer having a slow tool that I can choose not to use over having it not available at all. The stand-alone Filmulator, on its own, has OK performance (especially if I take it into account that I only have to use one tool instead of multiple). But I do miss darktable’s tools there (e.g. denoising, arbitrary rotation etc.)
2 Likes
i think we mainly didn’t pursue this idea to integrate filmulator into dt because of performance issues. requiring the whole image is not something that helps matters in dt’s pipeline. that said, i have (dysfunctional) code that runs the complexity of the filmulator inner workings on gpu for the full image. iirc it took like 20ms to run on a full image. that was probably 16–24 megapixels, i forget. this means there is probably hope to make this very fast indeed if we spend a bit of work on it. i’m really motivated to look into this, i think there are also still very interesting effects to be simulated between silver halide grains and developer.
5 Likes
sounds like heaven!
Would that be for dt or vkdt?
It’s in vkdt. I haven’t had the time to sit down and grok the GLSL and such to bring it up to shape; so much to do in vanilla Filmulator.
After using Filmulator on my Mac for a few days (paid someone to build it for me, will make the build available soon) I would prefer to see the Filmulator ‘magic’ integrated in darktable.
I agree. Filmulator has a nice effect, but it is very much a “one-trick pony” (likely either by design or out of lack of available time for the developer to expand the program). It is lacking in a lot of features, for example: denoising , has no support for ICC profiles, doesn’t work with TIFFs, and doesn’t like raw files an old Sony camera I like to use with an RGBE sensor. While that last point will be of concern to verryyyy few people, if the same applies to other cameras with non-traditional sensors then they would also not be able to use filmulator. The filmulator algorithm itself is pretty nice, so I’d love to see it integrated with something like darktable or rawtherapee.
I believe there is denoising now…not sure about tiffs…haven’t tried it for some time as WIndows builds were broken…
Denoising does exist in the nightly builds.
I’m definitely looking into supporting ICC Profiles next (especially because matrix profiles are hideously bad for the now-ubiquitous color LEDs), and… I’m not going to support RGBE, because it would break my current white balance pipeline which involves inverting the raw->xyz matrix, which can’t be done for 4-color CFAs.
If someone wants to have a go at integration, great. Comparing or wanting features is not very motivating to the devs.
If you read the scrollback, you’ll find that I actually did have an implementation as a module in darktable but:
- It doesn’t fit the darktable way of doing things at all, because it uses the entire image area so it kinda throws away a bunch of their region-of-interest optimization when you zoom in.
- It operates in a very particular part of the pipeline since it takes in linear brightness RGB data in the output color space and outputs tone curved data.
- Even regardless of those, while it technically did work, it didn’t look like Filmulator’s output and I couldn’t figure out why. I don’t know if the issue was the color handling or what.
- I wouldn’t be dogfooding it, because I don’t use darktable.
1 Like
I’d love to if I had the knowledge of how to do so. I think suggestions can be valuable to a development community. I’m sure it gets irritating when people come across as making demands instead of making a suggestion, but saying “wanting features is not very motivating to devs” discourages people from proposing ideas or giving support to ideas that could be worth a developer’s consideration.
Dogfooding – I had to look that one up! Amusing term 
As for the ICC and LEDs, did you mean display profiles for LED monitors, or camera input profiles for LED-lit lighting conditions? To be clear, what I meant by ICC profiles was camera input profiles, but I suppose display profiles are pretty important to! I didn’t think about mentioning that one since once I profile a monitor and have everything configured they operate in the background for the most part and I forget they are there.
As for RGBE sensor, could the white balance theoretically be applied after the RGBE to RGB conversion? On the other hand, I think the WB for raw is typically applied pre-demosaicing so maybe that wouldn’t work. Oh well, I can still use filmulator for other cameras 
Ah! Yes, I think I tried one of the nightly builds a while back for the denoising but couldn’t get it to install properly. I’ll have to try again with a more recent build. Thanks for reminding me of that
I think I would probably do both together. Before, I was talking about input profiles for LED lit lighting, especially ones like this one, which causes Filmulator to absolutely flip out:
It would be an interesting trick converting the E channel to G and then pretending that it was always like that for the rest of the pipeline… I may have to look into it.
It would have worked the old way, where I applied white balance after converting to sRGB, but that was causing me issues with extreme auto white balance so I had to abandon it.
What I meant was there’s a RGBE to RGB matrix when dealing with RGBE, or an RGBE to XYZ. Either can be done. But I doubt it’s really worth the effort. The DSC-F828 is the only consumer camera with an RGBE sensor and is almost 19 years old at this point. You may wonder, why do I use such an old camera? I got it last year online because it has a built in infrared night vision mode, which while very limited, can be “unlocked” by using a small but strong magnet to slide the IR cut filter out of the way for use as color-infrared camera. If I want to do normal photos with it, I can just slide it back in place.
Anyway I’m rambling so I’ll stop there