FBSTRETCH(1)

📦
version 7.44.0 · 2 versions
, in nixpkgs unstable

💅 FBSTRETCH(1) — the BRL-CAD glow-up manual 💅

okay so bestie, you found fbstretch(1) from the BRL-CAD manual set, and honestly? she's a little icon. let's get into it 🎀

✨ NAME ✨

fbstretch — stretch a frame buffer image 🫶 (yes, that's it, that's the whole job, and she does it flawlessly)

✨ SYNOPSIS ✨

fbstretch [-a] [-v] [-s _size_] [-w _width_] [-n _height_] [-f _in_fb_]
          [-x _x_scale_] [-y _y_scale_]
          [-S _size_] [-W _width_] [-N _height_] [[-F] _out_fb_]

✨ DESCRIPTION ✨

so fbstretch expands or compresses a frame buffer image, and she can do it horizontally, vertically, or both — like, no cap, both directions are on the table 💅. the image scaling origin (the fixed point) is the lower left-hand corner of the display, periodt.

when you're expanding (scale factor greater than 1), pixels are simply replicated. copy-paste behavior, literally. but when you're compressing (scale factor less than 1), pixel averaging is performed — unless you explicitly request sampling with the -a option. so the vibes change depending on which direction you're going lmao 🌸.

the default input image size is 512 by 512. explicitly specified sizes override the default, and if the actual input image size is smaller than what you requested, the actual size will be used (she's not gonna invent pixels for you, bestie 😭). if not specified, the requested output frame buffer size will be the stretched revised input size — it just follows from the math, iykyk.

now, if there are margins within the requested output beyond the stretched image, they will be cleared to background 🧚. but if the stretched image would extend beyond the requested output size, it will be clipped to fit — even if there is room for it in the actual frame buffer. yeah. she said no. 🙈 actual sizes depend on details of specific frame buffers, so like, check your own situation.

✨ OPTIONS ✨

  • -f input_image_name — inputs the image to be displayed from the specified frame buffer or pix(5) file, instead of modifying the output frame buffer in place. ⚠️ heads up: this option may not work if input and output frame buffers are the same device. awkward.
  • -s input_square_size — specifies input image width and height. two birds, one flag 🦋
  • -w input_width — specifies input image width.
  • -n input_height — specifies input image height.
  • -a — (no averaging) specifies that output pixels will be sampled from the input, instead of being computed by averaging RGB values. sampling girlies rise 🔥
  • -v — (verbose) causes actual sizes and scale factors used to be printed on the standard error output. she'll tell you exactly what she did 💖
  • -x horizontal_scale_factor — scales the image by the specified factor in the horizontal direction; the default is the ratio of requested output to input widths, if specified, otherwise 1.
  • -y vertical_scale_factor — scales the image by the specified factor in the vertical direction; the default is the ratio of requested output to input heights, if specified, otherwise 1.
  • -S output_square_size — specifies output frame buffer width and height.
  • -W output_width — specifies output frame buffer width.
  • -N output_height — specifies output frame buffer height.
  • -F output_frame_buffer_name — outputs to the specified framebuffer instead of the one specified by the FB_FILE environment variable. and here's the cute part: if this is the last option, the -F prefix is optional 🌈 (she's flexible like that)
  • -h, -? — print a usage message and exit.

✨ DISCUSSION ✨

real talk for a sec: pixel averaging may be meaningless for some images or color maps — in which case sampling should be specified. images of the Mandelbrot set are a good example of this 👑. so like, know your image, bestie.

✨ EXAMPLES ✨

Example 1. Enlarge a 320x200 image to fill a 1280x1024 framebuffer

$ gif-fb image.gif
$ fbstretch -w 320 -n 200 -W 1280 -N 1024

ate. no crumbs. 💀✨

✨ SEE ALSO ✨

gif-fb(1), pixscale(1), libdm(3), pix(5) — go read those too, they're the friend group 🫶

✨ DIAGNOSTICS ✨

error messages are intended to be self-explanatory. she's not cryptic, she's just honest 😭

✨ AUTHOR ✨

Douglas A. Gwyn, BRL/VLD-VMB — the main character who made this happen 💜

this software is Copyright (c) 1989-2026 by the United States Government as represented by U.S. Army Research Laboratory. iconic and legally protected, love that for her 🎀

✨ BUG REPORTS ✨

reports of bugs or problems should be submitted via electronic mail to devs@brlcad.org — don't suffer in silence, tell the devs 🦋

ngl if something looks weird, it's probably the frame buffer being specific, not you. actual sizes depend on details of specific frame buffers, remember? 💅

and that's the whole page, bestie — brought to you by the BRL-CAD manual set, FBSTRETCH(1), dated in that gorgeous little 1989-2026 copyright window. slay, go stretch some pixels 🌸✨💖

📦 where this page comes from