Bug #1209

grdimage: -Q is faulty with -t

Added by Viktor 14 days ago. Updated 10 days ago.

Status:ResolvedStart date:2018-03-05
Priority:NormalDue date:
Assignee:Paul% Done:


Target version:Candidate for next bugfix release
Affected version:6.x-svn Platform:


When adding a grid (grdimage): if -t is used, -Q will have no effect (small areas)? or produce something in-between.

Sample script produces the 2 attached images. Only difference is addition of '-t0' to 'test-t0.png', both have '-Q'.
Expected outcome:
  • both images look the same (they don't).
  • Areas invisible due to -Q remain so while the rest has a transparency as determined by -t.

-t0 is used only for illustration, a higher number than 0 was used/tested.
when grdimage is used with -A there doesn't seem to be any issues but -t seems to be ignored (perhaps on purpose).

land.nc - script resource (129 KB) Viktor, 2018-03-05 12:56

test.sh Magnifier - sample script (300 Bytes) Viktor, 2018-03-05 12:57

test-not.png - without -t parameter (as expected) (86.6 KB) Viktor, 2018-03-05 12:57

test-t0.png - with -t parameter (should have no effect)? (202 KB) Viktor, 2018-03-05 12:57

test543.ps - 5.4.3 (146 KB) Viktor, 2018-03-06 15:44

test6x.ps - r19820 (146 KB) Viktor, 2018-03-06 15:44


#1 Updated by Viktor 14 days ago

Just to add: sample script only produces 1 of the images, the other is produced by removing or adding -t0 to the first grdimage command.

#2 Updated by Paul 14 days ago

  • Status changed from New to Feedback

I dont think the Adobe transparency extension works this way. PostScript has no support for transparency but Adobe added some for PDF. We are using that as is. We have no control over how the transparency ensues other than via the PS_TRANSPARENCY settings. I think -t0 should simply print "that is the default". Unfortunately, it may have an effect since it sets transparency to true despite being zero. Will fix that part.

#3 Updated by Paul 14 days ago

  • Status changed from Feedback to In Progress

In r19888, -t0 will have no effect.

#4 Updated by Viktor 14 days ago

Is it possible to avoid the heavy jpeg-like artefacts when using -t?

#5 Updated by Paul 13 days ago

I dont think we have any control with that. I tried -t1 (since -t0 is not allow) and got big green squares. Also, grdimage -A does not consider -t. Maybe it should? Right now grdimage -Q -A sets the alpha channel to 0 (at NaNs) or 255. We could certainly change that depending on -t and we could set alpha to 0 at NaNs and 255*t/100 otherwise? Joaquim?

#6 Updated by Viktor 13 days ago

Must be a recent change because the images look fine when using GMT 5.4.3. Only on 6.x-svn broken output is produced with -t used.

Not sure -t0 should be an error. Maybe someone would do -t$transparency_var and now would have to check if $transparency_var == 0 and then run one command or another (with or without -t) based on that result.

for t in {99..0}; do
  gmt grdimage input.grd -t$t >> fadein_sequence_$i.ps 

Error -t: Transparency must be in (0-100]% range!
Perhaps a warning because the result of using 0 should have no effect.
It's like -t100 being an error. The command could just be ignored in most cases.

#7 Updated by Paul 13 days ago

OK, mind posting the two PS files since you are looking at this?

#8 Updated by Viktor 13 days ago

gmt pscoast -JOA172.5/-43.5/90/6i -R170.5/-44.15/174.05/-42.95r -Df -Slightblue -Gdarkgreen -K > test.ps
gmt grdimage -J -R -O -Q -t20 -Crainbow land.nc >> test.ps

#9 Updated by Viktor 13 days ago

The diff is quite short but I've found out running psconvert from 5.4.3 on the 6.x-svn output produces good results.

#10 Updated by Paul 13 days ago

Thanks, we will investigate.

#11 Updated by Paul 12 days ago

BTW, -t0 is no longer an error. You get a warning and it proceeds without transparency.

#12 Updated by Paul 10 days ago

  • Status changed from In Progress to Resolved
  • Assignee set to Paul
  • Target version set to Candidate for next bugfix release
  • % Done changed from 0 to 100

Fixed in r19907. During the discussion with the jittery movie we were told by the GS people that we had lots of PDF settings that are ignored when building a png. But that is not true when there is transparency since we must first convert to PDF (to get the transparency) and only then convert to raster. In this case we want the PDF settings to apply even though the end result is a raster. We had changed that relatively recently. I now reset the gs parameters to PDF when we detect transparency in the PS. Your examples now work for me.

Also available in: Atom PDF