Affinity Photo - Create an animated gif

[oscarlosan]

4 hours ago, R C-R said:

There is much more to it than just 'refactoring the code.' Serif's older software ran only on Windows; the Affinity software has to run on 3 different platforms (Windows, macOS, & iPadOS), using a single native file format for all 3 apps on all of them, & so on. Affinity doesn't even use the same rendering method as any of the Plus apps or the same kind of memory management.

In fact, they share little in common besides coming from the same company.

all of us who had draw plus know that it works under windows. 
Some Adobe applications also changed the rendering engine in some of its versions and it was still called Illustrator and Photoshop. 
Serif wouldn't have gotten where it is without the Draw plus code. In 5 years it is impossible to do that. 
Those who have not had Draw plus install it and see what I say (uncommon hahahaha). 
We already know that it now works for 2 more platforms, it puts it on its website (we know how to read). Well let's leave the news from Wikipedia. 
Let's focus, can you add an animation panel or something else to make animations?: Yes, if Serif decides they want to add it. 
And then they will review the code that they already have implemented in Draw plus, and they will adapt-modify it for the languages and paradigms they use. Sure developers could not be copy and paste.
Note that I am not criticizing the company, it seems very intelligent not to have to reinvent the wheel. I use your software daily.

 

[R C-R]

4 minutes ago, oscarlosan said:

And then they will review the code that they already have implemented in Draw plus, and they will adapt-modify it for the languages and paradigms they use.

Again, it is nowhere near that simple because the code base is entirely different. IOW, there is no way to adapt or modify the Plus code; it would have to be completely written from scratch, just as they did with the Affinity apps to begin with.

[oscarlosan]

10 minutes ago, R C-R said:

Again, it is nowhere near that simple because the code base is entirely different. IOW, there is no way to adapt or modify the Plus code; it would have to be completely written from scratch, just as they did with the Affinity apps to begin with.

Photoshop made much more drastic changes in terms of technology, code, interface and it was an evolution. Just don't change the name.
You could say that the current version has nothing to do with it, but it is still Photoshop and they were adapting their code. Of course you have to do it gentlemen analysts and developers. You don't want forum users to do it, many spend hours submitting bug reports.
 

[oscarlosan]

before adobe xd was inside photoshop and then they decided to put it in another application. It was free, no.

They reused some of their code: yes. They had to adapt it: of course they did.

[oscarlosan]

I'm not saying it's simple I know. There are features that come over the years. No hurry.

[oscarlosan]

without the draw plus base that they have been working on since the 90s or so, it would be impossible to have built affinity. The same as adobe that they have been working on since a few years before. They could not have had the versions that they currently have.

[R C-R]

4 minutes ago, oscarlosan said:

I'm not saying it's simple I know. There are features that come over the years. No hurry.

But you are saying it is just a matter of reviewing the Draw Plus code & somehow adapt & modify it to run on the Affinity apps. Considering that the DP code won't even run on anything besides Windows at the very least means generating entirely new code to do that, not just adapting or modifying the existing DP code.

[R C-R]

1 minute ago, oscarlosan said:

without the draw plus base that they have been working on since the 90s or so, it would be impossible to have built affinity.

Actually, if you research the history of how Affinity began, you will learn that it did not build on any existing code base. The intent was to start from scratch, among other things to be able to use more efficient modern frameworks & cross-platform capabilities that the old legacy Plus app code could not.

But regardless, they have made it clear that they are not currently interested in developing any animation features for Affinity, so there is no point for me in continuing this "what if" discussion any further.

[oscarlosan]

6 minutes ago, R C-R said:

But you are saying it is just a matter of reviewing the Draw Plus code & somehow adapt & modify it to run on the Affinity apps. Considering that the DP code won't even run on anything besides Windows at the very least means generating entirely new code to do that, not just adapting or modifying the existing DP code.

Of course, they will have to adapt it and write it in the appropriate language. Also improving it, removing centralized stuff, using proprietary framework libraries that your current core obviously uses, among other things... it's not free. Don't loop, leave it.

[R C-R]

8 minutes ago, oscarlosan said:

Don't loop, leave it.

Leave what? There is nothing in DP that Affinity can use. If you understand what it means to create a new suite of apps entirely from scratch, then you should know that. Just changing the coding language won't do it because Affinity can't even understand how the old code works, much less adapt it to a radically different code base.

[oscarlosan]

11 hours ago, R C-R said:

Leave what? There is nothing in DP that Affinity can use. If you understand what it means to create a new suite of apps entirely from scratch, then you should know that. Just changing the coding language won't do it because Affinity can't even understand how the old code works, much less adapt it to a radically different code base.

It is the same application made from scratch. In fact, 90% of the new features (not all) are already in Draw plus. And the new ones that come will be AutoTrace, and others that are already in draw plus. But it's okay drawplus was very good. If anyone doesn't believe me, download drawplus and you'll feel at home. Thanks for defending that they have done it since 0. Don't bother man (from now on I will no longer name DrawPlus). Versions of Illustrator and Photoshop changed engine and code and had to be made from scratch, but they needed the same developers to make the change. There must be a reason. I leave it there.

