Describe the bug
The local-file COG path in read_to_array decodes the array and then applies _apply_orientation to remap pixels into the standard top-left orientation. The HTTP COG path in _read_cog_http does not.
xrspatial/geotiff/_reader.py:1606 only rejects a non-default Orientation tag when window is not None; the full-read branch at xrspatial/geotiff/_reader.py:1654 returns the raw output of _fetch_decode_cog_http_tiles and the unmodified geo_info straight back to the caller. So reading the same oriented TIFF locally and over HTTP produces different pixel arrays and (in cases where orientation swaps width/height) different geo_info.
Expected behavior
Full HTTP COG reads of an oriented TIFF return the same array and geo_info as the local-file path. Specifically, _apply_orientation should run after _fetch_decode_cog_http_tiles and any geo_info dimensions affected by the orientation transform should be updated to match. The window+non-default-orientation rejection at line 1606 stays in place because windowed reads against oriented files have ambiguous semantics until _apply_orientation is taught about windows.
Proposed fix
In _read_cog_http, after the _fetch_decode_cog_http_tiles call when window is None, run the array and geo_info through the same orientation-handling helper used by the local path. Add a backend-parity test that writes a TIFF with a non-default Orientation tag and asserts the local and HTTP reads return equal arrays and equivalent geo_info.
Describe the bug
The local-file COG path in
read_to_arraydecodes the array and then applies_apply_orientationto remap pixels into the standard top-left orientation. The HTTP COG path in_read_cog_httpdoes not.xrspatial/geotiff/_reader.py:1606 only rejects a non-default Orientation tag when
window is not None; the full-read branch at xrspatial/geotiff/_reader.py:1654 returns the raw output of_fetch_decode_cog_http_tilesand the unmodifiedgeo_infostraight back to the caller. So reading the same oriented TIFF locally and over HTTP produces different pixel arrays and (in cases where orientation swaps width/height) different geo_info.Expected behavior
Full HTTP COG reads of an oriented TIFF return the same array and geo_info as the local-file path. Specifically,
_apply_orientationshould run after_fetch_decode_cog_http_tilesand any geo_info dimensions affected by the orientation transform should be updated to match. The window+non-default-orientation rejection at line 1606 stays in place because windowed reads against oriented files have ambiguous semantics until_apply_orientationis taught about windows.Proposed fix
In
_read_cog_http, after the_fetch_decode_cog_http_tilescall whenwindow is None, run the array and geo_info through the same orientation-handling helper used by the local path. Add a backend-parity test that writes a TIFF with a non-default Orientation tag and asserts the local and HTTP reads return equal arrays and equivalent geo_info.