[DresdenGman]

Link to issue

Closes #1973

Description of change

go.Image rejected zmin/zmax values whose length matches the trace's
colormodel: with colormodel='rgb' the valid 3-element bounds raised a
ValueError because the validator required exactly 4 elements (the rgba
length). The number of components is 3 for rgb/hsl and 4 for
rgba/rgba256/hsla — the attributes' own descriptions say so — but
validators are stateless and cannot see the colormodel of the trace being
validated, so the fixed 4-element length from the plotly.js schema cannot be
satisfied per-colormodel.

This marks zmin/zmax of the image trace as freeLength in
preprocess_schema in codegen/__init__.py — the central place for schema
adjustments before code generation — so they accept up to 4 elements. This
uses the existing info-array option the schema already applies to e.g.
updatemenu button args and parcoords constraintrange; no validator code
changes were needed. The regenerated plotly/validators/_validators.json
gains "free_length": true on exactly these two properties, and the
generated docstrings in plotly/graph_objs/_image.py now read "a list or
tuple of up to 4 elements".

One trade-off to be explicit about: freeLength accepts any length up to 4,
so 1- and 2-element values (and an empty list) are now also accepted, as they
already are for the other freeLength properties. Every element is still
validated as a number and lengths above 4 are still rejected. Restricting to
exactly 3 or 4 would need a new schema/validator option that plotly.js does
not define; if the schema in plotly.js itself gains freeLength for these
attributes, the preprocessing step here can be dropped.

import numpy as np
import plotly.graph_objects as go

im = np.random.randint(256, size=(50, 50, 3), dtype=np.uint8)
# Before: ValueError ("a list or tuple of 4 elements")
# After: works, bounds match the rgb colormodel
fig = go.Figure(go.Image(z=im, colormodel="rgb", zmin=[10, 10, 10], zmax=[100, 100, 100]))

Demo

Not applicable — validation-only change with no visual output difference
(the figure above previously raised instead of rendering).

Testing strategy

Added tests/test_core/test_graph_objs/test_image.py (16 tests): the #1973
example verbatim, matching-length bounds for all five colormodels, a
4-element value for a 3-component model (the previously accepted workaround
keeps working), the default colormodel, independence from property
assignment order, 5-element values rejected for every colormodel,
non-numeric elements rejected, and Heatmap scalar zmin/zmax as an
unaffected control. The 5 tests covering 3-element values fail on main and
pass with this change.

Full runs of tests/test_plotly_utils/validators/ and
tests/test_core/test_graph_objs/: 1555 passed / 2 failed on main vs.
1571 passed / 2 failed with this change — the delta is exactly the 16 new
tests, and both failures are pre-existing environment issues
(test_deepcopy_dataframe[polars] / [pyarrow], missing optional
dependencies), identical before and after.

Additional information (optional)

The fix is applied at the code-generation layer rather than by editing
generated files: preprocess_schema already hosts schema adjustments of
this kind (e.g. the sankey concentrationscales rename). I verified that
re-running code generation on unmodified main reproduces the checked-in
_validators.json exactly, so the regenerated diff contains only the two
intended entries.

Guidelines

• I have reviewed the pull request guidelines and the Code of Conduct and confirm that this PR follows them.
• I have added an entry to the changelog if needed (not required for documentation PRs).