You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR #1803 added max_pixels=max_pixels to the source read_to_array call inside read_vrt's source loop so that a tiny VRT output cannot force a huge source decode (#1796). The intent is correct, but _read_tiles and _read_tiles_cog_http use the same max_pixels for two separate things:
Per-tile dimension sanity (_check_dimensions(tw, th, samples, max_pixels) at _reader.py:1565 and :2022) — meant to reject crafted TIFFs whose TileWidth / TileLength headers declare absurd per-tile sizes (e.g. tw = 2^31).
After #1803 a user who sets max_pixels=10000 to bound their output now also fails the per-tile check on every normal source: a default 256×256 tile (65,536 pixels) trips the cap even when the requested window is much smaller.
The output is 100×100=10,000 pixels, exactly at the cap; the source-tile check rejects 256×256=65,536 first.
Fix: the per-tile dimension sanity check should use a separate, large absolute cap (e.g. MAX_PIXELS_DEFAULT = 1e9) rather than the caller's output budget. The output-window check at the same call sites continues to enforce the user-supplied max_pixels, preserving the #1796 protection.
Existing test xrspatial/geotiff/tests/test_vrt_dstrect_resample_cap_1737.py::test_dstrect_at_cap_succeeds is the regression: it was authored against the pre-#1803 contract and now fails. Six open PRs share this failure on Python 3.14 (the matrix's first-fail) and have the rest of the matrix cancelled fail-fast, so they all appear BLOCKED downstream.
PR #1803 added
max_pixels=max_pixelsto the sourceread_to_arraycall insideread_vrt's source loop so that a tiny VRT output cannot force a huge source decode (#1796). The intent is correct, but_read_tilesand_read_tiles_cog_httpuse the samemax_pixelsfor two separate things:_check_dimensions(out_w, out_h, samples, max_pixels)) — enforced for the data the caller will receive. This is what catches the VRT source reads do not honor max_pixels safety limit #1796 attack._check_dimensions(tw, th, samples, max_pixels)at_reader.py:1565and:2022) — meant to reject crafted TIFFs whoseTileWidth/TileLengthheaders declare absurd per-tile sizes (e.g.tw = 2^31).After #1803 a user who sets
max_pixels=10000to bound their output now also fails the per-tile check on every normal source: a default 256×256 tile (65,536 pixels) trips the cap even when the requested window is much smaller.Repro:
The output is 100×100=10,000 pixels, exactly at the cap; the source-tile check rejects 256×256=65,536 first.
Fix: the per-tile dimension sanity check should use a separate, large absolute cap (e.g.
MAX_PIXELS_DEFAULT = 1e9) rather than the caller's output budget. The output-window check at the same call sites continues to enforce the user-suppliedmax_pixels, preserving the #1796 protection.Existing test
xrspatial/geotiff/tests/test_vrt_dstrect_resample_cap_1737.py::test_dstrect_at_cap_succeedsis the regression: it was authored against the pre-#1803 contract and now fails. Six open PRs share this failure on Python 3.14 (the matrix's first-fail) and have the rest of the matrix cancelled fail-fast, so they all appear BLOCKED downstream.