Great, creating the usercommands folder in config/ART did the job!!! 1.3-81 does not crash at opening. Thank you very much (and also to the other guys that contribute) for all the work with ART.
I have a feature request/suggestion: adding a “lens blur” module in the local editing tab.
Sometimes the background in some photos is a little “busy” and you wish you had used a wider aperture to blur the background and isolate more the foreground.
Using the “smoothing” module helps a bit, but the type of blur is not giving the desired effect. So, what do you think about adding “lens blur” type of smoothing, either as a new module, or as a choice of type of blurring method in the “smoothing” module?
Something like that would be great to have, but I think you would need a depth map for it, and I don’t know how to compute one. Maybe it’s possible to use some technique similar to ‘focus peaking’ to estimate one, but I have no experience with this, I need to do a bit of homework first…
Borrow from dehaze or retinex?
I was thinking about something simpler like using area and shape masks to isolate the effect on the background, and refining the selection with gradients and brush masks.
In that case, maybe the new ‘gaussian’ mode I’ve added yesterday might be of use
I just tried the gaussian mode and that’s perfect! Thanks Alberto!
good morning, everyone.
With the daily use of Art, I’m missing a function that would allow me to compare 2 photos (more would be just as good) with the treatment done. When I compare 2 photos in the file browser, inspect tab, I only have access to the raw file (or associated to 2 kind of curves) but not to the full processing. Will it be possible to include a button to click to take into account the treatment done? It is possible to compare by exporting the file, but it is much more cumbersome. Likewise in the editor, I can only compare two snapshots of the same photo, but not two different photos.
Here’s a user command to do that (on linux, using geeqie and ART-cli):
[ART UserCommand] Label=Compare processed Command=./compare-processed.sh NumArgs=2
Then, the actual script (
#!/bin/bash d=$(mktemp -d) ART-cli --progress -f -s -Y -t -b16 -o "$d" -c "$@" 2>"$d/error" \ | zenity --width=500 --progress --auto-close --text="Converting to TIFF..." geeqie -n -t "$d" rm -rf "$d"
What this does:
Converts the two selected files to TIFF, on a temporary dir. It uses the “fast export” pipeline to make this quick; if you prefer the normal pipeline, just remove the
-ffrom the flags passed to
Opens the directory with Geeqie, hiding the side panels. By default Geeqie will show the first image, but just hit
U(split view) and then
Space(next image) to display also the second one
Deletes the temporary dir when you exit Geeqie
Much more cumbersome? Ctrl+S followed by Ctrl+Enter for each photo to be compared.
Two, or twenty. To compare two different photos, open two instances of ART…
Of course there are many possible alternatives to do this. But recognize that in a workflow that is supposed to be as ergonomic as possible, generating several exports in tiff (and deleting them after comparison) and opening several instances of Art, without having the simultaneity of zooming… is not very ergonomic.
the user command above should take care of both. It generates the TIFFs on the fly, on a temporary dir without any other pictures, and it deletes them when done…
On the other hand, ART is a raw processor, not a digital assets manager (DAM) like Digikam.
But give Alberto’s solution a try…
Hi Alberto, thank you very much for the script.
It works perfectly by not burdening the workflow. I just modified Numargs by minargs=2 to be able to compare more pictures if needed (and modify the script accordingly.)
Thank you very much again
Please allow me to put a comment about “feature requests” as well. Having extensively used DxO, Darktable and RT, I would suggest to NOT add too much unergonomic features. ART is on the right track to solve one of the biggest challenge of these products : become so powerfull that bottom line you end up with a labyrinthine software system (“usine à gaz” in French).
So NOT having a fille database approach, NOT having as much modules as possible, NOT having online export/printing module, NOT having dedicated compatibility with a given 3rd party software, etc. may provide what RT/DT/LR etc. are missing the most → the less-is-better effect…
From what I have gathered Alberto Griggio has already suggested that he considers the development of ART pretty much completed in terms of new features to add.
At present, only bug-fixing migth happen in the future as regards ART.
Let’s wait and see
-1 is more appropriate in the context of the post
This is mostly true, but there are a couple of things I’d like to add. No ETA though at the moment – in fact they are just ideas and might never materialize. A non-feature that I’m planning to work on sometime in the future is the transition to an external raw decoding library, most likely libraw. But this should be transparent to users.
Hello yes, what about -100?