Jump to content
hlkhllhhhh

Is there a way to initiate HDR/panorama or focus merge from the command line?

Recommended Posts

I would like to write a shell script that takes all files from a folder and starts an HDR merge with these pictures. This would save me a lot of of time compare d to having yo click through the menu for each merge. Is this possible or is there anther way to automate Affinity? this is on the Mac.

Share this post


Link to post
Share on other sites

There is no command line interface provided for the Affinity apps, & no scripting support other than the very limited support for macros in Affinity Photo.


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites
7 hours ago, R C-R said:

There is no command line interface provided for the Affinity apps, & no scripting support other than the very limited support for macros in Affinity Photo.

Disappointing.

Share this post


Link to post
Share on other sites
54 minutes ago, hlkhllhhhh said:

Disappointing.

The developers have said they may consider adding support for a scripting language or some sort of SDK in the future, but there has been no indication of if or when that might happen.


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites
1 hour ago, R C-R said:

The developers have said they may consider adding support for a scripting language or some sort of SDK in the future, but there has been no indication of if or when that might happen.

At least they should add some command line options so we can write scripts. That's not exactly difficult to do.

I will probably get Photomatix for HDR because it can do batch processing.

Share this post


Link to post
Share on other sites
1 minute ago, hlkhllhhhh said:

At least they should add some command line options so we can write scripts. That's not exactly difficult to do.

How do you know if that would be easy or hard to do? I don't know as much as I would like about such things but I do know that in an object oriented API it can be difficult & quite time consuming to work out all the inherences & dependencies that a non-trivial scripting language would require.


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites
47 minutes ago, R C-R said:

How do you know if that would be easy or hard to do? I don't know as much as I would like about such things but I do know that in an object oriented API it can be difficult & quite time consuming to work out all the inherences & dependencies that a non-trivial scripting language would require.

I have done software development for a long time and adding command line options like "-hdrmerge <file1> ....<filen>" is not difficult. The result would be exactly the same as pressing "OK" in the HDR merge dialog. Trust me, that's not hard to do.

Share this post


Link to post
Share on other sites
9 minutes ago, hlkhllhhhh said:

I have done software development for a long time and adding command line options like "-hdrmerge <file1> ....<filen>" is not difficult. The result would be exactly the same as pressing "OK" in the HDR merge dialog

Sure, as long as everything is set up exactly the same as when pressing the "OK" button in the GUI.

11 minutes ago, hlkhllhhhh said:

Trust me, that's not hard to do.

No offense intended but I prefer to trust a number of people I know in the software development business who say differently, including one that has been doing this since before OOP was a thing.


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites
2 minutes ago, R C-R said:

 

No offense intended but I prefer to trust a number of people I know in the software development business who say differently, including one that has been doing this since before OOP was a thing.

I am not sure what this has to do with OOP but us debating here doesn't help anything.

However, even if adding command line options is incredibly difficult it still would provide a lot of value and allow better integration of Affinity with other tools like Capture One.

Share this post


Link to post
Share on other sites

Out of curiosity, what CLI's do you work with in which items like <file1> are not treated as objects with inheritable properties that can be passed to other processes though API's?


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites

Basically it shouldn't be a big deal to add support for some cmdline arguments here, no matter if used in an OOP or procedural language context. Though it's always easier to overall handle this, if it has been already taken into account during the initial modeling and design phase of a software. However since the Affinity tools are frontend/backend oriented built up and also do use the common Win/MacOS programming APIs, they can add those things also on demand.


☛ Affinity Designer 1.7.3 ◆ Affinity Photo 1.7.3 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites
2 hours ago, R C-R said:

Out of curiosity, what CLI's do you work with in which items like <file1> are not treated as objects with inheritable properties that can be passed to other processes though API's?

I think something is getting confused here. To most CLIs parameters are just a bunch of strings. I don't know any CLIs that deal with objects ohter than PowerShell maybe.

Share this post


Link to post
Share on other sites
2 hours ago, v_kyr said:

Basically it shouldn't be a big deal to add support for some cmdline arguments here, no matter if used in an OOP or procedural language context.

OK, but which ones would those be? It seems to me that there are a lot assumptions being made about the backend code of the Affinity apps without any real knowledge of what it contains, which Mac or Windows API's it uses, which are high level or low level, how much initialization or error handling they require, & so on.


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites

I think he maybe thought more about the internal file representation inside an OO system and the mapping/association through an scripting API, instead of plain application argument calls. However even in OO file objects, their attributes and methods are mostly just finally encapsulated wrappers of more lower level file system call handles. - The same applies also to PowerShell here, which offers a powerful query language around these things.


☛ Affinity Designer 1.7.3 ◆ Affinity Photo 1.7.3 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites
9 minutes ago, R C-R said:

OK, but which ones would those be? It seems to me that there are a lot assumptions being made about the backend code of the Affinity apps without any real knowledge of what it contains, which Mac or Windows API's it uses, which are high level or low level, how much initialization or error handling they require, & so on.

