From ripley at stats.ox.ac.uk  Sun May 25 10:10:56 2008
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Sun, 25 May 2008 09:10:56 +0100 (BST)
Subject: [Rd] Macintosh Transperancy (PR#11511)
In-Reply-To: <F4370BF3-B89B-411C-8597-7FF58408D0F2@r-project.org>
References: <20080524145531.00EDD282EFF7@mail.pubhealth.ku.dk>
	<185EB21F-D9B8-41B8-828A-C9C1587771AC@r-project.org>
	<A7E95559-3D02-4FA8-AFBB-C2D21F97A47F@gmail.com>
	<F4370BF3-B89B-411C-8597-7FF58408D0F2@r-project.org>
Message-ID: <alpine.LFD.1.10.0805250708140.9980@gannet.stats.ox.ac.uk>

Bradley -- please learn the difference between 'transparent' and 
'semi-transparent'/'translucent'.  Your statements only begin to make 
sense for partially opaque colours.  Furthermore, there was a bug in the 
handling of (fully) transparent colours for these pch's what has been 
fixed in R-patched.

Also, the FAQ does ask you to make a bug report _only_ if you 'know for 
certain' what should happen, and here you are saying you would like to be 
able to do something different.  (It also discusses how to make 'wishlist' 
proposals, but you did not follow that and such proposals need to be 
unambiguously documented.)  You had better also 'know for certain' what 
does actually happen with current R versions.

There are several ways to handle semi-transparency, and Paul Murrell and I 
have debated which is the correct one to use.  In the case of pch=21:25 
where there may be two semi-transparent colours to paint, it is pretty 
clear that sensible people expect the two colours to be painted separately 
(they need not even have the same opacity).  If you don't want the border 
to be painted, make it transparent (and use R-patched or later).

Where the issue is less clear-cut is in pch=16 or 19, where the disc does 
have a stroked border of the same colour.  There devices do differ.
So if I do

plot(1, type="n")
points(1,1,pch=16, cex=10, lwd=3, col="#00ffff30")

on pdf() I get a disc of uniform colour and AFAIR on all other devices 
which support transparency give a darker border.  The point being that if 
we paint a fill and then a border in the same semi-transparent colour, 
should the overlap be painted once or twice?  I've not yet convinced Paul 
that we should take a position on what should happen here (and the use of 
anti-aliasing on lines or even fills means that what actually happens on 
some devices is more complicated still--and more complicated again on 
monitors such as mine which have hardware sharpening).

However, if you care you can use pch=21 with a transparent 'col' to 
achieve a uniform disc on all devices.


On Sat, 24 May 2008, Simon Urbanek wrote:

> Bradley,
>
> On May 24, 2008, at 9:07 PM, Bradley Vance wrote:
>
>> 	The bug is that the point that's being plotted is a single point, not 
>> a combination of two points, one that's just the outline, and one that's 
>> just the fill.  It also doesn't look like we'd expect when you're debugging 
>> a plot.  For example, let's say I create a plot, and notice that I can't 
>> see some of the points (due to other points being drawn on top of them). 
>> So I decide to make them transparent, so you can see where points over-lay 
>> each other, and the relative size/colors/etc of the over-layed points. 
>> Now, rather than just changing the opacity of the points/colors I see, I'm 
>> adding in another color to each point where outline and background meet, 
>> making the plot more confusing than it needs to be...
>> 	In looking at the documentation for bg in points (plot says to look 
>> at points for bg) it says
>> bgbackground (fill) color for the open plot symbols given by pch=21:25.
>> and the way it is now, the color is not a fill (ie - inside the lines) - 
>> it's super-imposed over part of the line.
>
> I think you're still missing the point - it is the fill. I suspect you're 
> misunderstanding the effect of using semi-transparent strokes. Moreover I get 
> *exactly* the same result using X11 (both Mac *and* Linux) as well as other 
> devices (PDF etc.). If you see anything else then *that* is a bug.
>
> A point is represented by a shape (path) which is filled and then drawn (line 
> stroke). As I was trying to explain earlier the effect is that half of the 
> line is in the filled area. Imagine a rectangle (0,0)-(1,1). When you fill 
> it, you're filling strictly the area between 0 and 1 (in both x and y). 
> However, when you strike let's say the line (0,0)-(1,0) with the width 0.25, 
> you are filling the area (0,-0.25)-(1,+0.25) which means that half the line 
> is outside (y<0) the filled are and another half is inside (y>=0). Given the 
> alpha-blending mechanics [target=alpha*color + (1-alpha)*old] it implies that 
> if the fill color is different from the background color and the line is not 
> opaque, you get different color outside and inside the rectangle. You can 
> verify that this is true for all devices that support alpha blending. This is 
> how it works and is supposed to be, that's not a bug.
>
>
>> 	Also, there's the fact that it does something different on different 
>> systems.  When I do the same thing at work on a Linux box (we don't have 
>> R.2.7 yet, we use mostly R2.4 but I've tried it on R2.6,
>
> Well, 2.6 didn't have alpha support in X11 AFAIR, so I have no idea what you 
> are trying to compare there ...
>
>
>> and we don't have Quartz, but I did output to PDF), it looks like a single 
>> point whose colors were made transparent, and not a point made of two 
>> overlapping transparent parts.
>> 	As I implied in my original ticket, I'd like to be able to choose 
>> whether to have it look the way it does now on the mac, and the way it does 
>> on Linux.  This might actually be something that needs to be addressed 
>> further by the core team, as that opacity is planning to be added for X11() 
>> for the next revision (and hopefully, will work into PNG and other device 
>> types that can support it)...
>> 	Perhaps the best way to implement the options/choices/etc is to add a 
>> separate alpha/opacity/whatever options that would control the opacity of 
>> each object it plots.  Thus, if you define an opacity to either col or bg, 
>> it would work the way it does on the Mac (ie - the colors are opaque and 
>> can thus you can see the other point-color through the top one).  However, 
>> if you have a point-opacity defined, the entire point will get the opacity, 
>> the way it is currently done on Linux.
>> 	Or, you can just say that in order to get it look the way that it 
>> currently does on the mac, you need to plot each point twice, once with no 
>> bg, and once with no line...
>>
>> 	Also, I don't think this is a critical bug.  It's just something I 
>> noticed that behaves differently on what I have at work (Linux) and what I 
>> have at home (mac).  I'm impressed with R, and am thinking of getting more 
>> involved in the r-project community, so figured I'd start with something I 
>> noticed was different across platforms...

How about starting by reading the FAQ and finding out what contributions 
are welcome?

> Again, I think you are missing something - it behaves consistently on Linux 
> and Mac in the latest release and it's not a bug.
>
> Cheers,
> Simon
>
>
>
>> On May 24, 2008, at 6:17 PM, Simon Urbanek wrote:
>> 
>>> Brad,
>>> 
>>> can you, please, let us know what is the "bug" here? If you paint 
>>> semi-transparent line over the same filled shape (same vertices), clearly 
>>> half of the line will be inside and and half outside of the shape, so each 
>>> part will have a different color - that is the whole point of 
>>> semi-transparency. Therefore I fail to see any bug or unexpected behavior 
>>> here.
>>> 
>>> Cheers,
>>> Simon
>>> 
>>> 
>>> On May 24, 2008, at 10:55 AM, brdvance at gmail.com wrote:
>>> 
>>>> Full_Name: Brad Vance
>>>> Version: 2.7.0
>>>> OS: 10.5.2
>>>> Submission from: (NULL) (71.123.195.202)
>>>> 
>>>> 
>>>> Problem : When drawing transperant points with lines thick-lines(lwd>1) + 
>>>> fill
>>>> (pch=21-25), it looks like the line is transperantly overlayed over the 
>>>> fill,
>>>> making it look like 2-lines surround the fill (each a different color). 
>>>> I
>>>> actually think that this is a nice OPTIONAL way to draw the points (even 
>>>> as
>>>> default), but since I could not discover how to turn it off, I decided to 
>>>> issue
>>>> the ticket.  In this option can see on the default-quartz device as well 
>>>> as
>>>> PDF-device.
>>>> 
>>>> Solution : Have the entire point-object designed/drawn as if there is
>>>> no-transparency, then make the composite object transparent.   Optionally 
>>>> figure
>>>> out an option to determine whether to apply transperancy as a group (to 
>>>> the
>>>> entire object) or separately (as it is now).
>>>> 
>>>> Code :
>>>>> df <- data.frame(X=rnorm(50),Y=rnorm(50))
>>>>> plot(X~Y,data=df,pch=c(21,22,23,24,25),cex=5,col="#00FF0055",bg="#FF000055",lwd=6)
>>>> 
>>>> Thanks,
>>>> -Brad Vance
>>>> 
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>> 
>>>> 
>>> 
>> 
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595



[Rd] Macintosh Transperancy (PR#11511)
Prof Brian Ripley