#2503 [5.5] Transparency of image lost in pdf output

[Eldrad Ulthran]

If a transparent palette is defined via colormap and used to colour an image, the QT and pngcairo output are correct, but in pdf output (pdfcairo, cairolatex) the image is fully opaque again. Attached are a screenshot of qt and the resulting pdf file.
Funnily enough, when using the same custom palette for a pm3d splot instead, the pdf output retains the correct transparency.

set xr [0:10]
set yr [0:1]
set urange [0:10]
set vrange [0:1]
set isosamples 2,100

set palette defined (0 "dark-violet", 1 "forest-green")
set cbr [4:6]
unset colorbox

set colormap new MYPALETTE
do for [i=1:|MYPALETTE|] {MYPALETTE[i] = MYPALETTE[i] + (int(0.5*0xff)<<24)}

set terminal cairolatex
set out "transparent_palette.tex"
plot '++' u 1:2:1 mask w image fc palette MYPALETTE not
unset out
unset term

[Ethan Merritt]

Thank you for the bug report. It turns out there are three overlapping issues here.

1) The simplest part to fix but the hardest to find was that filled areas emitted by the "with image" code were being treated as having fillstyle "default". Changing this internally to explicitly set the fillstyle to "solid" is by itself a minimal fix.

2) The reason that the bug is evident in pdf output but not in qt is that the "default" fillstyle is interpreted differently by different terminal drivers. Qt treats it the same as "solid". However the cairo terminals treated it separately and did not look for an alpha channel in this separate path. For the sake of consistency I have changed the cairo terminals to also treat the default as solid.

3) The test code given is not quite correct. It requires an additional keyword "pixels" in order to work as intended in a 2D plot, including set view map; splot ... with image. This is because when the image code sees a request to display what it identifies as a pure rectangular pixel array, it calls into a corresponding pixel dump routine in the current terminal's external graphics support library (qt cairo gdlib gtk ...) if there is one. But in general these do not handle an alpha channel, or at least gnuplot does not do the extra work to set one up. Instead gnuplot provides an additional keyword pixels that applies to plot styles with image, with rgbimage, and with rgbalpha. This mode tells the program to bypass any library-specific pixel array routines and draw each pixel in the array separately as a small rectangular filled area. This is where the actual bug hit, because this filled area was getting the "default" fill style, which was not necessarily "solid" and the cairo terminals only checked for an alpha channel value if the style was explicitly "solid".

Fixes for the generic image code and for the cairo terminals are in commit

dd12a0f9 Consistent support of alpha channel in "with image"

If you modify your actual scripts to use splot ... with image pixels they should now work in the development version with named palettes that contain an alpha channel value.

Version 5.4 does not yet support named palettes, but probably would benefit from the equivalent changes anyway in order to prevent future trip-ups.

[Ethan Merritt]

Unfortunately this has undesirable side effects on other plots (e.g. the heatmaps demo). Still open while I sort this out.

[Ethan Merritt]

OK. With further revision, the generic code now works for images with an alpha channel in the palette, doesn't break anything I can find (all demos run correctly), and has the unexpected side effect of reducing the size of image plots in PostScript output by about 10%. It is still possible that there is a problem affecting some terminal type I couldn't test (Windows?) but I'm marking this "pending-fixed".