Unless Affinity does something really unusual you can get a pretty good idea how it works because most apps follow the same few design patterns. A lot of them are dictated by the way the OS works. I doubt Affinity is any different. I think you are way overthinking this.

Share this post


Link to post
Share on other sites
4 minutes ago, hlkhllhhhh said:

Unless Affinity does something really unusual you can get a pretty good idea how it works because most apps follow the same few design patterns.

So what "few patterns" would those be? I am not asking for a "pretty good idea," whatever that is supposed to mean, but for something concrete one would expect a real world SDK to include. And not to overstate the obvious, but the Mac & Windows OS's are considerably different in many respects, from their windowing interfaces to their security models.


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites
3 minutes ago, R C-R said:

OK, but which ones would those be? It seems to me that there are a lot assumptions being made about the backend code of the Affinity apps without any real knowledge of what it contains, which Mac or Windows API's it uses, which are high level or low level, how much initialization or error handling they require, & so on.

For such common things like activating the same operation as a UI panel does via an cmd line argument instead I don't need to know anythink about those backends etc. here. The infrastructure is already there for either platform.

The overall handling is the following, just look and think about what happens underneath any Affinity panel (like open or save a file etc.) when you use and/or fill out the coresponding fields and settings (toggles etc.) of any dialog here. Some toggles, buttons, fields, controls etc. will return a bool state or give some numeric or string value back here when pressing a Ok button, those values all in turn are then used as arguments for a certain function/method call which performs the associated operation(s). And now think about passing over some CLI arguments here instead of using an UI panel for performing those same function/method calls.


☛ Affinity Designer 1.7.3 ◆ Affinity Photo 1.7.3 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites
3 minutes ago, v_kyr said:

For such common things like activating the same operation as a UI panel does via an cmd line argument instead I don't need to know anythink about those backends etc. here. The infrastructure is already there for either platform.

The overall handling is the following, just look and think about what happens underneath any Affinity panel (like open or save a file etc.) when you use and/or fill out the coresponding fields and settings (toggles etc.) of any dialog here. Some toggles, buttons, fields, controls etc. will return a bool state or give some numeric or string value back here when pressing a Ok button, those values all in turn are then used as arguments for a certain function/method call which performs the associated operation(s). And now think about passing over some CLI arguments here instead of using an UI panel for performing those same function/method calls.

Couldn't have said it better.

Share this post


Link to post
Share on other sites
22 minutes ago, R C-R said:

So what "few patterns" would those be? I am not asking for a "pretty good idea," whatever that is supposed to mean, but for something concrete one would expect a real world SDK to include. And not to overstate the obvious, but the Mac & Windows OS's are considerably different in many respects, from their windowing interfaces to their security models.

With patterns he means design patterns and there a lot of these for common tasks and in order to solve common design and implementation problems. The Win OS and MacOS APIs also make use of a lot of well known patterns here, be it creational patterns, structural patterns or beavioral patterns. Commonly used patterns in UI related systems and APIs are for example here Observer, State, Visitor, Mediator, Memento...  other structural ones which you will find a lot inside the APIs are Facade, Decorator, Composite, Adapter, Bridge... and so on. I suggest you take a look into some literature about these things, a good reading is the "Gang of Four" book from Gamma et all here.

Related to the OS differences, the software is already ported as is a bunch of other software like the whole Adobe suite and certain other software tools here too. So that's no argument at all, especially not for something simple like access of some functions through a CLI interface.


☛ Affinity Designer 1.7.3 ◆ Affinity Photo 1.7.3 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites
4 hours ago, v_kyr said:

The overall handling is the following, just look and think about what happens underneath any Affinity panel (like open or save a file etc.) when you use and/or fill out the coresponding fields and settings (toggles etc.) of any dialog here.

Think about what it would take to duplicate in a CLI something as simple to do in the GUI as moving a layer to a different position in the Layer panel. To begin with, since there may be more than one document open, you have to specify which document you are targeting, using whatever internal reference the app uses for that. You can't assume that would be by document name, since there could be several unsaved documents open. Likewise, you would also have to specify which layer in the document you are targeting, which may or may not have been assigned a name, & which position in the layer stack you want it moved to, which could be a deeply nested child layer position of some parent layer. Every one of these things would have to be specified unambiguously, & if passed as simple arguments of some 'layermove' command line statement, in the specific order that command expects.

 

There is no way to know if what you seem to be calling the "infrastructure" for this is present in the app, or how much work it would take to implement it if it is not. There would also have to be some kind of 'sanity checks' built into the app's CLI to make sure the command syntax is correct, that every reference exists at the time the command is executed, that each of them is of the appropriate type, that there are no other pending operations that would interfere with the execution of the command, & so on.

 

Frankly, I would be very surprised if support for any of this is currently present in the app. Why should it be? A GUI inherently provides what a CLI cannot, that being an unambiguous context for everything it allows a user to do.


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites
2 hours ago, R C-R said:

