What do you think of the following addition:
Option “ProcessTo=<filetype,like tiff>” (Probably just a bool “Process” would be fine) that will start processing the raw files right away in the gui and hand the resulting tiffs to the script. That way you can show the progress directly in the ART window (“converting image 2/5”; “running script” <…>"; …).
Another thing might be an option “SendBack=”. That would just monitor the started process. When it is finished it will open the generated image file again in ART for final touchup. Probably needs some more options to specify the path/filename of the generated image.
That would enable art to create panos/focus stacks on the fly and let me crop/sharpen/… the result. And I could directly send raw files to hdrmerge and edit the resulting dng right away in art.
Yes, you can do all that by running the single apps by hand. But having it integrated so tightly could speed up things and make it foolproof.
Verry nice to try!
The ‘usercommands’ dit not appeared in the ‘open’ menu after following the instruction and the examples placed in .config /ART-git/usercommands. Maybe I’m doing something wrong?
(System: Manjaro, latest git-version of ART and zinit , Hugin and HDRmerge installed)
I can see why this is appealing from a user’s point of view, but having such tight(er) integration is a rabbit hole I definitely do not want to jump into, as it opens the door to even more requests (“it would be nice if I could also do this and that from within the GUI…”).
Having user commands that are completely external and separated from ART (with only the minimal integration currently provided) makes them much easier to develop and maintain, and also more robust (if they crash, nothing happens to ART).
The only thing that might be worth considering is adding a progress dialog to ART-cli, but even that can already be done with a bit of scripting…
Regarding this point:
Another thing might be an option “SendBack=”. That would just monitor the started process.
No need for that. ART (and also RT) already monitors the current directory, so when a new file is added, it will be automatically available in the GUI.
Overall, I think the current way is a good compromise between ease of maintenance and features, so I’m sticking with that…
How many files did you select before right-clicking? the command shows up only if you have two or more selected (because of the constraint
MinArgs=2). If you want a simple “do nothing” command to check that everything works, you can try with this (just call it e.g.
[ART UserCommand] Label=Test command Command=/usr/bin/zenity --info --text="Test command"
I selected two files (cannon CR2).
“do nothing” works fine, it appears as (in Dutch): ‘open met’ > Test command
The Hugin-label does not appear
hmmm… you can try commenting-out some of the
Match... lines and see if that helps, maybe the constraint is a bit too tight
Now it is working! I commenting some of the Match out (the label appeared) and i make the file ‘hugin_raw.sh’ executable.
Thank you for you help!
I am talking about converting the RAW to TIFF before invoking the usercommand, which would make it unneccessary to call art-cli. Forcing the user to call art-cli makes it harder and less secure to develop such user-commands. art-cli might change, but art should always know how to do the conversion.
There are two use-cases: the user wants to use the pure RAW as script input, or the user wants the developed (in art) TIF as input. Two options make a bool.
Probably you just misunderstood the intention of that paragraph. Hopefully it’s clear now.
Thanks @agriggio for this new feature. And thanks too for the example Hugin script!
I’ll try that ASAP.
I think I understood, but my opinion stays. I think it’s not as simple as you think, and I can see many questions raising, for example: How should this be done? Should these files go to the queue? Mixed with the other ones? How about canceling the jobs? What if I want a png? Or a jpg? Or if I want to use the fast pipeline instead of the standard one? And so on… This use case is perfect for ART-cli, because all these aspects can be easily controlled by the user, by just invoking the command-line version of ART.
I see. I just think the majority of users are going to do really basic stuff that wouldn’t require scripting at all if art would pass the converted the RAW to the usercommand.
My 3 commands would be: send to hugin, send to hdrmerge, send to gimp (as layers). hdrmerge takes RAWs, hugin and gimp TIFFs.
The current “open in gimp” also isn’t quite configurable and nobody ever complained. Why not just use that also for the usercommand? If the user needs more advanced stuff he can write an own script using art-cli.
ART-cli a little bit, to allow for easier integration with zenity, using a new flag
--progress. For example:
$ ART-cli --progress <EXTRA_ARGS> | zenity --progress --auto-close
will not only give you a nice progress dialog, but it will also allow to abort the processing by hitting “Cancel”. I will also update the
hugin_raw.sh script on the wiki to take advantage of this.
Very useful extension: now I can quickly open Hugin, Macrofusion, Gimp and LuminanceHDR. I haven’t succeeded with HDRmerge yet. Nice to try
That’s strange, hdrmerge should be the easiest to integrate, as it works with raw files directly… here’s one (assuming
hdrmerge is in your
$PATH, otherwise adjust accordingly):
[ART UserCommand] Label=HDRmerge Command=hdrmerge MinArgs=2 FileType=raw MatchCamera=true MatchLens=true MatchAperture=true MatchFocalLen=true MatchDimensions=true
No, it is not strange: I started wrong with the sh-file. But with the txt file I managed, also in batch mode (without the match lines). Only thing I still miss is a notification that the batch process is ready.
Can I ask you something: with which command do I open files as layers in the Gimp? I couldn’t find that with Googling.
@agriggio I tried to put 2 user command txt files, one for Hugin and one for HDRMerge.
When both are present, only one appears in the context menu in ART. How do you add multiple user commands? Below are the 2 txt files (a copy of your own examples)
[ART UserCommand] Label=Hugin-raw Command=./hugin_raw.sh MinArgs=2 FileType=raw MatchCamera=true MatchLens=true MatchShutter=true MatchAperture=true MatchFocalLen=true # we could also consider adding additional criteria, like # MatchISO=true # MatchDimensions=true
[ART UserCommand] Label=HDRmerge Command=/home/sguyader/Photo-apps/HDRMerge/bin/hdrmerge MinArgs=2 FileType=raw MatchCamera=true MatchLens=true MatchAperture=true MatchFocalLen=true MatchDimensions=true
You can have as many user commands as you like (on separate
.txt files, just to clarify):
Did you try commenting out some of the
Match* filters? Maybe they are too strict for your use-case (and so they cause the commands to not show up when expected)?
Doh… It was as simple as that, I stupidly used the Hugin user command on a set of files with different exposures. Sorry for the noise…
I don’t think there’s a command-line flag for doing that, or at least I couldn’t find one. However, something like this should work:
#!/bin/bash # change this if your GIMP is somewhere else... GIMP=gimp bn=$(basename "$1") script="(let ((i (car (gimp-file-load 0 \"$1\" \"$1\")))) (gimp-item-set-name (aref (cadr (gimp-image-get-layers i)) 0) \"$bn\")" shift while [ "$1" != "" ]; do script="$script (gimp-image-insert-layer i (car (gimp-file-load-layer 0 i \"$1\")) 0 (- 1))" shift done script="$script (gimp-display-new i))" exec $GIMP -b "$script"