On Wed, Jan 16, 2008 at 11:37:58PM -0800, Alan Irwin wrote: > > 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?
Alan, I can confirm that I observe exactly the same behaviour with both debian oldstable and ubuntu gutsy (latest stable). > 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. That was how I read it. I have tried some options to change the way transparency is handled, but to no avail. Using identify on the two files shows that the type is Palette for png as opposed to TrueColor for pngcairo. The gd driver should be using TrueColor (24 bit) for the images though. Not sure if this is the region. I will try and put together a simple test case to try this out. > 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). I read somewhere that libgd does not support transparency for gif files? This may be out of date though. > 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. I'm currently equally perplexed. Hopefully we can come up with a simple test case to try out some ideas. Andrew ------------------------------------------------------------------------- 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
