I was wondering: would it be interesting/feasible to implement the filmulator algorithm as a gimp plugin?
I could offer some help in this case…
Yes, it should be both interesting and feasible, as long as there’s no problem mixing GTK and Qt, or something like that.
How does a GIMP plugin work?
I think there are two possibilities: either write an interface plugin that calls the filmulator executable (exchanging data via image files on disk), or write a native plugin, in which case a gtk-based GUI would be needed, but the image data could be exchanged via memory buffers…
It’d have to be the first option, then.
I guess what I have to do in the meantime is enable a command line switch to make it go straight into editing…
Which pixel format and color space is expected for the input data? Linear Rec.2020?
Could you also provide a configuration file that contains the processing options?
It takes in linear brightness of whatever RGB primaries, but at the moment isn’t color managed so the colors are only accurately shown if they’re sRGB. The output is sRGB-gamma curved with whatever primaries the input was.
A configuration file… The easiest sidecar file would be a tiny sqlite database, but if I have to I can add some text format.
I guess that thefilmulator output depends on the primaries of the input data… what color space do you use when converting raws?
The idea of the text file is the following: the first time you run the filmulator plugin on a gimp layer, it creates a new layer with the plugin output. The filmulator configuration is also stored as metadata attached to this new layer.
Next time you run the plugin on the layer that filmulator has created, the plugin detects the presence of the metadata and passes it to filmulator so that the editing can be resumed from the last saved state.
What do you think?
I have it use sRGB when converting raws.
As far as what I think…I think I’ll need to make a wrapper that creates an in-memory database based on the metadata, and which at the end of editing copies the database contents out to the metadata.
Where can I look for some example code?
You could have a look at the src/plugin/pfgimp.cc file in the photo flow sources (sorry, I’m on my mobile and I cannot easily post links).
In the PhF case the configuration file is in XML format, but anything that can be put into a memory buffer would be fine
I’ve decided to attempt to do this with Rust instead of C, because I want to try it out.
Meanwhile I have quickly hacked a plug-in interface. It is still rather basic and can surely be greatly improved, but should be already good enough for some testing. Here is the link to the github repository.
The code does the following:
- it copies the content of the active GIMP layer
- converts this to linear Rec2020 colorspace
- saves the converted image to a floating point TIFF file
- calls filmulator and passes the tiff file to it, as well as the name of the output TIFF file (floating-point as well)
- reads the output TIFF file from Filmulator and converts it bask to the colorspace of the GIMP image, assuming the Filmulator output is in Rec.2020 with sRGB TRC
- copies the new image into a new layer in the GIMP image
The place where Filmulator should be called is here: gimp-filmulator/gimp-filmulator.cc at master · aferrero2707/gimp-filmulator · GitHub
For the moment the code does not call Filmulator, but simply copies the input TIFF into the output one, just for checking that the plug-in code itself works as expected.
Just let me know if that makes sense for you, and what needs to be modified in your opinions…
Well then. I guess I won’t be doing it in Rust.
I’ll start off by making Filmulator callable on the command-line…
Can you explain where I might load and store settings in that script?
As for things to change, based on my experience with the darktable iop, Filmulator really does work better as a source of data, not an intermediate processing step, so it’d be best to reconfigure it as such.
If I understand correctly, the filmulator tone-mapping method works best when applied on linear pixel data issued from the most basic processing of raw data, right?
I’m reluctant to make a file loader plugin for Filmulator, simply because at the moment the status with GIMP RAW loader plug-ins is rather messy.
So the workflow would be something like this:
- process the RAW file with whatever software you like, and save a “neutral” result
- load the “neutral” processed RAW in Gimp
- apply the Filmulator plug-in
- further tweak in GIMP if needed
But everything is open to discussion, of course.
A binary or text file optionally passed to Filmulator upon invocation, and overwritten with the new settings when Filmulator exists, would be ok… or an hard-code file on disk, or whatever else can be passed from the command line. I would say that it is up to you to see what could be more appropriate/easier, and I can adapt the plug-in code accordingly.
If I understand correctly, the filmulator tone-mapping method works best
when applied on linear pixel data issued from the most basic processing
of raw data, right?
Yeah, the original way Filmulator worked was it took in the output of dcraw -4 -T, linear 16-bit TIFFs, and then I’d take the output of Filmulator and run it through RawTherapee to apply tone curves and such.
So the workflow would be something like this:
- process the RAW file with whatever software you like, and save a “neutral” resultload the “neutral” processed RAW in Gimpapply the Filmulator plug-infurther tweak in GIMP if needed
- load the “neutral” processed RAW in Gimp
- apply the Filmulator plug-in
- further tweak in GIMP if needed
In the end, that’s no better than simply using Filmulator from the very beginning and outputting a 16-bit TIFF to edit with GIMP.
The only way the workflow would improve over the current situation is if Filmulator is a raw loader in GIMP, rather than an intermediate operation.
To my mind, there could be at least a couple of advantages:
- filmulator could be applied not only to single RAW shots, but also to stitched panoramas and other multi-shot images
- the edit would be completely embedded in a single container, with the Gimp file storing not only the final result but also the configuration used to obtain it. No need for intermediate files. Copy the gimp file to another machine where filmulator is available, and you will still be able to re-open your filmulator session and tweak the parameters if needed…
1 Like
Filmulator will be able to be applied to stitched panoramas and multi-shot images…and eventually (maybe next year, maybe the year after?) it might be able to do those internally.
As for the intermediate files…if there’s no raw loader plugin, don’t you need an intermediate file anyway?
- process the RAW file with whatever software you like, and save a “neutral” result
If that’s not an intermediate, what is?
Sorry, I was referring to the plugin itself… if limited to raw loading, it will not be able to process images other than single raw shots.
There are actually few raw loader plugins available, using ufraw, dark table, photoflow… but (unless things have evolved very recently) gimp will use dark table by default if installed on your system, and ignore the others…
Making a raw loader plugin for filmulator is not difficult at all, and I’ll try to provide that as soon as possible, but I propose to also have a version that runs as an editing filter, like g’mic…
I suppose the operative phrase here is “why not both?”.
Before it sounded to me like it was troublesome when you said that
I’m reluctant to make a file loader plugin for Filmulator, simply because at the moment the status with GIMP RAW loader plug-ins is rather messy.
It is troublesome mostly from the gimp side… that is why I propose to start from the filter version. Once we get it running, the file loading version will be rather trivial to write, and then we will need to convince the gimp developers that they have to provide a mechanism for choosing which plugin to use for opening a given raw file…
Ah, I see now, there’s no selection capability.
One hackish way to get around it might be just having a file dialog pop up letting you select a raw file when Filmulator is called, and ignore whatever was on the layer previously. I’m not sure how well the GIMP devs would take such a workaround, though.