I also say that they are making a great effort.

[R C-R]

5 hours ago, oscarlosan said:

It is the same application made from scratch.

Nonsense! It is not at all the same app. Among other things, DP code can't run on Macs or iPads, doesn't use MipMaps for rendering, & uses an entirely different type of memory management because unlike Affinity it must load the entire file into memory.

Simply put, just because two apps have some of the same capabilities does not make them the same app, nor make it possible to reuse or adapt the same code used in one in the other.

[oscarlosan]

7 hours ago, R C-R said:

Nonsense! It is not at all the same app. Among other things, DP code can't run on Macs or iPads, doesn't use MipMaps for rendering, & uses an entirely different type of memory management because unlike Affinity it must load the entire file into memory.

Simply put, just because two apps have some of the same capabilities does not make them the same app, nor make it possible to reuse or adapt the same code used in one in the other.

Photoshop 1 and Photoshop 2023 are not the same application. In addition, there is also photoshop for ipad. Therefore you are in a similar situation photoshop for macOS, windows and ipad. Photoshop did not change the name. You do. But don't be offended, Serif workers. Adobe does too.

 

[R C-R]

36 minutes ago, oscarlosan said:

I have already explained that to you, with several examples.

No, in post after post you have simply ignored the fact that the code bases for DP & Affinity are completely different so there is no way to "adapt" or "refactor" the code of one to use with the other. They are functionally similar in a few respects but "under the hood" they are as different as night & day.

You even claimed that DP & AD are the same app "made from scratch," which they clearly are not. A number of users have tried to explain all this to you, but you still don't seem to get it.

[Barry Newman]

Don't confuse code reuse with algorithm reuse and reuse of concepts behind how software is used and what it offers, R C-R. Just look at styles and pressure graph in DrawPlus and Designer. Exact same thing. Well, not interested in that debate:

I didn't work much with animation - is GIF really still used for animations on webpages?? 

[R C-R]

5 minutes ago, Barry Newman said:

Don't confuse code reuse with algorithm reuse and reuse of concepts behind how software is used and what it offers, R C-R.

Don't confuse algorithms & concepts with the code that has to be written to implement it. So while you can say that some feature of one app that can run on one platform is conceptually the same as one that you would like to run 3 different ones, that does not mean the code from the former can be adapted to be used in the latter.

[v_kyr]

1 hour ago, R C-R said:

that does not mean the code from the former can be adapted to be used in the latter.

That's either meant different and wrong expressed, or your understanding of the words "code" and "adapt" is somehow different and a pretty strange one here! 

