Ben Day

A Ben Day dot is a printed dot that is always the same size, laid down in a regular pattern so that one ink makes a tint, and it is the texture every color comic from the 1890s to the 1980s was printed in. A scan of one of those pages is a grid of dots photographed onto a grid of pixels, and shown on a third grid of lights it interferes with itself. Fuji averages the dots away in every thumbnail, leaves the light table to the engine's own smoothing, and gives it one key, R, that turns the smoothing off and shows a picture's own pixels as blocks.

This page is the history of the dot, then the history of the word for the interference, which is older than any of this and is not a man's name, and then what Fuji does to the pixels of a scanned page, by algorithm, operating system call and CSS rule, written from the source.

The dot

A printer's son

Benjamin Henry Day printed the first issue of The Sun in New York on September 3, 1833, and sold it for one cent when the other papers cost five or six. It was the first penny paper in the United States and the first mass-market newspaper, and the mass market would need pictures. His son Benjamin Henry Day Jr., born in 1838, studied in Paris and drew for Frank Leslie's, Harper's Weekly and Vanity Fair, the illustrated weeklies of the 1860s and 1870s, and for Mark Twain's A Tramp Abroad of 1880. He was a working illustrator rather than a famous one, and what he knew from the inside was how long it took to shade a drawing by hand: every tint on a lithographic stone was stippled dot by dot or ruled line by line by a craftsman with a pen. On April 22, 1879, the Patent Office granted him U.S. Patent 214,493, "Improvement in Printing-Films", filed from West Hoboken, New Jersey, the year before. Its first claim is six words long, "A transparent tinting or printing film," and the word dot appears nowhere in it. The text speaks of "light or heavy, straight, swelled, or wavy lines, stipples, or grains," and the stipple, a field of small marks, is the dot's first name.

The film

Andy Bleck's history of the Ben Day dot, the most thorough account anyone has written, reads the patent and the catalogues closely, and the mechanism is simple. A pattern of lines or stipples is engraved on a block, an impression of the block is taken in tin foil, and warm gelatine mixed with glycerine poured over the foil sets into a nearly transparent sheet carrying the pattern in relief. Backed with silk, later with celluloid, and sewn onto a hinged wooden frame, the sheet was a screen: the lithographer inked its raised pattern with a roller, masked the parts of the stone that were to stay clear, lowered the screen over the drawing, and rubbed the back with a stylus wherever the tint was wanted, and the pattern transferred to the stone in greasy ink. Day's adjustable frame of 1881 added screws that moved the screen a thirty-second of an inch per turn, so a tint could be printed twice slightly offset and doubled. A catalogue of 1911 shows a hundred and seventy-two screens, twenty-six of them stipples; The Times wrote in 1912 that after 1885 mechanical stippling had largely replaced hand stippling and cheapened the publication of color work; and a British artist writing in 1941 still called the best films "Day's medium," after the man.

Halftone, the other dot

The Ben Day dot has a sibling, and people confuse the two constantly. A Ben Day dot is the same size everywhere and makes one flat tint, and an artist chooses where it goes; a halftone dot changes size from place to place to follow the tones of a photograph, and a camera chooses. William Fox Talbot suggested a screen of gauze over a photographic plate in 1852. Stephen Horgan printed the first photograph in a newspaper, of Steinway Hall, in the New York Daily Graphic on December 2, 1873; Frederic Ives of Philadelphia patented the first commercially successful process in 1881; Georg Meisenbach patented his Autotypie in Germany in 1882; and Max Levy's ruled glass screen of 1893 made the crossline screen a product a shop could buy. The wood engraving trade was gone by the end of that decade, and from then on a photograph went into print as a grid of dots.

The Sunday paper

Color came to the American newspaper in 1892, when the Chicago Inter-Ocean printed the first Sunday color section in the country, and New York's World, Herald and Journal followed from 1893. Bleck's chapter on the letterpress 1890s follows the dot into those pages: Richard Outcault's Hogan's Alley first ran in color in May 1895, at least partly tinted with Ben Day screens, and The Yellow Kid and his New Phonograph, printed in the New York Journal on October 25, 1896, is the page usually named as the first comic strip. In letterpress the engraver masked the zinc plate for each color, pressed the inked screen's dots onto it, and etched away everything that was not a dot or a solid, so each plate printed its ink as a field of identical dots wherever the artist had asked for a tint. The Sunday comics were born in Ben Day, and the comic book inherited the whole apparatus.

