Jump to content
You must now use your email address to sign in [click for more info] ×

Still no javascripting or python support in Photo???


Recommended Posts

I may have missed it, but I didnt see anything in the announcements or new features.

 

Disappointed that I have to tell our team we have to still stay on the "other suite".

 

I'd then once again like to add it as a feature request please.

(macro recording doesnt cut it)

Please add scripting support in Affinity Photo, as in add support for javascript or python scripts so we can automate our tasks and workflows.

Link to comment
Share on other sites

Same here, using scripts is my day-to-day workflow using Adobe Illustrator. If there's no solution out of the box, you always could rely on third-party solutions (including plug-ins). 

If you need a case, let people know and we could create different showcases why it's so crucial and how it could help for the workflow. 

Edited by Athanasius Pernath
Link to comment
Share on other sites

  • Staff

Developer response here

 

Patrick Connor
Serif Europe Ltd

"There is nothing noble in being superior to your fellow man. True nobility lies in being superior to your previous self."  W. L. Sheldon

 

Link to comment
Share on other sites

5 minutes ago, Jose Alvarez said:

And is it possible to know which scripting language is THE CHOSEN (Python please, Python please, Python please... :) )?

+1 for Python (or javascript). Please no new proprietary "Affinity" or other weird scripting language. Stick to industry standards like Python (or javascript)

Link to comment
Share on other sites

Here we go again...

ECMAScript (JavaScript) and Python both stink (pathetic languages), but for bad or for worse, they did indicate on the LONG LONG LONG prior thread on this subject that they were most likely going with JavaScript.

As much as I dislike JavaScript, I might actually consider doing something with it if it boils down to it.  If they had gone with Python, it would more likely have been a dead feature out of the gates for me, so they went with the slightly less bad of two evils.

Link to comment
Share on other sites

  • Staff
2 hours ago, Jose Alvarez said:

And is it possible to know which scripting language is THE CHOSEN (Python please, Python please, Python please... :) )?

Ask the Dev in that thread. He may explain more what our plans are

Patrick Connor
Serif Europe Ltd

"There is nothing noble in being superior to your fellow man. True nobility lies in being superior to your previous self."  W. L. Sheldon

 

Link to comment
Share on other sites

COPY / PASTE from Scripting Forum, TonyB (Moderator):

Affinity will support Javascript and also have a 'C' based API binding interface that people can use to write plugins. We will also have the ability to create UI to support their scripts and plugins with dialogs and panels. 

We have a team developing this but the amount of work is very large so unfortunately users will need to be patient.

 

Crystal clear, mates.

Link to comment
Share on other sites

On 11/10/2022 at 5:02 AM, fde101 said:

Here we go again...

ECMAScript (JavaScript) and Python both stink (pathetic languages),

If they use a WASM engine then they can support all languages with high performance.  It would give Affinity an edge over the competition with a very modern engine.

Link to comment
Share on other sites

1 hour ago, CM0 said:

If they use a WASM engine then they can support all languages with high performance.  It would give Affinity an edge over the competition with a very modern engine.

Unless a program is originally conceived of and designed around having scripting, it's not really possible to add scripting, as the process becomes legion.

 

Hence how long it's taking.

 

If it is achieved, the performance of the scripting language is never going to be a problem, as each scripting invoked operation of the underlying program's operative abilities will take orders of magnitude longer than the house keeping and condition determinations of their issuance with even the worst binding of the worst performing scripting language given the lowest possible priority.

 

 

 

 

Link to comment
Share on other sites

37 minutes ago, deeds said:

Unless a program is originally conceived of and designed around having scripting, it's not really possible to add scripting, as the process becomes legion.

 

Hence how long it's taking.

 

If it is achieved, the performance of the scripting language is never going to be a problem, as each scripting invoked operation of the underlying program's operative abilities will take orders of magnitude longer than the house keeping and condition determinations of their issuance with even the worst binding of the worst performing scripting language given the lowest possible priority.

 

 

 

 

I've implemented scripting engines in applications.  Scripting is not greatly different than any other feature.  It will depend on how well existing API's are designed.  The pace of new features in general is probably more indicative of how long scripting will take as they all have to build on top of the existing API's.

Furthermore, we don't know how long it is taking, we don't know when the effort began.  It has been talked about from long ago, but we don't know when the effort commenced so hard to say it is taking long.

Performance is very important when doing image processing.  The engine and language can make orders of magnitude difference in performance.  Affinity has the opportunity here to do something not done before by the competition.  Which is to potentially have the live update capabilities extend to even scripting and plugins.  Interpreted languages are going to be very slow, but with a WASM engine you could write extremely efficient code in RUST for intensive operations while still allowing more process oriented scripting done by JavaScript or Python with the same engine.

Link to comment
Share on other sites

27 minutes ago, CM0 said:

I've implemented scripting engines in applications.  Scripting is not greatly different than any other feature.  It will depend on how well existing API's are designed.  The pace of new features in general is probably more indicative of how long scripting will take as they all have to build on top of the existing API's.

Furthermore, we don't know how long it is taking, we don't know when the effort began.  It has been talked about from long ago, but we don't know when the effort commenced so hard to say it is taking long.

