On Fri, Jan 18, 2008 at 09:44:43AM +0000, Andrew Ross wrote: > On Thu, Jan 17, 2008 at 07:20:29PM -0800, Alan Irwin wrote: > > On 2008-01-17 19:27-0000 Andrew Ross wrote: > > > > >> [...]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). > > > > >> [...]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. > > > > Hi Andrew: > > > > As you know I don't have access to cairo at the moment. However, you do. > > How does the first page of example 30 compare for transparency between png > > and pngcairo? My impression is the png version looks okay. If it happens > > that pngcairo has the same transparency interpretation as png for the first > > page, but not the second, that might be an important clue about where the > > trouble lies. > > By eye page 1 looks fine, but page 2 for png shows the problem you > describe. To me this suggests it is something to do with the cmap1 > palette. This is also why I didn't notice any problems when I first > implemented the changes to the gd driver.
To follow up my own response - it is not a fundamental libgd problem. I have a simple test case (attached) which does what I would expect. To compile this use "gcc test_alpha.c -lgd -o test_alpha". I can't currently see how this differs from what happens in the gd driver. I have found the cause of the dark lines though (at least for the gd driver). If two plotted polygons overlap, as happens in this case, then you get a contribution to the colour from both of them. This results in the border being a darker shade of red than the interior of the polygon. This could be tricky to fix. 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