Four inks, sixty-four colors

The comic book of the 1950s and 1960s was printed on newsprint by four-color rotary letterpress, most of it at World Color Press in Sparta, Illinois, which by the early 1980s printed nearly every comic book in America. A colorist painted a photostat of the inked page with dyes and wrote a code beside each area for the separator, and the code was not CMYK but YRB, yellow, red and blue, with a number for the tint: a bare letter was solid ink, a 2 was 25 percent, a 3 was 50 percent, and YR2B3 stacked solid yellow, a quarter red and half blue. Three tints of three inks, with black for the lines, gave sixty-three colors and the white of the paper, the sixty-four-color palette the era is remembered for. The separations were cut by hand, mostly by women, on acetate overlays at the Chemical Color Plate Corporation in Bridgeport, Connecticut, which did the work for Marvel, DC and Archie, and the tints went onto the plates through contact screens of sixty lines to the inch, each color's screen turned thirty degrees from the last. Day's gelatine film had long since gone out of use. What survived was the look, a field of identical dots at one of three densities, and the name.

Lichtenstein

In 1961 Roy Lichtenstein painted Look Mickey, four feet by nearly six, from an illustration in a Disney storybook, and in 1963 Whaam!, a diptych thirteen feet wide from a panel Irv Novick drew for All-American Men of War, and Drowning Girl, from Tony Abruzzo's splash page in Secret Hearts. The Tate bought Whaam! in 1966 and the Museum of Modern Art bought Drowning Girl in 1971. He painted the dots through a handmade metal screen with a scrub brush, and by 1963 through a stencil that gave them a regularity the comics never quite had. The dots were the argument of the paintings, a painter's hand pretending to be a press at a size where nobody could pretend the dots were anything else, and after him the Ben Day dot was a sign: anything printed with it reads as a comic, on a poster, a shirt or a film.

Screentone

The dot moved from the printer's shop to the artist's desk as a sheet of adhesive film, Day's screen turned inside out: the pattern is already printed, and the artist cuts the sheet, lays it face down, rubs the back with a stylus, and peels the backing away. Zip-A-Tone claims first use in 1937, Chart-Pak followed in 1949, and Letraset sold the same thing as Letratone from 1966. Western comics used it for texture and shading, and Japanese manga, printed in black on cheap paper with no color at all, built its whole language of tone on it: skies, blushes, speed lines, the gray of a school uniform. A manga page of the 1980s is a Ben Day page with the color taken out, and a scanned one has the same dots at the same densities.

Moiré

Moiré is the pattern that appears when two regular patterns are laid over each other, and the word is French for a watered silk. The fabric came first: silk makers pressed two wet layers of ribbed cloth together, the ribs did not quite line up, and the dried cloth carried a rippled sheen that looks like water. The French noun moire is a seventeenth-century borrowing of the English mohair, which the English had from the French mocayart, the Italians from mocaiarro, and everyone from the Arabic mukhayyar, the chosen cloth, goat's hair of the best quality. So the word is a cloth, then a finish, then the look of that finish, and only then the ripples in a photograph of a screen door. Nobody named Moiré invented anything.

The effect is a beat. Two gratings of nearly the same pitch go in and out of step, and the eye sees the slow pattern where they drift: for two sets of lines of spacing p and p + δp, the bands fall about p²/δp apart, and for two identical gratings turned by a small angle α they fall about p/α apart. Four halftone screens on one page are four gratings, and the printer's craft of screen angles keeps them thirty degrees apart so the beat between them becomes the rosette, a pattern too fine and too even to notice. A screen out of angle shows the beat as a plaid across a face, which is the moiré the comic separators guarded against.

A scanner adds a third grating. It samples the page on a grid of its own, and a screen of sixty dots to the inch sampled at three hundred dots to the inch is five samples per dot, which is enough; sampled at seventy-two it is barely one, and the dots fold into a slow beat with the sampling grid, which signal processing calls aliasing. The same thing happens again, in software, every time the scan is shown smaller than it was scanned: shrinking a picture to fit a window is sampling it again, on the window's grid, and a method that picks pixels rather than averaging them makes the beat on the screen instead of on paper. Scanner software calls the cure descreening, and the reliable form of it is to scan high, blur the dots away, and shrink. Fuji descreens nothing. Every thumbnail it makes averages rather than picks, and the rest of this page is which method, where, what the light table does instead, and the one key that turns its smoothing off.

What Fuji does to the pixels

