On 2008-01-16 22:47-0500 Hazen Babcock wrote:
> On Jan 16, 2008, at 9:14 PM, Alan W. Irwin wrote:
>> [...] OTOH, it is mostly just a big red blob with some minor transparency
>> effects
>> so perhaps something is not working quite correctly for the second page
>> for
>> the png device. [...]
>
> It looks like this driver scales alpha values in a different way than the
> cairo drivers.
Hazen, could you comment the second page code of example 30? I am having
trouble following exactly what it is supposed to do. From the looks of your
pngcairo results, it appears your second page code imposes a large red
square on top of variously coloured small squares or a black background
between the squares. The transparency of the large red square appears to be
opaque at the top and transparent at the bottom.
If that characterization of the expected code results is correct, then both
the png and pngcairo results fit that characterization, but the pngcairo
results have a linear variation of transparency with vertical position,
while the png results seem to be non-linear with vertical position but with an
identical transparency range, i.e., it is mostly opaque until it abruptly
gets transparent near the bottom below the last row of squares.
To show in more detail what I mean by that description, here are the results
of measuring the colour of the transparent red on black background at the
top, middle, and bottom of the image results from -dev png and -dev
pngcairo:
png pngcairo
top #FF0000 #FF0000
middle #F60000 #7B0000
bottom #000000 #000000
7B in hex just barely misses #7F (i.e., blending equal amounts of black and
red). Probably that is because I misplaced the colour probe icon
(KDE colour chooser probe) slightly from the exact middle of the image.
OTOH, #F6 corresponds to something very far from 50 per cent transparency
and actually is quite close to corresponding with complete opaqueness.
Andrew (Ross), do you confirm the above qualitative problem with the png
result?
It is strange the result seems to be non-linear. The libgd documentation I
can find as part of the Debian testing package for libgd refers to
gdAlphaTransparent = 127 corresponding to complete transparency (background
image shines through completely) and gdAlphaOpaque = 0 corresponding to
completely opaque with gdAlphaTransparent/2 being 50 per cent transparent,
consistent with a linear correspondence between the transparency index and
the transparency result. But that is nowhere near the actual results I
measure above in the -dev png image.
I tried -dev gif and -dev jpeg as well. -dev gif has complete opaqueness
(page 2 is just a giant red square) while -dev jpeg mimics the apparent
non-linear results of -dev png pretty closely. I cannot explain why libgd
does not seem to transmit transparency information to the gif output, but
since the -dev png and -dev jpeg results have a similar (non-linear)
transparency result, I don't think it is a problem with libgd's
misinterpretation of alpha index meanings for libjpeg and libpng (unless the
same misinterpretation is made for both libraries).
Anyhow, Andrew, the apparent non-linear transformation between transparency
index (alpha channel) and transparency result for both jpeg and png results
from libgd is a mystery which I hope you will be able to solve.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
