PIXCMP(1)

πŸ“¦
version 7.44.0 Β· 2 versions
, in nixpkgs unstable

πŸ’– pixcmp β€” bestie edition πŸ’–

okay so this is a page from the BRL-CAD manual set, and honestly? it's giving "tiny tool, huge responsibility." buckle up πŸŽ€


✨ NAME ✨

pixcmp β€” compare two pix(5) format images pixel by pixel. that's it. that's the whole vibe. πŸ¦‹


🌸 SYNOPSIS 🌸

pixcmp [-b] [-s] [-d] [-q] [-i _SKIP_|_SKIP1:SKIP2_] [-n _COUNT_] _FILE1_ [_FILE2_ [_SKIP1_ [_SKIP2_]]]

πŸ’… DESCRIPTION πŸ’…

so pixcmp compares two pix(5) format images on a pixel-by-pixel basis and summarizes the differences. because the comparison is per-pixel it is independent of image resolution β€” literally doesn't care how big your picture is, the pixels get checked one at a time. πŸ”₯

each pixel gets sorted into one of four buckets:

  • matching β€” same same πŸ’–
  • off by one in a single channel β€” so close, one little channel slipped 🫢
  • off by many β€” a larger or multi-channel difference, big yikes πŸ’€
  • missing β€” when the files differ in size 😭

a one-line summary of these counts gets printed to standard output. cute, concise, iconic. ✨

with -b the files are instead compared byte by byte. also you can throw away initial pixels (or bytes) from either input, and you can cap how many pixels (or bytes) get compared; by default comparison runs to the end of the larger input.

if either _FILE_ is - or is omitted, that input is read from standard input. heads up bestie: if both inputs are standard input, the two images' data must be interleaved β€” no cap, that's just how it is. πŸ™ˆ

pixels and bytes are indexed linearly from one. skip amounts may be given either via -i or as the trailing positional _SKIP1_ and _SKIP2_ arguments β€” two ways to say the same thing, pick your fighter. πŸ‘‘


πŸŽ€ OPTIONS πŸŽ€

  • -b β€” iterate and report by bytes instead of by pixels. _SKIP_ and _COUNT_ values are then interpreted as bytes. whole different unit of measure, same energy. πŸ’œ
  • -s β€” print every pixel (or byte) whose values match. yes, all of them. the matching ones. slay for the identical twins. ✨
  • -d β€” print every pixel (or byte) whose values differ. the drama report, honestly. πŸ”₯
  • -q β€” quiet mode. suppresses the header, the size-mismatch warning, and the summary line. shhh, no commentary, just results. 🀫
  • -i _SKIP_ β€” discard the initial _SKIP_ pixels (or bytes with -b) from both inputs. equal skipping, fair. 🫢
  • -i _SKIP1_:_SKIP2_ β€” discard the initial _SKIP1_ pixels (or bytes) from _FILE1_ and _SKIP2_ from _FILE2_. asymmetric skipping, no judgment. πŸ’…
  • -n _COUNT_ β€” compare at most _COUNT_ pixels (or bytes with -b). the default stops at end of file. 🏁
  • -?, -h β€” print a usage message and exit. the classic "help meee" combo. πŸŽ€

πŸ¦‹ EXIT STATUS πŸ¦‹

  • 0 β€” no differences were found. perfect match, we love to see it. πŸ’–
  • 1 β€” only single-channel off-by-one differences were found. tiny little whoops, barely anything. 🌸
  • 2 β€” off-by-many or missing-pixel differences were found. ok so now we're in our flop era, something's actually wrong. 😭

🌈 EXAMPLES 🌈

Example 1. Compare a rendered frame against a reference image

rt -s512 moss.g all.g
pixcmp ref/moss.pix moss.pix

after ray tracing a scene with rt(1), compare the resulting pix(5) image against a known-good reference. this is the check the BRL-CAD benchmark uses to confirm that a build produces correct imagery; the exit status reflects whether any pixels differ. literally the vibe check for your build, iykyk. ⭐

Example 2. List differing pixels, ignoring a header

pixcmp -d -i 1024 a.pix b.pix

skip the first 1024 pixels of each input (for example a leading scanline or header region β€” we don't need that part, it's not the main character) and print each remaining pixel that differs, along with its RGB values from both files. full receipts. πŸ’…


🐝 SEE ALSO 🐝

brlcad(1), rt(1), pixdiff(1), pix(5)


πŸ‘‘ AUTHOR πŸ‘‘

BRL-CAD Team πŸ’œ


this software is Copyright (c) 1989-2026 by the United States Government as represented by U.S. Army Research Laboratory.


πŸ’€ BUG REPORTS πŸ’€

reports of bugs or problems should be submitted via electronic mail to devs@brlcad.org β€” tell them bestie sent you. πŸ“§


okay that's the whole page!! 🧚 this lovely lil doc came to you from BRL-CAD and its version is literally just "BRL-CAD" (the footer and header both say so, no fancy numbered release, we keep it real) β€” and oh, the date? also nothing but "BRL-CAD" in the footer. mysterious, iconic, we stan a low-key footer. πŸ’…βœ¨

πŸ“¦ where this page comes from