PNG render does not zoom correctly

[jblang]

From Gary.Swo...@gmail.com on August 04, 2009 20:37:10

What steps will reproduce the problem? 1. Make a recording and create a continuous zoom in one direction, without any stops in the middle. I've included a XAF file I created for this.

2. Render the recording to PNGs. Optionally you can create a video from the PNGs, it makes it easier to see the problem. What is the expected output? What do you see instead? When playing back the recording in XaoS it works fine. But in the PNG render there are numerous "backward zooms" that last about three frames. This causes random jerky movements in the resulting video. In the docs it mentions there may be missing frames if subsequent PNGs are the same (like if you pause a zoom and there is no panning). But in my recording there are no frames that look alike, so there are no missing frames in the middle of the recording.

If you have a image viewer like gthumb or ristretto you can step through the PNGs and see the errant zooms frame by frame. In my included recording the first backward zoom happens around frame 80. What version of the product are you using? On what operating system? Version 3.4, on Ubuntu Jaunty (32 bit). Please provide any additional information below. Every recording I have made with XaoS has this problem. I've tried rendering from the GUI and the commandline, with different arguments and different fractals.

Attachment: anim1.xaf

Original issue: http://code.google.com/p/gnuxaos/issues/detail?id=34

[jblang]

From Gary.Swo...@gmail.com on August 04, 2009 18:53:39

A little more information - the first "backward" frame is number 84, as numbered by XaoS. It only goes for 1 frame, but it makes a relatively big jump compared to the normal frames. It does not get back to the zoom position frame 83 had until about frame 89.

[jblang]

Confirmed this on the latest code. Reattaching repro file as anim1.txt.

[jblang]

Stepping through the code, I found that it was executing this command on line 64 of the file is when the jump backward at frame 84 occurs:

(animateview -0.278147583 -0.742341942 6.27343881E-05 6.27343881E-05)

I confirmed that this was the cause by commenting out the line in the file, and confirming that the jump backward no longer occurs. The animateview function resets the view to a specific location, and these commands are periodically in the file. My theory is that the frame timer for the rendering engine is slightly faster than the timer for the real-time display, and that the zoom gets slightly ahead of where it is expected to be, so that when the animateview function is called, it resets the view back where it was a few frames prior.

I haven't investigated yet what triggers the recording code to place one of these animateview commands. It may just do so periodically.

[kovzol]

I confirm this. An example is attached (for the record). I used ffmpeg -pattern_type glob -r 30 -f image2 -s 640x480 -i 'anim*.png' -shortest -vcodec libx264 -crf 25 -pix_fmt yuv420p -acodec copy anim.mp4 to create the .mp4 file. sierpcarpet.xaf.txt anim.mp4.zip

[combs]

I am a new user to XaoS and am experiencing this too in XaoS 4.2.1 (linux x86_64) on Ubuntu 20.04.

[combs]

I can confirm @jblang's 2019 hypothesis that the (animateview) commands cause this. They are unnecessary. Post-processing the .xaf files like this makes them renderable:

grep -v animateview BROKEN.xaf > FIXED.xaf

Perhaps this issue from 2009 has a simple fix.

[CLandel89]

Can confirm this, but:

Even with grep -v ..., the output skips frames and flies around. The mouse was moving around during recording. After second 20, the output is clearly different from the recorded sequence.

Original sequence:

anim0.xaf.zip

Rendered with (animateview) commands removed:

https://user-images.githubusercontent.com/1664262/235371234-fd6c261c-34b6-474e-9704-fd24f7ff3941.mp4

My system:

# uname -a
Linux **** 5.15.0-71-generic #78-Ubuntu SMP Tue Apr 18 **:**:** UTC 2023 x86_64 x86_64 x86_64 GNU/Linux