Repository: go
Issue: x/image/draw: panic resizing image.Uniform
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.20.4 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/chris/.cache/go-build"
GOENV="/home/chris/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/chris/Code/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/chris/Code/go"
GOPRIVATE="*.playchat.net"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/chris/.local/lib/go-1.20.4"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/chris/.local/lib/go-1.20.4/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20.4"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/tmp/repro/go.mod"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2871775836=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

### What did you do?

I have code that downloads an image and tries to rescale it. In the event that the download failed, it falls back to a simple `image.Uniform` and uses that instead. However, this approach actually panics during the rescale in a surprising way:

https://go.dev/play/p/01WIzG_E0nb

```
panic: runtime error: makeslice: cap out of range

goroutine 1 [running]:
golang.org/x/image/draw.newDistrib(0x4fa1e0, 0x5299f8?, 0x77359400)
        /home/chris/Code/go/pkg/mod/golang.org/x/image@v0.7.0/draw/scale.go:266 +0x265
golang.org/x/image/draw.(*Kernel).newScaler(0x4fa1e0, 0xa, 0xa, 0x77359400, 0x77359400, 0x0)
        /home/chris/Code/go/pkg/mod/golang.org/x/image@v0.7.0/draw/scale.go:142 +0x5e
golang.org/x/image/draw.(*Kernel).Scale(0xc00006a058?, {0x49c700, 0xc00002a040}, {{0x7f602a27cb88?, 0x7f602a271108?}, {0x60?, 0x500b00?}}, {0x49c5c8, 0xc000014230}, {{0xffffffffc4653600, ...}, ...}, ...)
        /home/chris/Code/go/pkg/mod/golang.org/x/image@v0.7.0/draw/scale.go:126 +0xa5
main.main()
        /tmp/repro/main.go:14 +0x165
exit status 2
```

### What did you expect to see?

I expected rescaling an `image.Uniform` to be trivial since it doesn't actually need to do any work.

### What did you see instead?

Because [`image.Uniform.Bounds()`](https://cs.opensource.google/go/go/+/refs/tags/go1.20.4:src/image/names.go;l=40) returns an effectively-infinite size, using the bounds of the image as input to the rescale operation makes the rescale try to allocate a buffer larger than available memory.

I understand that I can special-case this in my logic, but it seems desirable for this not to crash in general when an `image.Uniform` happens to be the input to the rescale operation. Applications like mine may be pulling these images from a variety of sources, and needing this special case is surprising.

I'd be happy to submit a patch that handles this as a special case in the rescale if that's the desired approach.

CC @dominikh @nigeltao @pedroleiterocha @jackmordaunt