And to be honest, I always have a good laugh here when people who have absolute no experiences and clues (...so really don't know nothing...) about programming and software development still do debate stubborn about such themes. - My advice would be: don't engage in endless and fruitless discussions unless you are a real expert on the subject and know what you are talking about!

[v_kyr]

2 hours ago, Barry Newman said:

is GIF really still used for animations on webpages?

Partly, though lately I do see more WEBP based animations instead, as those are probably overall more compact and faster to transfer.

[v_kyr]

Once Affinity will have & support scripting it should be pretty easy to generate animated GIFs. - Personally I use mostly Python scripting for such tasks.

Here's a short example with a drawn blue circle moving repeatedly from top left to bottom right ...

from PIL import Image, ImageDraw

def ellipse(x, y, offset):
    image = Image.new("RGB", (400, 400), "yellow")
    draw = ImageDraw.Draw(image)
    draw.ellipse((x, y, x+offset, y+offset), fill="blue")
    return image


def make_animated_gif():
    frames = []
    x = 0
    y = 0
    offset = 50
    for number in range(20):
        frames.append(ellipse(x, y, offset))
        x += 35
        y += 35
        
    frame_one = frames[0]
    frame_one.save("anim_circle.gif", format="GIF", append_images=frames,
                   save_all=True, duration=100, loop=0)
    

if __name__ == "__main__":
    make_animated_gif()

 

Of course we can do the same with a bunch of let's say via the Export Persona exported image files instead, then we would let the script instead read the image files from some folder and let it generate out of those the animation. No need to ask, of course we could also adapt the order of the images, the animation speed ... etc. to our needs then.

[R C-R]

31 minutes ago, v_kyr said:

That's either meant different and wrong expressed, or your understanding of the words "code" and "adapt" is somehow different and a pretty strange one here! 

OK, then how would you adapt code written to run only on Windows to run on Windows, macOS, & iPadOS, or for that matter to adapt code based on a time sequence in one app to run on another app that has nothing like that built into it? What about memory use differences, & the rest of it?

[v_kyr]

4 hours ago, R C-R said:

OK, then how would you adapt code written to run only on Windows to run on Windows, macOS, & iPadOS, or for that matter to adapt code based on a time sequence in one app to run on another app that has nothing like that built into it?

As the word adapt already implies here, if you use one and the same programming language here (let's say C/C++ as in the case of DP & ADe), you just port/change only the routines (aka lib and other code sections) which do differ platform specific wise, as some of the OS path & filesystem I/O related routines and certain UI related stuff, the rest which depends on standard language libs is everywhere available. Further for many I/O and memory related routines there are äquivalent routines for all common platforms. - Keep in mind that major programming languages like C/C++ do follow their defined standardizations as do many accompanied libs for those, so things are available on/for all platforms here!  Other used things like certain algorithms & data structures can be always converted and written in any programming language, the OS and programming language doesn't play any role here!

To give you an idea of an software adaption flow ...

... I once (in former times) had a personal need for being able to reuse some english localized Adobe PS Actions (atn files) under PS versions as fully german localized actions and vice versa. So to offer and make available certain of my PS actions in peoples native language. Doing the whole manually the common way was always a tedious (idiotic & dull) very time consuming and hard work. So I once decided to better invest the time to write some assist tool for these purposes. - So I carefully studied the Adobe ATN file format and how it is overall defined and setup bytewise (done some code reverse engineering) and finally found a way how to change & manipulate the ATN byte file format for what I was specifically after.

- I wrote the first incarnation of that tool as a CLI tool in plain Java code, where the most complex part was to do all the bloody atn byte parsings and changings, even for very huge ATN files in a gracefull manner.

- Next after some time I thought, Ok let's make that stuff slightly more comfortable to use and make an Java UI-program out of all that, which then also allows to define & reuse own translation rules on demand. The result was a Java app which did run (thank's to Java) equally on all platforms (Win, Mac, Linux).

- After one or two years and a growing user base of my tool, I decided to give people also native versions of it, so they can run it without the need of installing a Java Runtime Environment. I first wrote a Win version in C#, as that (C#) is pretty much a nobrainer for someone who already knows Java very well. I also afterwards wrote a plain C/C++ version in order to compare processing speeds between Java/C#/C++ versions.  -- I had to recode all UI-stuff here as I didn't used a portable platform UI library like QT or the like. Also I had to adapt my I/O, byte parsing and generation routines, meaning using instead equivalent (doing the same) C# and C/C++ code functions/methods to what I've used in Java here before.

 

- Next I started building a native macOS app out of that tool, here I had the choice to use either C/C++/Objective-C or SWIFT and decide which language to use. Using C/C++/Objective-C would have been relative easy for me, as I have a good knowledge of all three of them and being a former times NeXT ObjC progger. And as I could have reused a bunch of the already available Win C/C++ code here. - But instead I decided then to recode the whole in Swift, as Swift was a pretty new thing at Apple and since I was more interested in doing some programming with that Swift language, in order to learn & see how programming with that will be instead. -- So I really rewrote (recoded) all of what I had code wise so far in Java/C#/C/C++ in Swift, by reusing Apple's Swift API instead of ObjC here. The only difficult to handle part in Swift was the conversion of the byte parsing and generation routines, as I wasn't much used to Swift based byte coding routines and syntax. Doing instead the macOS UI stuff with Swift was relative easy and fun here.

All in all one has to have just a fair knowledge of the choosen programming language, it's available API functions & libs and certain of the language specifics & idiosyncrasies.  Everything else is not much of a theme here, as there are a bunch of cross platform available frameworks & libraries for all sort of prog languages. - And Affinity software relys on a bunch of third party cross platforms here, which can be used on either systems (Win, Mac, Linux)!

[R C-R]

3 hours ago, v_kyr said:

All in all one has to have just a fair knowledge of the choosen programming language, it's available API functions & libs and certain of the language specifics & idiosyncrasies. 

But unlike DP, if Affinity does not have any builtin functions that can support any form of animation output, then how can you "adapt" any of those functions that exist in DP to AP, regardless of what programming language you are using?

[Alfred]

On 7/4/2023 at 3:52 PM, R C-R said:

Among other things, DP code can't run on Macs or iPads, doesn't use MipMaps for rendering, & uses an entirely different type of memory management because unlike Affinity it must load the entire file into memory.

I believe DrawPlus does actually use MipMaps for rendering, but the other differences  you mention are hugely important.

[v_kyr]

5 hours ago, R C-R said:

But unlike DP, if Affinity does not have any builtin functions that can support any form of animation output, then how can you "adapt" any of those functions that exist in DP to AP, regardless of what programming language you are using?

You take a closer look at those DP source code portions, the functions which perform the filling of an array (or some similar used data structure) with layer contents (or whatever DP used here to combine certain of it's drawing portions), the duration and order definitions etc. and convert/adapt that code over for ADe. Then you hook in (add) some UI interaction stuff to ADe which initiates and calls the generation of the combined gif.

[Barry Newman]

23 hours ago, R C-R said:

Don't confuse algorithms & concepts with the code that has to be written to implement it. So while you can say that some feature of one app that can run on one platform is conceptually the same as one that you would like to run 3 different ones, that does not mean the code from the former can be adapted to be used in the latter.

For professional reasons, I'll just have to disagree and leave this silly exchange of words.

Have a nice day.