annotation coordinates do not respect log scaling

[eisenlohr]

When adding annotations to a plot that uses log scaling, the annotation coordinates need to be rescaled to represent the log10 of the actual coordinates. While this is documented behavior, it is rather counterintuitive and should be fixed.
Seemingly no other axis-types (date, for instance) needs special treatment but works without modifying the underlying data.

Minimum example demonstrating the point, i.e. label_y is 4 but plotted at 10^4:

df = pd.DataFrame(data={'x':[1,2,3,4],
                        'y':[1,4,9,16],
                        })

fig = px.line(df,
              x='x',
              y='y',
              log_y=True,
              log_x=True,
              )

annotations = []
fig.for_each_trace(
    lambda trace: annotations.append(dict(x=np.log10(np.sqrt(trace.x[0]*trace.x[-1])),
                                          y=np.sqrt(trace.y[0]*trace.y[-1]),
                                          text=f'({np.sqrt(trace.x[0]*trace.x[-1])},{np.sqrt(trace.y[0]*trace.y[-1])})',))
)

fig.update_layout(annotations=annotations,
                  width=300,
                  height=300,
                  )
fig.show()

[nicolaskruchten]

I agree that this is a pretty bad aspect of our API. Specifying layout.(x|y)axis.range on log axes works the same way.

Unfortunately, we will not be able to change this without a major version bump to both Plotly.py and Plotly.js, as it would likely break many people's code in the wild. The best we can do in the short term is to add a flag to the layout (default False, so folks would have to opt in) that would enable us to accept coordinates directly.

[eisenlohr]

I would certainly support the addition of a (hidden) flag to remedy this. Additionally, I am confused what you mean by "works the same way". Specifying the range in the px.line command uses direct coordinates, not log10 of those:

x = np.arange(4)+1
df = pd.DataFrame(data={'x':x,'y':x**2,'z':x**3,})

fig = px.line(df,
              x='x',
              y=['y','z'],
              log_y=True,
              log_x=True,
              range_y=[1,100],
              range_x=[1,5],
              )
fig.show()

[nicolaskruchten]

Indeed, Plotly Express hides this ugly detail in its wrapper API, Under the hood it does the conversion when it sets the attribute:

plotly.py/packages/python/plotly/plotly/express/_core.py

Line 473 in d191458

if log_key in args and args[log_key]:

[eisenlohr]

I see. Nevertheless, my suggestion (maybe for plotly 5?) would be to have fully transparent handling of coordinates irrespective of whether a log or linear scale is chosen. That is, any coordinate—such as data values, ranges, annotation/label coordinates—is always given in the same "natural" way. So if the data points are (1,1) and (10,10), the expectation would be to state an axis range of, for instance, [1,10] (as is presently done), as well as annotation coordinates of (1,1) (not log(1)!). (Please see #2581 for an issue that prevents clickable annotation when using a log axis.)

I would propose to have the transformation from any "natural" coordinates to their logarithm be done very deep down in the plotting framework, i.e. right before drawing/calculating screen coordinates, and not at the very top where it is easy to introduce inconsistencies...

[nicolaskruchten]

Yep, I agree :)

[maegul]

This seems to also wreak some havoc with with figure.add_hline() function and the use of the annotation_position="top left" argument (and similar), as for plotly version 5.4.0 it doesn't seem to take account of the log axis type.

I found myself needing to make the following adjustment:

(
   fig
    .add_hline(
        y=line_value, 
        annotation_text=f'This is an annotation',
        annotation_position='top left',
        # This is the adjustment --V
        annotation_y=np.log10(line_value)
    )
)

[kb-]

I can't believe this bug is still there after 3 years😭
(version '5.17.0')

[eisenlohr]

I have not followed this trail for a while, but the idea mentioned above (use "natural" coordinates and only translate to chosen axis-scaling late in the game) seems to not have made it into the code...

[gvwilson]

Hi - we are trying to tidy up the stale issues and PRs in Plotly's public repositories so that we can focus on things that are still important to our community. Since this one has been sitting for a while, I'm going to close it; if it is still a concern, please add a comment letting us know what recent version of our software you've checked it with so that I can reopen it and add it to our backlog. Alternatively, if it's a request for tech support, please post in our community forum. Thank you - @gvwilson

[eisenlohr]

The exact same problem as originally posted June 20, 2020, still occurs with plotly.js v2.27.0. Hence, all subsequent comments in above thread appear to be valid concerns to address.

[gvwilson]

Thank you - I'll reopen and add to our backlog.