Designer v2.4.2 windows 10: Why does exporting GIFs take way longer than exporting PNG, TIFF, JPEG ect?

[EEE]

Hi, I am currently writing my seminar thesis for my studies at university and for that I am experimenting a little bit with file sizes and formats. For that, I created a vector graphic with a color gradient and text.

I made copies with different sizes, ranging from 50x50px to 4000x4000px. Then I exported them all at once but as separate files using the export persona. When I exported them as PDF or SVG, the export worked extremely fast, as I was expecting for a vector-based image. However, JPEG and PNG also only took one or two seconds. TIFF took about 30 seconds, which I expected to be the slowest, but for the GIFs, I needed about 5 minutes and 40 seconds. When I repeated it, I got similar results.

Do you have an explanation for why there is such a big time difference? Is the algorithm behind the GIF compression simply less time-efficient? I'm looking forward to your answers.

 

SVG Example Immage 1000x1000px.svg

[walt.farrell]

Welcome to the Serif Affinity forums.

Are you exporting them to the same location, and where is that (local disk, USB disk, network, ...)?

For me, exporting just that 1000x1000 size as a GIF, using either File > Export or the Export Persona, takes about 5 seconds to a local disk on my laptop. That is slightly longer than PNG takes, but comparable.

[R C-R]

2 minutes ago, walt.farrell said:

For me, exporting just that 1000x1000 size as a GIF, using either File > Export or the Export Persona, takes about 5 seconds to a local disk on my laptop.

On my Mac, it took no more than 2 seconds to export it as a GIF to my desktop folder via File > Export.

[NotMyFault]

1 hour ago, EEE said:

Is the algorithm behind the GIF compression simply less time-efficient?

GIF are 256 indexed colors (or pallerized) all others are not. Creating the palette takes some time, but not several minutes 

[NotMyFault]

I see your export size is 1 larger in x direction, you should fix this before export 

[EEE]

On 5/11/2024 at 7:48 PM, walt.farrell said:

Welcome to the Serif Affinity forums.

Hi, thank you

 

On 5/11/2024 at 7:48 PM, walt.farrell said:

Are you exporting them to the same location, and where is that (local disk, USB disk, network, ...)?

I have exported them to separate folders on my local disc. But even when exported to the same folder there is the same difference in required time. I allso tested it on my work laptop and got the same results

 

On 5/11/2024 at 7:48 PM, walt.farrell said:

For me, exporting just that 1000x1000 size as a GIF, using either File > Export or the Export Persona, takes about 5 seconds to a local disk on my laptop. That is slightly longer than PNG takes, but comparable.

It happens for the bigger file sizes, like 4000x4000px, or when I export all the graphics as gifs at the same time. When I only export the 1000x1000 one it takes also only a few seconds. Actually I dont know why I only attatched the 1000x1000px version to my original post

 

 

 

AffinityFormatExperiment.afdesign AffinityFormatExperiment SVG 4000x4000.svg

[EEE]

On 5/11/2024 at 8:19 PM, NotMyFault said:

I see your export size is 1 larger in x direction, you should fix this before export 

Actually i dont understand how that happens. When I click on the graphic the transform window says it has 4000x4000px, aswell as the measure tool. But in the export option and affter the export the x direction has that extra pixel. When I change the Size in the export options it exports it with the correct size. When I change the size of the original square in the designer persona to 4000x3999px the export format is 4000x4000px

      

[NotMyFault]

Because the x position has fractional decimals. All objects need to be positioned to whole integers. This is a nasty story.

[Alfred]

2 minutes ago, NotMyFault said:

All objects need to bee positioned to whole integers. This is a nasty story.

A nasty story with a sting in the tail?

[NotMyFault]

To shorten the discussion: 

on iPad Pro 2018, all regular raster exports are fast, but all palettised exports are super slow (gif and PNG with palettised option).

The issue is that the method to create the actual palette seems super slow and probably linear or even over-linear to amount of pixels. Maybe influenced by available RAM (which is quite low on iPad).

 

edit: over linear means runtime is a function of pixel count which returns value above any linear runtime. For details, see

https://en.wikipedia.org/wiki/Time_complexity#Table_of_common_time_complexities
https://en.wikipedia.org/wiki/Big_O_notation

it is a definition from computer science about the runtime dependency on input (length). 

[Alfred]

1 minute ago, NotMyFault said:

The issue is that the method to create the actual palette seems super slow and probably linear or even over-linear to amount of pixels.

I don’t know what you mean by “linear” in the present context, and I’ve no idea what “over-linear” might mean in any context!

[NotMyFault]

It means that i did measure the export preview time:

1500x1500 takes 6 sec

2000x2000 takes 12 sec

2500x2500 takes 18 sec

this means iPad processes about 350.000 pixels per second, and export time is O(n) or linear proportional to number of pixels.

