change line opacity, leave markers opaque

[stklik]

Is it possible to add an opacity to the line-attribute?change the line opacity but not the marker opacity?
I found that I can set the opacity of the entire line including markers (opacity = .5) and the one of the marker (e.g. marker={"opacity":1}). However, it is seemingly impossible to reduce the opacity of just the line.

As shown in this example:

import plotly
import plotly.graph_objs as go
plotly.offline.init_notebook_mode(connected=True)  # I'm running in a jupyter notebook

x = np.arange(0,10)
ys = [np.random.rand(10) for _ in range(3)]

lines = []
for y in ys:
    line = go.Scatter(x=x, y=y, mode="markers+lines", opacity=.5, marker={'symbol': 'x', 'size': "15", "opacity":1},
        line={'opacity': 0.5}
    )
    lines.append(line)           
fig = go.Figure(
    data=lines,
    layout=go.Layout(showlegend=True)
)
plotly.offline.iplot(fig)

See result here:

My problem is the following: My data points are important, the lines are just visual aid. I want to make the lines .5-opaque but have the markers fully opaque.
However, when I set opacity=.5, marker={'opacity':1} the opacity of the marker is also reduced. (I believe that the marker-opacity is defined in the range [0, line-opacity].

PS: If there is an existing solution/workaround for this issue, it might be interesting to (also) answer on my post on Stackoverflow

[etpinard]

Is it possible to add an opacity to the line-attribute?change the line opacity but not the marker opacity?

You can set line.color to an rgba value like in this codepen: https://codepen.io/etpinard/pen/QxbNBO?editors=0010

[stklik]

You can set line.color to an rgba value
Thanks for your suggestion.

I saw that possibility, but it requires to manually set the color of the line as well, rather than letting plotly do the coloring.
In my project I'm changing the list of default colours provided by the Colors component, in order to avoid manually setting the colour in every plot I create.
(I therefore asked for an ''official'' solution)

[alexcjohnson]

I saw that possibility, but it requires to manually set the color of the line as well, rather than letting plotly do the coloring.

Seems like a reasonable use case... I wouldn't be opposed to adding that.

In my project I'm changing the list of default colours provided by the Colors component, in order to avoid manually setting the colour in every plot I create.

Have you seen layout.colorway that does exactly that? #2156 It's still part of each figure then, but it can be a constant for every plot, and then it doesn't require you to have a custom build.

[stklik]

Seems like a reasonable use case... I wouldn't be opposed to adding that.

awesome.

Have you seen layout.colorway that does exactly that? #2156 It's still part of each figure then, but it can be a constant for every plot, and then it doesn't require you to have a custom build.

I had not seen it, but it's exactly what I was looking for. you just made my crooked DIY solution obsolete, thanks!

[hidai]

I have the same use-case.
Any plan to address the original issue (adding line.opacity)?

[corymosiman12]

+1

[JanghyunJK]

+2

[raffg]

+3

My use case is the bottom right chart here https://covid-19-raffg.herokuapp.com/

Workaround is this:

def hex_to_rgba(h, alpha):
    '''
    converts color value in hex format to rgba format with alpha transparency
    '''
    return tuple([int(h.lstrip('#')[i:i+2], 16) for i in (0, 2, 4)] + [alpha])


import pandas as pd
import plotly
import plotly.graph_objects as go
trace_data = pd.DataFrame({'base': [0, 1, 2, 3, 4],
                           'trace1': [1, 2, 3, 4, 5],
                           'trace2': [1.5, 1.9, 2, 3.9, 6],
                           'trace3': [2, 1, 3.3, 4.4, 4.5],
                           'trace4': [0, 3, 2, 1, 3]})

trace_colors = plotly.colors.qualitative.D3
color_idx = 0

fig = go.Figure()
for trace in ['trace1', 'trace2', 'trace3', 'trace4']:
    marker_size = [0] * (len(trace_data) - 1)
    marker_size.append(6)
    color = trace_colors[color_idx % len(trace_colors)]
    marker_color = 'rgba' + str(hex_to_rgba(color, 1))
    line_color = 'rgba' + str(hex_to_rgba(color, .25))
    # Perform a lot of data wrangling in Pandas here...
    fig.add_trace(go.Scatter(x=trace_data['base'],
                             y=trace_data[trace],
                             mode='lines+markers',
                             marker=dict(color=marker_color,
                                         size=marker_size),
                             line=dict(color=line_color, width=1),
                             name=trace))
    color_idx += 1
fig.show()

[JPvRiel]

+4

While experimenting with the histogram and attempting to add lines in overlay bar mode from the seaborn mpg sample dataset, i.e.:

mpg = sns.load_dataset('mpg')
fig = px.histogram(mpg, x='mpg', color='origin', barmode='overlay', opacity=0.33, marginal='box')
fig.update_traces(marker_line_width=2)

The default isn't great as the opacity applies to the default of black lines, meanwhile, notice that the default behaviour for the marginal box plot does exactly what most users would aim at - same color lines as the filled object. So my view is that it's quite inconsistent from a theme perspective to not be able to match this with the lines for the bar plot.

I attempted a similar workaround to @raffg , but seems that with the histogram, the alpha channel set for line color is ignored and overridden by the opacity value regardless.

def col_hex_to_to_rgba(rgb_hex: str, alpha: float=1.0) -> tuple[int, int, int, float]:
    return tuple([int(rgb_hex.lstrip('#')[i:i+2], 16) for i in (0, 2, 4)] + [alpha])

fig = px.histogram(mpg, x='mpg', color='origin', barmode='overlay', opacity=0.33, marginal='box')
for trace in fig.data:
    # Copy marker colour in hex string format (without alpha channel) and convert it to and RGBA string (adding the alpha channel)
    trace.marker.line.color = f'rgba{col_hex_to_to_rgba(rgb_hex=trace.marker.color, alpha=1.0)}'
    trace.marker.line.width = 2
fig

Disappointingly the lines only become visible when the colors/edges overlap. This also suggests that the graphic renders the lines outwards in way that overlaps, which is not ideal. For a histogram plot, line thickness rendered inwards would be better I think, such that the color blending from neighboring bar lines don't affect each other.

Also, checked that data of the figure traces, and indeed, alpha for the lines is being ignored. It was set correctly, e.g. content of fig.data[0]

Histogram({
    'alignmentgroup': 'True',
    'bingroup': 'x',
    'hovertemplate': 'origin=usa<br>mpg=%{x}<br>count=%{y}<extra></extra>',
    'legendgroup': 'usa',
    'marker': {'color': '#636efa',
               'line': {'color': 'rgba(99, 110, 250, 1.0)', 'width': 2},
               'opacity': 0.33,
               'pattern': {'shape': ''}},
    'name': 'usa',
    'offsetgroup': 'usa',
    'orientation': 'v',
    'showlegend': True,
    'x': array([18., 15., 18., ..., 32., 28., 31.]),
    'xaxis': 'x',
    'yaxis': 'y'
})

[JPvRiel]

I've found this seems to be an issue for scatter-plots as well, and the above mentioned work-around using the alpha channel with RGBA does not work. opacity at the parent marker level seems to override any alpha value set for the marker line color.

E.g. when trying to create a bubble chart with transparent fill and solid lines:

import plotly.express as px

df_gap_2007 = px.data.gapminder().query('year == 2007')
fig = px.scatter(df_gap_2007, y='lifeExp', x='gdpPercap',
    size='pop', size_max=50,
    opacity=0.25, color='continent',
    hover_name='country', hover_data=['lifeExp', 'gdpPercap', 'pop']
)
for trace in fig.data:
    trace.marker.line.color = 'rgba(0, 0, 0, 1.0)'
    trace.marker.line.width = 2
fig.show()

Resulting plot does not have solid black lines as would be expected with 'rgba(0, 0, 0, 1.0)':

Again, the marker part within fig.data[0]:

    'line': {'color': 'rgba(0, 0, 0, 1.0)', 'width': 2},
    'opacity': 0.25,

[gvwilson]

Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson