Repository navigation
split_raster reads image width as band count after transposing #1438
Description
Describe the bug
split_raster warns that an ordinary three-band image is not three-band. After converting an image from (height, width, channels) to (channels, height, width), it reads numpy_image.shape[2] as the band count. That dimension is width. The warning is visible in the existing preprocessing test suite for the bundled RGB raster.
To reproduce
import tempfile
from deepforest import get_data, preprocess
with tempfile.TemporaryDirectory() as out:
preprocess.split_raster(
path_to_raster=get_data("OSBS_029.tif"),
patch_size=300,
save_dir=out,
)Actual warning: Input image had non-3 band shape of (3, 400, 400), selecting first 3 bands.
Expected: No band-count warning for a (3, 400, 400) RGB image. The check should use the channel dimension after layout conversion. The handling of channels-last images with more than four bands also needs a focused test, since the current branch may slice rows rather than channels.
Environment
macOS, Python 3.11.15, DeepForest main 081f1e0 with uv sync --all-extras --dev.
Context
PR #1301 identified the same index error but was closed without merging. It remains present on current main.
User story
As a user preparing RGB raster crops, I want channel validation to report the actual channel count so valid images do not emit misleading warnings and multispectral images are handled deliberately.
Activity
hardikkaurani commentedon Oct 19, 2026
Hi @SahilKumar75 and @henrykironde,
I took a look at this issue and was able to reproduce the warning on the upstream
mainbranch using the bundledOSBS_029.tifraster.It looks like the band count is being read from
numpy_image.shape[2]after the image is transposed from(H, W, C)to(C, H, W). At that point,shape[2]refers to the image width, which seems to be why a valid RGB image triggers the warning.The likely fix is small: use
numpy_image.shape[0]to get the number of channels in the channel-first layout, along with a regression test for the RGB case.@SahilKumar75, are you already working on this? I noticed you're coordinating the related
split_rasterissues, so I wanted to check before going ahead. Happy to put together a small PR if that would be useful.Thanks!
SahilKumar75 commentedon Oct 19, 2026
I’m not working on #1438, so please go ahead with the PR. The RGB regression test sounds right. If it fits the same fix, please also test the more than four bands case noted in the issue.
hardikkaurani commentedon Oct 19, 2026
Thanks, @SahilKumar75 - I’ll proceed with a focused PR for #1438. I’ll cover the RGB regression and add a targeted test for channels-last images with more than four bands if the same layout correction addresses that path, then report the validation results in the PR.
@henrykironde, I’d also appreciate any guidance on the preferred approach for this fix.
Thanks!