Most of the export time is to create the palette (the progress stays at 0%

Linear time complexity

 

[Affinity Rat]

So does this means that saving a tiff file in 8 bit, is slower than 32 bit, if 8 bit palettized and 32 bit not?

[Pšenda]

On 5/11/2024 at 6:21 PM, EEE said:

I am experimenting a little bit with file sizes and formats

Try also with/without HW Acceleration (in application preferences).

[NotMyFault]

35 minutes ago, Affinity Rat said:

So does this means that saving a tiff file in 8 bit, is slower than 32 bit, if 8 bit palettized and 32 bit not?

I would say yes, but just test it out. It depends on many factors, including the actual image content, e.g. images with solid colors may compress by enormes factors whereas random noise or complex gradients are often the worst case.

[Affinity Rat]

4 hours ago, NotMyFault said:

It means that i did measure the export preview time:

1500x1500 takes 6 sec

2000x2000 takes 12 sec

2500x2500 takes 18 sec

this means iPad processes about 350.000 pixels per second, and export time is O(n) or linear proportional to number of pixels.

Most of the export time is to create the palette (the progress stays at 0%

Linear time complexity

 

I too was unfamiliar with the term “Over-linear” your link on time complexity doesnt mention it. I searched google and found not much relevant to this context, but I’m interested, could you please expand on it.

By “over-linear” are you referring to an empirical approach vs theoretical? 

 

 

 

 

[NotMyFault]

Sorry my use of terms is a bit sloppy.

the linked article explicitly explains linear time O(n) and sublinear time below O(n).

similar, above linear or over-linear or supra-linear or super-linear time means any runtime above O(n).

For examples see O(n^2) or any table entry not belonging to sublinear or linear time.

 

to say it in other words in the context of image editor apps:

• linear time means taking a constant time per pixel or processing a constant number of pixels per second. This is mostly the case.
• sublinear means it gets faster with higher pixel numbers (this rarely happens, e.g. deleting a layer or file)
• above linear means it gets slower with higher pixel numbers. 

https://en.wiktionary.org/wiki/superlinear

[Affinity Rat]

So are you saying in mathematical terms this is an expression like (non-linear) ➗  linear,  hence over-linear?

 

[NotMyFault]

Over in the sense of larger, more, exceeding.

 

[Affinity Rat]

So the area of the graph over-linear is where non-linear/linear > 1.

[EEE]

11 hours ago, NotMyFault said:

Because the x position has fractional decimals. All objects need to be positioned to whole integers. This is a nasty story.

Uh thats quite interesting for my seminar thesis. And annoying. Now that I have repositioned the images it works and by activating the force pixel alignment i can prevent it from happening again

[EEE]

13 hours ago, Pšenda said:

Try also with/without HW Acceleration (in application preferences).

Good idea, I tried, but for the gif export it did not seem to affect the time it takes. In both cases it was more or less 5 minutes 40. Maybe I would get different results with more RAM, I only have 8GB

[EEE]

13 hours ago, NotMyFault said:

I would say yes, but just test it out. It depends on many factors, including the actual image content, e.g. images with solid colors may compress by enormes factors whereas random noise or complex gradients are often the worst case.

I tried the same 4000x4000px but with a solid colour instead of a gradient, it did not affect the export time I think. It was about 2min 14 export time without the gradient and

about the same with the gradient.

With the no gradient version I also tried exporting GIF greyscale with only grey scale and 2 colours. I think the result is quite interesting when zooming in and out

 

Edited May 14, 2024 by EEE
Changed image

[EEE]

51 minutes ago, EEE said:

With the no gradient version I also tried exporting GIF greyscale with only grey scale and 2 colours. I think the result is quite interesting when zooming in and out

Well when uploaded the image looks diferent than in my windows foto app. after downloading the image and viewing it in the app again, it looks the same as online. as it seems when uploading it the image gets compressed further when uploading it. Before the upload it was 1.192.523 Bytes and now it is 978.889 Bytes. It had a strong Moiré effect before I think

Edited May 14, 2024 by EEE

[NotMyFault]

7 hours ago, EEE said:

Well when uploaded the image looks diferent than in my windows foto app. after downloading the image and viewing it in the app again, it looks the same as online. as it seems when uploading it the image gets compressed further when uploading it. Before the upload it was 1.192.523 Bytes and now it is 978.889 Bytes. It had a strong Moiré effect before I think

All your good observations are to be expected.

• Different apps use different methods to zoom images, e.g. resample bilinear or nearest neighbor. Handling of color profiles is another issue / difference.
• moire is often the consequence when having fine patterns
• Affinity creates inferior palettes during export. E.g. a single colored image may get diffusion pattern of two colors instead of only one perfect matching color.
• the affinity forum software re-compresses jpg images. So either use png, specifically for screenshots (which uses lossless compression only) or zip jpg files before upload if fine details are relevant