Love this new feature in Darktable to send files to external editors, similar to the LUA script to export files to GIMP. The current version of the External Editors module seems to only support JPG and PNG files for export. Will it be also possible to support RAW and TIF files for export in the future?
Hi @Steven_Adler,
According to the LUA script, these are allowed:
local allowed_file_types = {“JPG”, “jpg”, “JPEG”, “jpeg”, “TIF”, “tif”, “TIFF”, “tiff”, “EXR”, “exr”, “PNG”, “png”}
Thank you for the quick reply. What is the name of the LUA script? I will try to add “ORF” and see if I can pass RAW files to the external editors.
I think this is a glorified export function and you can’t export raw files so I doubt it…
ext_editor.lua
Krita can handle RAWs so I just added nef to the ext_editor list, used the external editors module to export a nef to Krita: Works like a charm.
It does not export the changes made in darktable, though, just the initial RAW image. Which I think is kinda obvious.
Cool. I think the GIMP exporter in the Export module exports changes made by darktable to RAW files and exports them as JPG files waiting for GIMP to save its changes and return the new JPG to Darktable. Would be cool to integrate that code in the External Editors module…
Well, you can use this lua script to export RAWs if you want to, but why would you want to do this? (unless you exported it to RawTherapee, that I would fully understand and support 
)
Especially in the case of exporting to GIMP, which cannot handle RAWs itself and needs an external RAW editor, be it dcraw or darktable, to handle the RAW before it can do anything with it (which means it is a tiff or exr file by now).
But there are always exceptions why one wants to do something and knowing it can be done is nice.
Sorry it’s early …why would you not just open the raw in the chosen app. Not seeing a use case to open a raw in DT and then pass that to Krita???
I use DT to organize my photos and tag them. Of course I can dig through directories to find the same files, but it is more convenient to use DT as a central DAM and keep even the changes made by external editors in DT.
Yes, um, we radicals using M1 Macs might wish to add fanciness to DT edits with all kinds of external editorial magic.
Exactly my point (as stated in my reply immediately above your comment).
It’s still too early…I can see that you would use DT as DAM but don’t you do that as part of your raw development?? Passing an unmodified raw via DT to Krita and then what would you get back from Krita?? A Tiff?? At some point you lose the raw data going back and forth so you would have to decide when wouldn’t you??
I would think you would want the raw data for DT to do at least even the basic processing??
Maybe I just don’t see the whole workflow
Why are you asking me?
I’m not the one that came up with the idea to use the External Editor lua script to export a RAW from darktable to an external editor. I’m the one that tried it and mentioned that you could if you wanted to.
The reason I specifically mentioned Krita is because it can handle RAWs on its own (unlike GIMP).
So let me be clear: I personally think it is a strange idea and don’t see any use cases for this. Using darktable only for its DAM functionality might be seen as a reason, but there are better, specialized DAMs out there (but that is a personal taste in the end).
Workflow would be: Dedicated RAW editor → (possibly) Raster graphics editor → (just maybe) RAW editor.
Sorry I wasn’t meaning to “ask” you, I was just trying to follow the logic but I really don’t care either way … options are good
the feature of being able to send an image from one editor to another is common in Windows, Mac, and KDE. It can also be found in Digikam, and many other DAM’s and editing programs.
I think the difference is that dark table is primarily an editor with some DAM features, while digikam is a DAM with some editor features.
I can only ask for features. It is always up to all of you to find reasons not to want them.
I am the author of the Lua script ext_editor.lua.
The standard use case is to “export to collection” from the raw to typically a tiff ( this export recipe is also included in the script) and then edit the exported tiff with external editors (Gimp or whatever else) by doing round trips. Darktable remains the pivotal program.
But anybody can improve the script, this is the beauty of open source.
Cheers
My point is that the raw data will only go once in this proposed scheme before it is not raw data any more…its not coming back to DT as a raw so if you send it to some program unedited and then do anything to it, you get it back as a tiff or some format that is now altered and now you would no longer be using DT as a raw editor to further process data as it is no longer raw… So at which point would you want to introduce this in your workflow…
This all fine if you know that but it still begs the question why you would not use DT as much as you want for DAM or whatever purpose and also to do as much of the work on the “raw” data of your file and then further process it as a tiff, a process which the lua script automates…
In the end you can move whatever you want wherever you want as long as you know the consequences…