resize
result = resize(img, width, height, [method="nearest"])
Input: img, width, height, method · Output: result
What it is
img is an Image; width/height are positive integers giving the absolute target size in pixels (not a scale factor — see imscale for that). method is an optional named string: "nearest" (default, cheap nearest-neighbor) or "bilinear" (smoother).
Overloads
img can be Image or Vec; method can be string or Vec.
2 forms. Each carries its own inputs, outputs and worked example — pick the tab for the one you are calling.
| Code | Input | Output | Description |
result = resize(img, width, height, [method="nearest"]) | img Imageimg an Image.width —width/height are the absolute output size in pixels.height —width/height are the absolute output size in pixels.method string, optional (default "nearest")Resamples the whole picture to that size using method for interpolation — the resulting figure is the same content redrawn at a new resolution, nothing about the pixels' meaning changes. | Vec number or Vecresize(vec, new_length, [fill=0.0]), a ReDim Preserve-style grow/shrink to new_length elements, padding new slots with the number fill when growing, truncating when shrinking, and returning a new Vec | — |
Examples
Written for this form and run by the build -- the output below is what the engine actually produced.
img = image_new(10, 10, r=0, g=0, b=0)
big = resize(img, 20, 15, method="bilinear")
print(big.width, big.height) # 20 15
20 15
Ask an image its dimensions with .width and .height, not with a tuple. Every call in this chapter that takes a size takes it as width then height — image_new(width, height), resize(img, width, height), crop(img, x0, y0, width, height) — and a named accessor cannot be read in the wrong order the way a pair can. img.width means the same thing however the language chooses to order a returned pair, so code written against it does not depend on remembering a convention, and does not change meaning if that convention is ever revisited.
For completeness: size(img) returns [width, height] — the same order every call above takes — and length(img) returns the pixel count, which has no order to get wrong. There is no worked example of size on an image on this page yet, deliberately: the build that renders these pages runs an engine older than that behaviour, so an example printing it would show you a number the current engine does not produce, over the build's signature. It will be added once the two agree.
| Code | Input | Output | Description |
result = resize(img, width, height, [method="nearest"]) | img Vecimg is an Image.width Vecwidth/height are positive integers giving the absolute target size in pixels (not a scale factor — see imscale for that).height Vecwidth/height are positive integers giving the absolute target size in pixels (not a scale factor — see imscale for that).method Vec, optional (default "nearest")method is an optional named string: "nearest" (default, cheap nearest-neighbor) or "bilinear" (smoother). | Vec number or Vecresize(vec, new_length, [fill=0.0]), a ReDim Preserve-style grow/shrink to new_length elements, padding new slots with the number fill when growing, truncating when shrinking, and returning a new Vec | vec a Vec; new_length is the target element count, fill (optional, default 0.0) is the value used to pad new trailing slots when growing. A ReDim Preserve-style grow/shrink — growing keeps every existing element and appends fills, shrinking truncates from the end. Nothing to do with pixels at all; same builtin name, unrelated meaning. |
Examples
Written for this form and run by the build -- the output below is what the engine actually produced.
v = [1, 2, 3]
print(resize(v, 5, fill=9)) # [1, 2, 3, 9, 9] -- grown, padded with 9
print(resize(v, 2)) # [1, 2] -- shrunk, tail dropped
[1, 2, 3, 9, 9] [1, 2]
How it works
resize(img, width, height, [method="nearest"|"bilinear"]) — nearest-neighbor by default (matches most languages' cheap first-pass resize); method="bilinear" for smoother scaling. resize(vec, new_length, [fill=0.0]) — overloaded on argument type, not a separate name (same pattern as zeros(filt) above): BASIC's ReDim Preserve, offered as an explicit, visible call rather than an implicit side effect of assignment (see the out-of-bounds index-assignment decision silent-bug risk, a typo'd index would silently resize instead of erroring, but a deliberate, named resize(...) call carries none of that ambiguity: the intent to grow/shrink is right there in the source). Returns a NEW vector of exactly new_length, same immutable-return convention as append/hstack/vstack: growing keeps every existing value in its original position and pads the new trailing slots with fill; shrinking truncates (keeps the first new_length elements, matching ReDim Preserve's own shrink behavior — dropping the tail, not an error).
From the note above this builtin in the interpreter, where the reasoning was written down as it was built.