Four pixel units are at work below. Image pixels are the picture's own, the grid the scanner or the camera made. CSS pixels are the page's and the user's, what a thumbnail is sized in and what a key on the light table counts in. Backing pixels are the grid the web engine paints into, devicePixelRatio of them to a CSS pixel: two on a Retina Mac and one and a half on a Windows laptop at 150 percent. Panel pixels are the lights, and on a Mac in a scaled mode macOS resamples the whole backing store onto them afterward, invisibly to every program. Fuji's rule is that a picture is resampled once, from image pixels to backing pixels, and that the backing pixels then reach the compositor one to one with nothing to do; the thumbnails page has the measurements behind it.

A thumbnail averages

A thumbnail is a reduction, and every route Fuji has to one reads every source pixel. On macOS and Windows a JPEG or a PNG never reaches the web engine: Rust asks the operating system's own imaging library, the one Finder and Explorer use, for a thumbnail at the backing size the page will show it. On the Mac that library is ImageIO, whose CGImageSourceCreateThumbnailAtIndex decodes a JPEG at a half, a quarter or an eighth where the codec allows and resamples the rest of the way with a filter that reads every source pixel. On Windows it is the Windows Imaging Component, whose scaler runs in WICBitmapInterpolationModeFant, which Microsoft describes in one sentence: "Destination pixel values are computed as a weighted average of all the pixels that map to the new pixel." Karl Fant published the method in IEEE Computer Graphics and Applications in January 1986 as "A Nonaliasing, Real-Time Spatial Transform Technique," Honeywell patented it as US 4,835,532, and the title says what it is for: a reduction that integrates every source pixel into each output pixel cannot alias, because no pixel is skipped. The other modes on Microsoft's page, nearest neighbor, bilinear and bicubic, read one, four and sixteen source pixels per output pixel whatever the ratio, and at the twenty to one a thumbnail needs they read almost nothing.

Everything else, WebP, AVIF and BMP on Windows and every raster file on Linux, is decoded by the web engine at full size and shrunk by the page. One drawImage from a large decode into a small canvas aliases on the Mac, because Core Graphics reads a fixed footprint of source pixels around each output pixel and at twenty-six to one most of the picture is never read. So the page halves, through two scratch canvases taken in turn, until the last draw is within two to one, which is the ratio at which a fixed footprint is a true average of its source, and it asks every step for imageSmoothingQuality of high, since the default reads only the four nearest pixels:

while (size.x > target.x * 2) {
	let half = xy(Math.ceil(size.x / 2), Math.ceil(size.y / 2))
	let canvas = scratch[step % 2]
	canvas.width = half.x; canvas.height = half.y
	let c = canvas.getContext('2d', {colorSpace: flowGamut})
	c.imageSmoothingQuality = 'high'
	c.drawImage(source, 0, 0, half.x, half.y)
	source = canvas; size = half; step++
}
context.imageSmoothingQuality = 'high'
context.drawImage(source, 0, 0, target.x, target.y)

A chain of halvings is an averaging filter, since each step reads every pixel of the one before. So by every route, a thumbnail of a scanned comic page on the contact sheet is a smooth tint of the color the printer meant, and never a beat.

The light table smooths

The Diamond Table shows a picture the other way round. The file is read into a blob, an <img> points at it, decode() produces the full-size frame off the main thread, and that one element is put on the card and stays there; a flip hides one element and shows another, and nothing is drawn by hand. The card's size and place are computed in real numbers and snapped to the backing grid, so no edge falls on a fraction of a backing pixel, and the picture fills the card with object-fit of fill, which stretches nothing because the card is the picture's own shape. The engine then resamples the decoded frame once, from image pixels to the card's backing pixels, with the filter it uses for any <img> that sets no image-rendering, and composites the result one to one because every edge of the card is on the grid.

For a page of dots that means two things. Shown smaller than it was scanned, the engine's filter reads a footprint of source pixels that does not grow with the ratio, so at two to one it averages and at five to one it can skip rows, and a sixty-line screen scanned at three hundred dots to the inch can show a beat at some sizes and not at others, exactly as the scanner did. Shown larger, the dots are smoothed into soft disks, and a GIF from 1996 that was drawn pixel by pixel is smoothed the same way, which nobody who drew it wanted. The second case is what the R key is for.

The R key