Think about what it would take to duplicate in a CLI something as simple to do in the GUI as moving a layer to a different position in the Layer panel. To begin with, since there may be more than one document open, you have to specify which document you are targeting, using whatever internal reference the app uses for that. You can't assume that would be by document name, since there could be several unsaved documents open...

I think you are somehow mixing up things here, what has that command line invocation of a HDR merge for batch processing to do with already opened documents or the like here? This is more "either or" functionality, either you use the GUI for the HDR merge or you use the apps command line to invoke the operation. For CLI you would specify the command to perform and the files to use by using appropriate command line flags/args.

What you describe instead is more something a scripting API and thus some mapped scripting language script would have to deal with, aka accessing, moving, possitioning layers and objects of certain actual open files etc.

2 hours ago, R C-R said:

There is no way to know if what you seem to be calling the "infrastructure" for this is present in the app, or how much work it would take to implement it if it is not. There would also have to be some kind of 'sanity checks' built into the app's CLI to make sure the command syntax is correct, that every reference exists at the time the command is executed, that each of them is of the appropriate type, that there are no other pending operations that would interfere with the execution of the command, & so on.

I've progged things like that a lot in apps so I know it's not a big thing at all to offer CLI access here for certain functions. You just have to recognize and check the passed over CLI arguments, if passed over file paths do exist, files can be opened etc. That's something the GUI has to do too and there are already API functions/methods for this one only reuse!

Quote

Frankly, I would be very surprised if support for any of this is currently present in the app. Why should it be? A GUI inherently provides what a CLI cannot, that being an unambiguous context for everything it allows a user to do.

Automation, batch processing, why clicking through a RAM eating GUI when you can simply initiate certain actions quickly from the command line or place them into some bash scripts etc.


☛ Affinity Designer 1.7.3 ◆ Affinity Photo 1.7.3 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites
13 minutes ago, v_kyr said:

Automation, batch processing, why clicking through a RAM eating GUI when you can simply initiate certain actions quickly from the command line or place them into some bash scripts etc.

Heh, I rather think devs have not supplied CLI or scripting because for most paying customers CLI or scripts are NOT simple or quick, but most alien things in the world.

Share this post


Link to post
Share on other sites
30 minutes ago, v_kyr said:

This is more "either or" functionality, either you use the GUI for the HDR merge or you use the apps command line to invoke the operation. For CLI you would specify the command to perform and the files to use by using appropriate command line flags/args.

What makes you think there is any support at all for CLI commands or for handling flags or arguments (appropriate or not) built into the Affinity apps? All I am hearing is that you have programmed apps to support those things, but it still sounds like you are just guessing about the presence of anything remotely like that in the Affinity ones.

 

This is not about anything as vaguely defined as identifying "design patterns." It is about what actually exists in the code & how it could be accessed from the command line. Have you searched through the code & found anything that even suggests it includes any command strings, perhaps in some encoded or tokenized form, or a command line interpreter, or anything else you would expect to find in an app that offered a CLI?

 

1 hour ago, v_kyr said:

What you describe instead is more something a scripting API and thus some mapped scripting language script would have to deal with, aka accessing, moving, possitioning layers and objects of certain actual open files etc.

On the contrary, it is something any viable interface must deal with! No interface can access something that isn't there & it must not leave anything in an undefined or unstable state, regardless of what it can or can't access. This is just as important for a CLI as for a scripting API.


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites

Sadly most people don't know that the real power of any operating system lies down in such CLI based app and process interactions. It's the essential thing any OS and many apps rely on here, even if it might not be obvious to the majority of users. The GUIs placed on top of this base functionality (Desktops, file browsers etc. etc.) are just another visual interaction method for the more plain mortals here, those users who fear or have no clues about what realy happens under beneath the surface.

If you would start to develop an OS or App etc. you usually don't start with the interaction layers, first of all you would think about how to handle and then start to define and implement the data model you want to work with. You will want to decouple that from the UI and later just build up a loose coupling here, so you are able to port those base things and can also adapt other UIs to your data models. - So in short there is no magic about all those development things here, it's instead more learned and used programming techniques.

1 hour ago, Fixx said:

Heh, I rather think devs have not supplied CLI or scripting because for most paying customers CLI or scripts are NOT simple or quick, but most alien things in the world.

So why are they (the customers) then asking for these things (macros, scripts, plugins etc.) all the time? - These would offer much more capabilities in terms of performing certain common or custom repetetive tasks, instead of clicking through the same panels hundred times again and again. Further there are also not just rookies among the user base, there are also power users or people who want to be able to have the freedom to define their own processing chains here for altering bulk media (photos) and the like.

 


☛ Affinity Designer 1.7.3 ◆ Affinity Photo 1.7.3 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites
1 hour ago, Fixx said:

Heh, I rather think devs have not supplied CLI or scripting because for most paying customers CLI or scripts are NOT simple or quick, but most alien things in the world.

I don't think that is the reason but regardless of that, the developers have flat out said there is no support for a CLI or a scripting language currently built into the Affinity apps. They did say they might consider adding support for a scripting language at some point in the future, but AFAIK there has never been any mention of supporting a CLI.


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.