Performance is very important when doing image processing.  The engine and language can make orders of magnitude difference in performance.  Affinity has the opportunity here to do something not done before by the competition.  Which is to potentially have the live update capabilities extend to even scripting and plugins.  Interpreted languages are going to be very slow, but with a WASM engine you could write extremely efficient code in RUST for intensive operations while still allowing more process oriented scripting done by JavaScript or Python with the same engine.

You must be young.

The speed of the language, for a scripting "engine" (whatever that means to you) is not the issue. It can only, and will only ever, invoke commands/functions/methods/operations of the host program. As such, the scripting "engine" will perform those operations thousands of times faster than you can with a mouse and keyboard, even if it's Python. 

 

But the binding, the hooks into the commands, in a manner that's safe, documentable, portable and integrated with the software... that's holistic stuff that's gotta be started from inception. Otherwise it won't happen.

 

How much would you like to bet that we never see a fully integrated scripting language facility within Affinity products? By that, I mean to the capacity that scripting can be used in 3ds Max as an objective, the manner in which it can be done in After Effects as a baseline, the way it can be done in Reaper as an ideal.

Link to comment
Share on other sites

44 minutes ago, deeds said:

You must be young.

The speed of the language, for a scripting "engine" (whatever that means to you) is not the issue. It can only, and will only ever, invoke commands/functions/methods/operations of the host program. As such, the scripting "engine" will perform those operations thousands of times faster than you can with a mouse and keyboard, even if it's Python. 

 

But the binding, the hooks into the commands, in a manner that's safe, documentable, portable and integrated with the software... that's holistic stuff that's gotta be started from inception. Otherwise it won't happen.

 

How much would you like to bet that we never see a fully integrated scripting language facility within Affinity products? By that, I mean to the capacity that scripting can be used in 3ds Max as an objective, the manner in which it can be done in After Effects as a baseline, the way it can be done in Reaper as an ideal.

Yes, so young that I started development writing machine code on a C64 :-) 

Your take on performance is on procedure oriented scripts and yes what you describe for procedure oriented scripts is true.  However, if you want to write a filter that has to crunch through a ton of data, then the engine performance is highly important.  So, yes scripting as a way to do more advanced macros it really doesn't matter.  However, as a means to provide an interface to build extensions/plugins to do more advanced image manipulation it would matter.  Nonetheless, even side stepping any performance use cases WASM would still provide for a language agnostic engine.

I have no idea how successful they will be.  It seems they are mostly playing catchup now instead of innovating and leading.  So from that standpoint I'm not optimistic, only hopeful they will surprise me.

Link to comment
Share on other sites

1 hour ago, CM0 said:

Yes, so young that I started development writing machine code on a C64 🙂 

Your take on performance is on procedure oriented scripts and yes what you describe for procedure oriented scripts is true.  However, if you want to write a filter that has to crunch through a ton of data, then the engine performance is highly important.  So, yes scripting as a way to do more advanced macros it really doesn't matter.  However, as a means to provide an interface to build extensions/plugins to do more advanced image manipulation it would matter.  Nonetheless, even side stepping any performance use cases WASM would still provide for a language agnostic engine.

I have no idea how successful they will be.  It seems they are mostly playing catchup now instead of innovating and leading.  So from that standpoint I'm not optimistic, only hopeful they will surprise me.

Oh... you're younger. I grew up with the earlier batch of 6502's and Assembly.

 

On the matter of the ability to make plugins for Affinity products... not going to happen. That takes even more forethought than providing a scripting language. 

 

 

Link to comment
Share on other sites

Plugins already working - Adobe 8bf format supported and in fact works pretty well, with selections and stuff (used filter forge with v1 - worked like a charm). So you can already write/compile anything you want.

Scripting definitely is not a replacement for plugins, speed is not important, the deepness of API is the key. UI stuff is cool but secondary thing too, imho.

Really hoping there will be possibility to work with curves and brushes at low level - add/edit/sample splines/nodes, peek into layers content, draw strokes with specific brush/settings, etc

Link to comment
Share on other sites

On 11/12/2022 at 4:04 AM, CM0 said:

If they use a WASM engine then they can support all languages with high performance.  It would give Affinity an edge over the competition with a very modern engine.

Quite true. But I can understand why a WASM engine will not be their first effort, it is still a little of a cutting edge for something that will be an internally support feature for an obviously fairly stressed team. Hopefully the C API will enable external developers to provide some features. I hope that once the scripting and API is finally shipped (I understand it is a big rewrite of the app internal architecture, and I was not expecting it before v2), we will see some gradual expansion of the API in future versions too. 

Link to comment
Share on other sites

8 hours ago, David Cake said:

Quite true. But I can understand why a WASM engine will not be their first effort, it is still a little of a cutting edge for something that will be an internally support feature for an obviously fairly stressed team. ...

I don't disagree.  However, Affinity originally positioned itself as something different with cutting edge performance.  It feels like Affinity has had to fall back to playing catch up instead of innovating.  If they could pull off something like WASM integration, I think it would pay future dividends by bringing in a much larger ecosystem of integrations.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | 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.