do this	to
R	show the picture's own pixels as blocks, or smooth them again
I	read Smooth or Rasterized on the hud, under the zoom in CSS and in backing pixels per picture pixel
1 to 6	set a whole number of CSS pixels per picture pixel, where the blocks are exact squares

Press R on the light table and the picture on the card shows its own pixels as blocks. Press it again and the picture is smoothed, as it is at every launch. Nothing is read, decoded or drawn again, the flip is as fast as before, and a GIF keeps animating. It is a lens over the card, the way gamma is a lens over every view: off at every launch, written nowhere, and separate from the contact sheet, whose thumbnails are reductions and are always averaged. The I hud says which it is, Smooth or Rasterized, on the line that carries the gamma, and shows the zoom above it in CSS pixels and in backing pixels per picture pixel, so the ratio the blocks depend on is always in view. The keys and the wheel that set that zoom are the Zoom page's.

The ratio that matters

What the blocks look like depends on one number, backing pixels per image pixel, and it is the product of two numbers that two different parties set:

$$\frac{\text{backing}}{\text{image}}=\frac{\text{CSS}}{\text{image}}\times \frac{\text{backing}}{\text{CSS}}$$

The first factor is the user's: the number keys set it to a whole number, F and W set it to whatever fits the frame, and the wheel and a right drag set it to anything at all. The second is the platform's: 1 on an ordinary monitor, 2 on a Retina Mac, and 1.25, 1.5 or 1.75 on a Windows laptop at the scales people run. Fuji reads it and never sets it.

key	ordinary monitor, 1	Windows at 150%, 1.5	Retina Mac, 2
1	1	1.5	2
2	2	3	4
3	3	4.5	6
4	4	6	8

Backing pixels per image pixel at each number key. At a whole number every image pixel becomes an exact square block of its own color and nothing is blended: the palette of a 1996 GIF stays its palette, its dither stays a dither, and a one-pixel line is exactly as many backing pixels wide as the key says. On an ordinary monitor and on a Retina Mac every key is whole; at 150 percent the odd keys are not, and 1, the key that says actual size, is the worst of them. At a fraction, one notch of the wheel past a number key or an odd key at 150 percent, the blocks are still pure and hard-edged, because Chromium and the Mac's WebKit both draw pixelated as plain nearest neighbor at any ratio, but they are not all one size: at 2.94 backing pixels per image pixel a one-pixel checkerboard comes out as squares of three with a square of two every sixteenth, which the eye reads as a faint beat across the picture. Below one to one the same filter drops image pixels rather than averaging them, which on a photograph is sparkle and on a scanned page of dots is moiré. The key means what it says at every ratio, and the hud says the ratio.

Under the hood

The whole mechanism is one CSS property, one class and one key, and the off position declares nothing at all. The property is image-rendering, and its value is pixelated, which every engine Fuji ships on draws as nearest neighbor, with crisp-edges declared ahead of it so that an engine too old to know the newer word keeps the older one for the same filter. The rule lives in the light table's own scoped styles beside the rule that places the picture, and it matches only while the card carries a class:

.myCard :deep(.myImage) {
	position: absolute;
	top: 0; left: 0; width: 100%; height: 100%;
	object-fit: fill;
	display: none;
}
.myCard.myRaster :deep(.myImage) {
	image-rendering: crisp-edges;
	image-rendering: pixelated;
}

The first rule says nothing about image-rendering, so a card without the class is drawn with the engine's own smoothing. The :deep() is there because the picture is the store's own element, adopted into the card rather than written in the template, and a plain scoped rule could never reach it. The class is bound to one ref, in a module shaped like the gamma module:

export const raster = ref(false)

export function rasterToggle() {
	raster.value = !raster.value
}

<div ref="cardRef" class="myCard myShadow myDry myWillChangeTransform bg-well" :class="{myRaster: raster}">

And the key is answered on the table, beside I, rather than in the shell where G is, because gamma is a way of looking at every view at once and this is a way of looking at the card:

else if (!Ctrl && key == 'r') { rasterToggle() }

It costs nothing because the engine rasterizes the card's picture from image pixels into the card's backing pixels once, and image-rendering chooses the filter for that one draw. The card's edges are already snapped to the backing grid, so the layer composites one to one and the blocks reach the backing store intact. The gamma filter applies to the finished pixels afterward, so a pixelated picture through the gamma lens stays pixelated. And because the rule is scoped to the card, no thumbnail can match it: the contact sheet's canvases are in another component with another scope, and the module that holds the ref is imported by the light table alone.

One image pixel, one light

