Text is bouncing around (text_jitter.m4v). It even moves up, down, up again between consecutive frames with uniform transitions.Surfaces visible in surface_jitter.m4v (centre, hot colour palette) which have points projected from geo coords to x,y have the same behaviour. The black outlines were produced under geo coords but the surfaces are in x,y space.

I'm not too sure if this can be fixed, a GMT issue or more to do with ghostscript.It moves by a pixel at a time.

History

It is because you are not controlling the page size, hence the PNGs have variable image size and hopeless to stitch together. Decide on a canvas size and use PS_MEDIA to specify that paper size and remove the -A from psconvert.GMT6 will add new module movie.c which I think you will find very helpful.

Sorry I forgot to mention anything about page size.Outside the example, I set the page size. In surface_jitter.m4v I set the page size to Custom_16ix9i and do not clip with psconvert.I think it is still clearly visible if you look at text_jitter.m4v or even go through the outputs in an image viewer as it is the jitter relative to the different characters, not the overall positioning.

I have removed the variable of page size.You can see between the images I have uploaded, the characters are individually dancing across the page.

Is there a way to make them move in unison?I think if the change in motion is in the same direction (as is the case between these increments), if a character moves up a pixel, down and then up again, then it is a bug.If the text is moving left and down between increments, then I expect the characters to move left, down or stay the same. I have found that not to be the case.

It seems graphical positioning can be sub-pixel and therefore is correct but text positioning isn't, the characters are treated individually and can actually bounce in the opposite direction of the way they are progressing.

When GMT sets up a projection it adjusts the view point. Since you are changing not only the projection latitude but the projection 3-D view elevation you need to have a fixed point. Currently you don't and the jittering you see is the adjustment made due to the changes. For a movie you will need to fix this. See anim03 for how we use modifiers to +p for this situation. This has nothing to do with text positioning being variable and everything to do with overall coordinate system; it gets reset for each frame in your case.

Promoting this to a bug report. Attached is a simple movie showing a changing viewpoint of a line and the text HELLO. The line moves smoothly while the text is jittery, just as the OP stated. I increased precision in writing the rotation matrix to PostScript but not effect (and none expected since same matrix works for the red line).

Exactly. I want to pan the map area (changing not only the projection latitude) while changing the view (projection 3-D view elevation and azimuth).I have looked at anim03 and determine that -p+... is used to fix the centre which is not what I want, it goes against the previous statement.

The positioning of geographical data works perfectly fine and therefore have no issues with my projection and perspective settings. surface_jitter.m4v shows that the coastlines, land etc.. all look fine, it's that projecting lon, lat to Cartesian, that when the view changes, these un-projected coords do not match the geographically plotted data.The issue is that, as the map pans, the characters of text and some lines move inconsistently. One character might move right, the others won't move until the next frame. This is what I mean by jumpy.

psconvert with a higher resolution seems to help with what seems to be rounding errors.

Writing just ELL instead of HELLO to avoid anything curved since flattenpath must replace curved paths with straight line segments. flattenpath depends on a flatness parameter. I set that as small as is allowed (0.2). None of this mattered, and with non-curved letters it seems to rule out flattenpath as a culprit.

Notice that individual letters jiggle differently despite being set as a word. So to me that suggest some internal ghostscript issue in setting individual letters.

I have run this movie from small to > 4k and they all jitter - no obvious trend to me. I will try posting to the ghostscript forum to see if the insiders have some knowledge.

We are checking with the ghostscript developers. Meanwhile, one suggestion from a poster that I tried was to select resolution some multiple higher than desired and then resize the images with graphicsmagick. So far this is a good workaround: Use a dpi 4 times what you want, then resize the large images back down. E.g., for a 1600x1000 images I tried

and then assemble the movie using the NEW frames. This smooths the jitter down to manageable levels (it is not completely removed but given pixelation it is acceptable). The higher the multiplier the better of course. 2 is not bad but it is only computer time so why not 4 or 8?

We have had some consultation with the GhostScript developers on this issue. When I mentioned our workaround of up/down scaling they pointed out that gs has an option for this (-dDownScaleFactor=<factor>). So I have implemented that in our movie application and it works great and remedies the problems we have discussed. Since you are making very nice animations it would be great if you were able to build GMT 6 from subversion and try out gmt movie. It requires that you write your script using modern mode (a GMT6 feature). The benefits will be obvious once you look at the script and run it. The movie.rst document explains the details. I attach an example script for doing a GMT 6 movie and the two animations resulting from passing -W8 or no -W.

I see I can run psconvert with '-C-dDownScaleFactor=<factor>' noting that the s in scale must be capital. If it's of any importance, I am using ghoscript 9.20 because 9.21 seemed to produce strange results, not sure which version you have.It seems about 33% slower for psconvert with a factor up/down of 4. Hoping this won't be too significant with thousands of frames.

I already use GMT from subversion because there isn't any release yet where Z scaling works with oblique Mercator after 5.1. I will have a look at movie but I found it hard to scale code so have already made a GMT wrapper in Python to help with the complexity prior to the official library.