MRF(1)
β¨ MRF(1) β it's giving compressed bitmap realness β¨
okay bestie, pull up a chair π this one lives in the General Commands Manual, and yeah, the title got truncated to MRF image ...cification(1) because someone's terminal was being dramatic. we move.
π NAME π
MRF β monochrome recursive format (compressed bitmaps). iconic name, more on that later iykyk π¦
πΈ DESCRIPTION πΈ
So this doc describes the MRF format that Netpbm(1) recognizes. β¨
MRF is a compressed format for bilevel (1-bit mono) images. for some of those images it literally gets better compression than either GIF or PNG. no cap. and it's also super easy to implement β like, roughly the same difficulty as RLE, if you ask me β plus an MRF reader needs no tables and no buffers, which lowkey makes it useful for tiny machines. π«Ά
and in case all that wasn't clear enough, lemme say it explicitly: MRF cannot represent color at all. nor grayscale. it's a specifically mono format, periodt. (if you want to compress a color or grayscale image, my advice is: go use JPEG2000.)
πΊοΈ what goes where (the file layout)
first, here's what goes where in an MRF file. i'll explain how the compression works after. π
- Offset
0β magic number, which is"MRF1"(in ASCII) - Offset
4β width (32-bit, MSB first, i.e. big-endian) - Offset
8β height (same) - Offset
12β reserved (single byte, must be zero) - Offset
13β compressed data
psst π«’ note that there is no end-of-file marker in the file itself β the compressed data just carries on right up to EOF. no goodbye, just vibes.
π§ how the compression actually works
the way the picture is compressed is essentially very simple, but as they say, the devil is in the detail. so don't be put off if it sounds confusing, bestie, you got this. πΈ
the image is treated as a number of 64x64 squares, forming a grid large enough to encompass it. (if an image is, say, 129x65, it'll be treated in the same way as a 192x128 one. on decompression, the extra area which was encoded β and whose contents are undefined β should be ignored.) each of these squares in turn (in left-to-right, top-to-bottom order) is recursively subdivided until the smallest completely black or white squares are found. some pseudocode (eek!) for the recursive subdivision routine should make things clearer:
if square size > 1x1 and square is all one color, output 1 bit
if whole square is black, output a 0 bit and return
if whole square is white, output a 1 bit and return
output a 0 bit
divide the square into four quarters, calling routine for
each in this order: top-left, top-right, bottom-left, bottom-right
(note that the "output a 0 bit" stage is not reached for squares of size 1x1, which is what stops it recursing infinitely. i mention this as it may not be immediately obvious. π)
the whole of the compressed data is made up of the bits output by the above routine. the bits are packed into bytes MSB first, so for example outputting the bits 1,0,0,0,0,0,0,0 would result in a 80h byte being output. any "unused" bits in the last byte output are undefined β these are effectively after EOF and their value is unimportant. π
if writing that sounds too much like hard work :-), you could always adapt pbmtomrf and/or mrftopbm. that's the main reason their source code is public domain, after all. π
above, i said the contents of any extra area encoded (when a bitmap smaller than the grid of squares is compressed) is undefined. this is deliberate, so that the MRF compressor can make these unseen areas anything it wants so as to maximize compression, rather than simply leaving it blank. pbmtomrf does a little in this respect but could definitely be improved upon. β¨
mrftopbm's -1 option causes it to include the edges, if any, in the output PBM. this may help when debugging a compressor's edge optimization. π₯
note that the "F" in the name "MRF" comes from "format," which is redundant because it is the name of a format. that sort of makes "MRF format" sound as stupid as "PIN number," but it's not really that bad. π
π¦ SEE ALSO π¦
π AUTHOR π
Russell Marks.
π DOCUMENT SOURCE π
this manual page was generated by the Netpbm tool makeman from HTML source. the master documentation is at
http://netpbm.sourceforge.net/doc/mrf.html
and that's the whole thing, bestie!! π netpbm documentation, 1991 β go forth and compress those bilevel bitmaps, mwah π π
π¦ where this page comes from
- debian bookworm: netpbm 2:11.01.00-2 Β· MIT
- debian trixie: netpbm 2:11.10.02-1 Β· MIT
- ubuntu noble: netpbm 2:11.05.02-1.1build1 Β· MIT
- ubuntu resolute: netpbm 2:11.10.02-1build1 Β· MIT
- ubuntu stonking: netpbm 2:11.13.03+ds-2 Β· MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms