[FEATURE]: Access values calculated / derived by plotly.js as part of plotting

[alexcjohnson]

Description

There are a lot of things that plotly.js has to calculate in the course of creating a plot from your data, and many of these would be useful for other purposes, either (1) to avoid repeating the calculation, (2) because there's some nuance about how the calculation should be done, or (3) because as a user you don't even have access to the information needed to do the calculation.

This is similar to full_figure_for_development, but that feature is intended (per the name) just for use during development in order to understand how plotly.js sets attribute defaults, and which attributes are available and meaningful in a particular situation. It should not be used in production because it's slow and the resulting object can be very large, and it only includes information from the "full" figure data and layout objects, which generally means it captures interactions between attributes but NOT values that are derived from data arrays. One exception is automatically-calculated axis ranges, which clearly depend on the data and ARE available from full_figure_for_development - but we'd love a more efficient (and more accurate, see below) way to get these as well.

The intent here is to allow users to retrieve calculated values that may be useful for other purposes in production situations, without all the overhead of full_figure_for_development. But I'm imagining the usage (and implementation) would be similar to full_figure_for_development, with the exception that that one is implemented via Kaleido only, whereas for this purpose at least if you've displayed your figure as a FigureWidget it should be possible to query the displayed figure directly rather than remaking it in Kaleido. This will ensure any calculations that depend on the display environment (for example the actual displayed size, if that's inherited from the container, and the exact fonts used by the browser) are properly reflected in the result.

Why should this feature be added?

Some examples of information to be included here:

• Axis ranges
• tick0 and dtick (or perhaps the list of precise tick values and associated text that we displayed?)
• Tick rotation angle
• Margins, so you can align neighboring elements with specific data positions or ensure multiple plots are properly aligned
• Box and violin plots: statistics shown on the plot: min, max, median, quartiles, standard deviation, fences, outliers (see discussion in [FEATURE]: Support for Method #7 (Pandas/NumPy default) in quartilemethod for Box and Violin plots #5550 re: the ambiguity of quartile values)
• Grouped plots (bar, histogram, box, violin): width and position offset for each trace
• Stacked plots (bar, histogram, scatter): final base & top for each trace (this could be large, as it'll be two values per data point, so may need to be opt-in?)
• Automatic colorscales: the min and max values

I'm sure there are many more. These values would also be useful to JavaScript users, and for their use perhaps we can either just put them into a new data structure we attach to the graph div, or new objects we attach to gd._fullLayout and each trace in gd._fullData, then they can access them directly, no need for a new method. For Python users though this requires a new method to retrieve this info from JS.

[ranjeet7980]

Proposed API Design: get_computed_values()

To make this feature request more actionable, I would like to propose a concrete API sketch that maintainers and contributors can respond to, refine, or push back on.

---

Basic Usage

computed = fig.get_computed_values()

With no arguments, this returns a structured dictionary of the most commonly needed computed values — axis ranges, tick values, margins — without anything large or trace-level that could be expensive.

---

Selective Retrieval via include

computed = fig.get_computed_values(
    include=["axis_ranges", "tick_values", "margins", "box_stats"]
)

A whitelist of keys the user explicitly wants. This keeps the default response lightweight while still giving power users access to more expensive or verbose outputs. Possible keys could include:

Key	What it returns
axis_ranges	Final rendered [min, max] for each axis
tick_values	Computed tick positions and display text per axis
tick_rotation	Final rotation angle per axis tick label
margins	Rendered t/b/l/r margins in pixels
box_stats	Min, max, median, Q1, Q3, fences, outliers per box/violin trace
bar_geometry	Width and offset per trace in grouped bar/histogram plots
stack_geometry	Base and top values per point per trace in stacked plots
colorscale_range	Computed [cmin, cmax] for auto colorscales
contour_levels	Computed contour level values when autocontour: true
histogram_bins	Computed bin edges and counts after nbinsx/nbinsy negotiation
legend_geometry	Rendered position and dimensions of the legend box

---

Trace Filtering via traces

computed = fig.get_computed_values(
    include=["box_stats", "bar_geometry"],
    traces=[0, 2]  # only retrieve for trace index 0 and 2
)

Some computed values are per-trace and potentially large. Allowing the user to scope to specific traces avoids returning unnecessary data when you only care about one or two traces in a large figure.

---

Example Return Structure

{
    "axis_ranges": {
        "xaxis": [-0.5, 10.5],
        "yaxis": [0.0, 87.3],
        "xaxis2": [0.0, 1.0]
    },
    "tick_values": {
        "xaxis": [
            {"value": 0.0, "text": "0"},
            {"value": 2.0, "text": "2"},
            {"value": 4.0, "text": "4"}
        ],
        "yaxis": [
            {"value": 0.0,  "text": "0"},
            {"value": 25.0, "text": "25"},
            {"value": 50.0, "text": "50"},
            {"value": 75.0, "text": "75"}
        ]
    },
    "margins": {
        "t": 60, "b": 80, "l": 72, "r": 20
    },
    "box_stats": {
        "trace_0": {
            "min": 1.2, "max": 98.6,
            "q1": 24.5, "median": 51.0, "q3": 76.2,
            "lower_fence": 5.0, "upper_fence": 95.0,
            "outliers": [0.3, 99.1, 101.4]
        }
    }
}

---

Two Backend Paths, One Interface

The same method signature should work regardless of the rendering environment, but the backend used to fulfill the request should differ:

• FigureWidget in Jupyter: queries the live plotly.js graph div directly via the existing widget comm channel. This is the most accurate path because it reflects true browser font metrics, container-inherited dimensions, and any responsive resizing that has occurred.
• Static Figure or non-Jupyter environments: falls back to a scoped Kaleido render — similar to full_figure_for_development but only extracting the requested keys, making it significantly faster and producing a much smaller result object.

The user should not need to think about which backend is being used. The method just works, and the docstring can note that FigureWidget results may be more accurate for layout-sensitive values like margins and tick_rotation.

---

Why Opt-In for Large Outputs?

Certain keys like stack_geometry and histogram_bins can be proportional to the size of the input data — potentially thousands of values per trace. These should either:

• Only be returned when explicitly listed in include, and never part of a bare get_computed_values() call, or
• Support an additional max_points argument to return a sampled or summarized form

This keeps the default call fast and the result human-readable, while still making the full data accessible when genuinely needed.

---

JavaScript Access (No New Method Needed)

For JavaScript users, no new method is necessary. The computed values could simply be attached to existing structures after render:

// Layout-level values
gd._computedLayout.axis_ranges
gd._computedLayout.margins
gd._computedLayout.tick_values

// Per-trace values
gd._fullData[0]._computed.box_stats
gd._fullData[1]._computed.bar_geometry

This follows the existing convention of _full-prefixed objects on the graph div and requires no API change for JS users — just documented properties they can read after the plot renders.

---

This is a starting-point sketch and I would welcome feedback on naming, structure, or which keys are feasible to expose. The goal is simply to move from "here's a concept" to "here's something we can concretely discuss and implement."

[ranjeet7980]

Following this proposal, I have filed two related feature requests that extend this idea:

• [FEATURE]: get_subplot_geometry()
• [FEATURE]: autorangePadding