Req: Additional placeholder/variable which expands to the actual selected snapshot name

[Marcus Wißmann]

It would be very useful to have an additional placeholder for Queue->Output Location->Use template, e.g. %ss, which expands to the name of the actual selected snapshot. If no snapshot is selected this placeholder should expand to an empty string. This way we could easily create variations of the photo on snapshot basis, which get named automatically: So instead of %f_processed a better solution would then be: %f_processed_%sn, which could expand for example to IMG_1234_processed_socialmedia, IMG_1234_processed_printservice, IMG_1234_processed_webgallery, IMG_1234_processed_messenger and so on. This shouldn’t be to much work to implement but would enhance organising photos very much. Thank you!

[agriggio]

added option to specify the currently-active snapshot in the output file name pattern

See #299

→ <<cset 1ca98b8e9a5a>>

[agriggio]

This is a good idea, and indeed not hard. So, I’ve just implemented it.

The only caveat is that there is no notion of “currently selected snapshot”, so this works by comparing the current processing profile with each of the snapshots, and considering as active the first one that matches. This means that if you have multiple snapshots with different names but with the exact same parameters, always the first one will be used. I don’t expect this to be a problem in practice, but it’s worth mentioning it.

BTW: the placeholder to use is %n for the “plain” snapshot name, or %u for the name in which spaces are replaced by underscores.

[Marcus Wißmann]

That was very fast, thanks alot!

[Marcus Wißmann]

I don’t know if I better should have opened a new issue or not, but your implementation doesn’t work for me. Both placeholders (%n and %u) are always empty for me. Even if I updated a snapshot by right-clicking with the current settings. If you need some example files let it me know.

[agriggio]

Indeed, it seems I was too quick in dismissing this. I confirm that it only works sometimes, I need to investigate what is going on...

[agriggio]

procparams: properly consider auto-computed settings when comparing ProcParams instances

Fixes #299

→ <<cset 92c71215990c>>

[agriggio]

Hi, can you try again with the latest master and see if it works now? Thanks!

[Marcus Wißmann]

Hello, I am sorry, but it still doesn’t work.

[agriggio]

Ok. At this point then I need an example (raw file + arp sidecar) to be able to make progress though… thanks in advance!

[Marcus Wißmann]

Here the needed files.

[agriggio]

procparams: fix missing auto-computed settings when comparing ProcParams instances

Another attempt at fixing #299

→ <<cset 4870a6828d23>>

[agriggio]

Thanks for the samples. Maybe now it works

[Marcus Wißmann]

It looks like it is working now. I will use it intensively over the next few days and report back if there are any hidden problems.

[Marcus Wißmann]

And of course: Thank you very much!

[Marcus Wißmann]

Hi Alberto, it mostly works but not always. Here’s again a RAW/sidecar combination where it fails.

[agriggio]

Thanks! That was due to a typo in a previous commit, it should work now.

[Marcus Wißmann]

Indeed, I have processed 64 RAWs, each with snapshots put in processing queue, and everything works as intended. Great!