Bug #1186

Preventing jitter in text positioning

Added by Viktor about 1 month ago. Updated 26 days ago.

Status:ClosedStart date:2018-01-21
Priority:NormalDue date:
Assignee:Paul% Done:


Target version:Candidate for next bugfix release
Affected version:all Platform:



I have run into an issue when using GMT to create animations.

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.

test.sh Magnifier - used to produce text_jitter example (282 Bytes) Viktor, 2018-01-21 13:38

text_jitter.m4v - text bounces around (34.8 KB) Viktor, 2018-01-21 13:39

surface_jitter.m4v - surfaces don't match projected coords (11.3 MB) Viktor, 2018-01-21 13:39

test06.jpg - 1 (23.6 KB) Viktor, 2018-01-21 16:21

test07.jpg - 2 (23.6 KB) Viktor, 2018-01-21 16:21

test08.jpg - 3 (23.6 KB) Viktor, 2018-01-21 16:21

test.sh Magnifier - now there is a consistent page size (307 Bytes) Viktor, 2018-01-21 16:21

bug_200.mp4 (1.04 MB) Paul, 2018-01-22 19:10

example.sh Magnifier - Example movie script for GMT 6 (713 Bytes) Paul, 2018-01-24 17:07

bug_W1.mp4 - Initial jittery movie (763 KB) Paul, 2018-01-24 17:07

bug_W8.mp4 - Jitter mitigated by 8x subpixel sampling (456 KB) Paul, 2018-01-24 17:08


#1 Updated by Paul about 1 month ago

  • Status changed from New to Resolved

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.

#2 Updated by Viktor about 1 month ago

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'm aware of what you mean but this is not the issue.

#3 Updated by Viktor about 1 month ago

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.

#4 Updated by Paul about 1 month ago

  • Status changed from Resolved to Feedback

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.

#5 Updated by Paul about 1 month ago

Hm, not so sure anymore. I also get a movie that looks too wiggly for my liking. Will report back once I have a better answer and solution.

#6 Updated by Paul about 1 month ago

  • Tracker changed from Feature to Bug
  • Subject changed from Preventing jitter in item positioning to Preventing jitter in text positioning
  • Status changed from Feedback to In Progress
  • Target version set to Candidate for next bugfix release
  • Affected version set to all

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).

#7 Updated by Viktor about 1 month ago

Edit: didn't refresh page and missed last 2 replies.

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.

#8 Updated by Paul about 1 month ago

More testing without any final answer:
  1. 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.
  2. 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.
  3. 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.

#9 Updated by Paul about 1 month ago

Forgot to attach the movie.

#10 Updated by Paul about 1 month ago

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

ls *.png > t.lis
while read file; do gm convert -resize 400x250 $file NEW_${file}; done < t.lis

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?

#11 Updated by Paul about 1 month ago

  • File example.shMagnifier added
  • File bug_W1.mp4 added
  • File bug_W8.mp4 added
  • Status changed from In Progress to Resolved
  • Assignee set to Paul
  • % Done changed from 0 to 100

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.

#12 Updated by Viktor about 1 month ago

Thanks for the help/updates/workaround.

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.

#13 Updated by Paul about 1 month ago

We are running 9.22 which seems OK. One advantage of movie.c is that it does it in parallel without you having to do anything specific.

#14 Updated by Paul 26 days ago

  • Status changed from Resolved to Closed

Closing this one as solved.

Also available in: Atom PDF