Everything so far stops at the backing bitmap: the number keys count CSS pixels, and the I hud says how many backing pixels each one becomes. So why not go one grid further, with every pixel in the file on the panel's lights exactly, a red image pixel on pure red lights and a blue one on pure blue, one light each or an exact square of them, and nothing in between? Because no program can promise it. A program paints a bitmap, and how that bitmap reaches the lights is settled after the program has finished, by the operating system and by the display settings the user chose, and the Mac and Windows settle it in opposite ways.

On a Mac, the window server takes the last step. A Mac application draws in points, which are CSS pixels by Apple's name, into what Apple's guide to high resolution calls the backing store, an offscreen bitmap at two pixels to the point on every Retina display. Then, in Apple's words, "the window server scales the content appropriately, mapping points to onscreen pixels." A program reads that two as its window's backingScaleFactor, and Apple's documentation for the property says the number "does not represent anything concrete, such as pixel density or physical size." System Settings lists a Retina Mac's display modes by the size they look like in points, and on a MacBook Air with 2560 by 1664 lights only one of them, "looks like" 1280 by 832, is exactly half the panel, where the backing store and the panel are one grid and a block Fuji paints is the block the lights show. Every other mode is scaled. At "looks like" 1710 by 1112 the window server composites every window and the menu bar into a frame of 3420 by 2224 backing pixels and resamples the whole frame onto the 2560 by 1664 lights, three lights for every four backing pixels, through a smoothing filter no program chooses and none can turn off. A screenshot in that mode is 3420 by 2224, more pixels than the panel has lights, because a screenshot captures the frame the window server composited, before the resample onto the panel.

On Windows, the bitmap is the display resolution, which the user chooses. Windows keeps no backing store of its own for a program that declares itself per-monitor DPI aware, as Fuji does, and Microsoft's guide to high-DPI programs lists what that declaration gets: "the application seeing the raw pixels of each display" and "the application never being bitmap scaled by Windows." The scale setting, 125, 150 or 175 percent, decides only how many of those raw pixels make a CSS pixel. Windows keeps the Mac's arrangement for a program that declares nothing: it paints at 96 dpi and Windows stretches its bitmap, which, as Microsoft puts it, "results in the application appearing blurry." So at the panel's own resolution, the one Windows marks Recommended, the grid Fuji paints is the panel at every scale, and a block Fuji paints is a block on the glass. But many people make things bigger the older way, by lowering the resolution, 1920 by 1080 on a 2560 by 1440 panel, when the setting they want is the scale, "Change the size of text, apps, and other items," which makes everything bigger and keeps every light. At a lowered resolution the graphics card or the monitor stretches the whole picture onto the lights after Windows has finished with it, and Microsoft's own page says that "text won't look as sharp." Every number a program can read still says the display resolution is the panel, so Fuji cannot tell, and neither can anything else running on the machine.

The platform and the user's display settings decide the two ratios between the screen's three grids, and these are the common cases:

screen	backing per CSS	panel per backing
an ordinary monitor on a Mac, or on Windows at 100 percent	1	1
a Windows laptop at 125, 150 or 175 percent	1.25, 1.5 or 1.75	1
a Retina Mac at exactly half its panel, like the MacBook Air at "looks like" 1280 by 832	2	1
a Retina Mac in a scaled mode, like the MacBook Air at "looks like" 1710 by 1112	2	about 0.75
a Windows monitor set below its own resolution, like 1920 by 1080 on a 2560 by 1440 panel	1	about 1.33

Wherever the last column is 1, the lights are in reach, and Fuji reaches them: with R on, a number key whose backing ratio is whole puts every image pixel on an exact square of lights in its own color, one light at 1 on an ordinary monitor, two by two at 1 on a Retina Mac at half its panel, and three by three at 2 on a Windows laptop at 150 percent. Wherever the last column is not 1, no size reaches them. Take a 256-pixel GIF on the MacBook Air at "looks like" 1710 by 1112. Painted 256 backing pixels across, it is clean in the backing store, and macOS delivers it to the glass 192 lights across and soft. Painted to reach the glass 256 lights across, its true size, it has to be 342 backing pixels across, so the paint blends its pixels before macOS resamples them a second time. Clean in the bitmap and the wrong size on the glass, or the right size and smoothed twice, and no program can choose a third way. The display settings can, and they are the user's: on a Mac the mode at exactly half the panel, and on Windows the panel's own resolution with a larger scale.