Nice little addition
Hi @agriggio , strangely it doesn’t work for me… The [False Colors Map] group is not in my Option file, I added it… but the skimming colours remain unchanged…
what did I miss ?
It’s probably only done in the sources, so you’ll have to wait the next release if you don’t compile nightly builds yourself.
Hello @Teto , I compile the sources myself! (with the build-art script), so I have the latest dev version!
EDIT: shame on me! I took the wrong Options file (not the one in ~/.config)
sorry for the noise…
1 Like
Hello all,
I got this message for the compilation of the last version:
Program name: art
Build type: release
Build without updating: false
fatal: .git/index : fichier d’index plus petit qu’attendu
fatal: argument ‘HEAD’ ambigu : révision inconnue ou chemin inexistant.
Utilisez ‘–’ pour séparer les chemins des révisions, comme ceci :
‘git [<révision>…] – […]’
fatal: HEAD ne pointe pas sur une branche
fatal: .git/index : fichier d’index plus petit qu’attendu
Any idea ? I download several times the archive.
Thanks for the suggestions
Hi @agriggio ,
I may have found a problem, or I missed something somewhere.
When I create snapshots, if I quit the photo without saving, an .arp is automatically created and the snapshots are saved. Typically, if you have 2 snapshots, your file is around ~60ko (compared to a file without snapshot : ~20Ko)
But, if I save specifically the arp somewhere else (under a different name), the snapshots are not saved.
Worse, if I load a photo with 2 snapshots, load an arp file without snapshot, and do Ctrl+Z, the snapshots are not recovered and are definitively lost.
Edit : And it seems that if you load an arp with snapshots, to a file that does not have the same name, the snapshots are not loaded.
Do I miss something ?
Hello, snapshots are stored in an arp file with the same name as the original raw file, plus the extension arp, like in DSC_1000.RAW.arp. You can’t change that name or copy that file to another location without losing the snapshots (which is perhaps not the expected behavior).
So I suggest not to mess with those arps (renaming, replacing) to start with.
Not here. I load a photo with two snapshots, then I load the arp profile Neutral and the two snapshots are still there.
I hope it’s not ! ^^
In fact you can, if names match, as you said, snapshots are usable, so it’s a workaround for the moment, changing manually files name.
Hi,
This is by design. The save button saves the current parameters.
I failed to reproduce this. Can you give more details?
Again by design. Load is loading only the active parameters, it doesn’t touch the snapshots.
Before you ask, I’m not going to change this behaviour, sorry 
. However, note that if you want to save (or load) complete .arp sidecars, you should be able to do that with user commands from the file browser. For example, here’s a simple one that saves the sidecar to another file:
- first, put the following in
$HOME/.config/ART/usercommands/copy_arp.txt:
[ART UserCommand]
Label=Copy .arp sidecar
Command=./copy-arp.sh
NumArgs=1
- then, put this in
$HOME/.config/ART/usercommands/copy-arp.shand make it executable:
#!/bin/sh
arp="$1.arp"
if [ -f "$arp" ]; then
out=$(zenity --file-selection --save --confirm-overwrite --file-filter="arp sidecars | *.arp" --file-filter="All files | *")
if [ "$out" != "" ]; then
cp "$arp" "$out"
if [ $? -ne 0 ]; then
zenity --error --text="File copy failed"
fi
fi
else
zenity --error --text="The selected file has no associated arp"
fi
You should now have a menu entry under “User commands” (right-click on a thumbnail in the file browser) that will copy your arp sidecar wherever you want, including all the snapshots. A similar trick can be used also for loading if needed (though in this case you would need to make sure that the picture is not open in the editor, otherwise the arp will be overwritten).
@agriggio
Hello Alberto, is there a way to run two instances of Art with two different languages for example? That way it’s easier to compare the default language file with a translation.
If you compile it yourself you can define two different values for the config directory (CACHE_NAME_SUFFIX in CMake). Alternatively, you can run two instances with two different users, or in different VMs if you like killing a fly with a cannonball
it’s a curve that you can apply at the end, after the result mask has been computed by combining the individual ones. The regularization slider lets you “smoothen” the mask to make it more uniform (though I’m not happy yet with the current implementation, so it might be tweaked in the future)
Sad. I work with pictures that are huge in size. I just keep the source, then create variants in different color profiles, but I don’t keep variants when the work is done. So having the possibility to save snapshots (because I create sometimes different light tones) as an option (in saving panel) would be useful, but never mind, as you won’t do it anyway.
I don’t compile myself.
- You open your photo with snapshots in your_photo.tiff.arp.
- Load another arp (with different parameters) this way :
- In fact, you don’t want to do that for a reason, Ctrl+Z or directly with side panel :
- You don’t retrieve your snapshots.
- Now if you close the file, the your_photo.tiff.arp is automatically saved, without the snapshots, of course… So except if you close by crashing ART, you’re screwed, your snapshots are lost forever.
This sounds like a bug. I’ll investigate and let you know.
Regarding your use case of saving snapshots, it’s still unclear to me what you want to achieve exactly. If you can provide more details I can see whether there is actually something missing or whether there is some alternative workflow that can be used.
HTH
Hi,
I just tried, but the snapshots stay there…
what am I doing wrong? Thanks!
Hello, @agriggio
Working with brush mask I noticed two strange things, I’m not sure are they bugs or not.
-
When smoothing is used, increasing the size of brush affects smoothing size of all previous strokes as well, and only when I do another stroke (with increased size). Decreasing size - doesn’t affect any strokes, and smoothing remains as if brush size wasn’t decreased. Here is a video:
2021-08-09_20-10-22.mkv (17.8 MB) -
Maybe it’s intended behavior for feathering, but sometimes it lays on the texture in some particular way, and combining it with increased Highlight/Gain results in decreasing contrast in that area. In other words, as I understand, it may lay on darker details of texture and Highlight/Gain is applied to these darker details and as result contrast of area is decreased. Switching to smoothing instead of feathering helps. Is it intended way or maybe there is something wrong happening? Here is a video for it:
2021-08-09_20-14-14-1-1.mkv (4.4 MB)
I notice it in different areas of photos and it’s not looking great and makes me to use smoothing instead of feathering.
Thank you.
Hi,
that’s expected. “Smoothing” operates globally on the brush mask, and the actual effect depends on the size of the maximum brush radius used.
feathering is an edge-sensitive blur (actually a guided filter), so in some sense it’s expected to behave differently on areas with detail wrt flat areas. But what you show in the videos is weird indeed. The guided filter is known to have some dependency on the “exposure” (on the magnitude of the pixel values, actually) so that darker areas and brighter ones affect the filter in different ways even if they contain similar edges. I think the darktable devs have come up with a variant that removes such dependency and makes the filter behave better wrt. exposure differences – I should probably check that out. In the meantime, would you be able to share one of the problematic pictures+arp?
Thank you for quick response. Sure, here is a photo and arp. Try to set smoothness of brush mask to 50 without changing anything else and then back to 0 - you will instantly notice problematic area right in the middle of the photo.
DSC_4531.NEF.arp (21.7 KB)
DSC_4531.NEF (27.2 MB)
Thank you!