Timelaple images are created but not collected into a `.gif` file

[alpetukhov]

Dear Bastian and coauthors,

Thank you for the comparison tool! Unfortunately, I've been having some problems with the timelapse feature in the latest (e7c0e1b) version of the tool. I've folowed the instructions in the Building the Docker container from scratch section of the README, got the osh.pbf file and successfully run the image generation in the make-images.ipynb notebook. All the images were generated, but there is no .gif file and the latest entry in the output of the last notebook cell is about the generation of the last image

Generating zoom 15 at time 2025-06-14T15:29:59Z
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Noto Sans Syriac Eastern Regular' in FontSet 'fontset-0'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Noto Sans Tibetan Regular' in FontSet 'fontset-0'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Noto Emoji Regular' in FontSet 'fontset-0'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Unifont Medium' in FontSet 'fontset-0'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'unifont Medium' in FontSet 'fontset-0'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Unifont Upper Medium' in FontSet 'fontset-0'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Noto Sans Syriac Eastern Regular' in FontSet 'fontset-1'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Noto Sans Tibetan Regular' in FontSet 'fontset-1'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Noto Emoji Regular' in FontSet 'fontset-1'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Unifont Medium' in FontSet 'fontset-1'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'unifont Medium' in FontSet 'fontset-1'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Unifont Upper Medium' in FontSet 'fontset-1'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Noto Sans Tibetan Bold' in FontSet 'fontset-2'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Noto Sans Syriac Eastern Regular' in FontSet 'fontset-2'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Noto Sans Tibetan Regular' in FontSet 'fontset-2'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Noto Emoji Regular' in FontSet 'fontset-2'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Unifont Medium' in FontSet 'fontset-2'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'unifont Medium' in FontSet 'fontset-2'
Mapnik LOG> 2025-06-21 09:10:18: warning: unable to find face-name 'Unifont Upper Medium' in FontSet 'fontset-2'

I've tried to restart the container several times and the results have been inconsistent: sometimes the .gif files is created, sometimes the generation is stuck at the last frame and sometimes it is even stuck somewhere in the middle.
Do you have any ideas what might be causing it or what may I've been doing wrong?

Thanks in advance,
Aleksandr

[gedankenstuecke]

Hey @alpetukhov,

thanks for reporting this, could you maybe share the full parameters you're using (bounding box, which osh.pbf, the number of frames you're trying to generate etc)? That way we could try to reproduce it on our ends and see if we can sort out what goes wrong.

Generally speaking, I've noticed that the script tends to run into problems when one tries to generate too big areas at too high a zoom level, but it's hard to know if this is the case here!

[alpetukhov]

Sure, here's the link to the page with the osh.pbf file and here's the resulting command

./make.sh external/central-fed-district-internal.osh.pbf 2025-05-30T00:00:00Z 2025-06-14T15:30:00Z 41.720753,53.403494,41.891384,53.482428 15 15 8

I guess this might be the case of a big aria with the zoom level too high.

[gedankenstuecke]

Yep, it's likely to be a matter of the area and zoom combined making too large an image. It doesn't work for me either, but if I create only 2 instead of the 8 snapshots you tried to create the resulting GIF already takes up 18 MB for me.

What you could do is take the 8 individual frames it creates and make a movie file out of it instead, that way the size would remain a lot smaller!

[alpetukhov]

I've tried a smaller area in the same file with zoom levels from 6 to 12 and it unfortunately still unable to make a GIF out of them. Here's the command

./make.sh external/central-fed-district-internal.osh.pbf 2025-06-14T00:00:00Z 2025-06-18T00:00:00Z 41.797314,53.464215,41.837568,53.476247 6 12 8

I don't think this is the problem with the frame sizes, since in this case the individual file size ranges from 100 bytes to 10 kilobytes.

[gedankenstuecke]

Could you try and see what happens if you make 2 instead of 8 frames?

[alpetukhov]

So I' tried every number of frames from 2 to 10 for the small example

./make.sh external/central-fed-district-internal.osh.pbf 2025-06-14T00:00:00Z 2025-06-18T00:00:00Z 41.797314,53.464215,41.837568,53.476247 6 12 FRAME_NUM

and both still and animated comparison images were created for every number of frames instead of 8.

Then I've tried my initial example with 10 frames and it worked for both still and animated images!

./make.sh external/central-fed-district-internal.osh.pbf 2025-05-30T00:00:00Z 2025-06-14T15:30:00Z 41.720753,53.403494,41.891384,53.482428 13 15 10

Seems like I was extremly unlucky to pick the exact number of frames that breaks the code for some reason. One one hand, my exact problem is solved, on the other hand what is so special with 8 frames?

[gedankenstuecke]

That's very strange, on top of my head I have no idea why that might be the case! @iandees as you implemented the GIF creation: would you have an idea what makes that number special? 😆

[iandees]

Can you share the whole output from the command, including your command that started it all? With such inconsistent results it sounds like you're running out of memory or disk space. But the output you shared in the initial report doesn't reflect anything going wrong.