Send Images To Your Terminal With Rich Pixels

September 13, 2025 by Donald Papp 10 Comments

[darrenburns]’ Rich Pixels is a library for sending colorful images to a terminal. Give it an image, and it’ll dump it to your terminal in full color. While it also supports ASCII art, the cool part is how it makes it so easy to display an arbitrary image — a pixel-art rendition of it, anyway — in a terminal window.

How it does this is by cleverly representing two lines of pixels in the source image with a single terminal row of characters. Each vertical pixel pair is represented by a single Unicode ▄ (U+2584 “lower half block”) character. The trick is to set the background color of the half-block to the upper pixel’s RGB value, and the foreground color of the half-block to the lower pixel’s RGB. By doing this, a single half block character represents two vertically-stacked pixels. The only gotcha is that Rich Pixels doesn’t resize the source image; if one’s source image is 600 pixels wide, one’s terminal is going to receive 600 U+2584 characters per line to render the Rich Pixels version.

[Simon WIllison] took things a step further and made show_image.py, which works the same except it resizes the source image to fit one’s terminal first. This makes it much more flexible and intuitive.

The code is here on [Simon]’s tools GitHub, a repository for software tools he finds useful, like the Incomplete JSON Pretty Printer.

Forget Pixel Art: Try Subpixels

November 23, 2024 by Al Williams 22 Comments

[Japhy Riddle] was tired of creating pixel art. He went to subpixel art. The idea is that since each color pixel is composed of three subpixels, your display is actually three times as dense as you think it is. As long as you don’t care about the colors, of course.

Is it practical? No, although it is related to the Bayer filter algorithm and font antialiasing. You can also use subpixel manipulation to hide messages in plain sight.

Continue reading “Forget Pixel Art: Try Subpixels” →

Pixel Art And The Myth Of The CRT Effect

August 3, 2024 by Maya Posch 61 Comments

The ‘CRT Effect’ myth says that the reason why pixel art of old games looked so much better is due to the smoothing and blending effects of cathode-ray tube (CRT) displays, which were everywhere until the early 2000s. In fits of mistaken nostalgia this has led both to modern-day extreme cubism pixel art and video game ‘CRT’ filters that respectively fail to approach what pixel art was about, or why old games looked the way they did back with our NES and SNES game consoles. This is a point which [Carl Svensson] vehemently argues from a position of experience, and one which is likely shared by quite a few of our readers.

Although there is some possible color bleed and other artefacts with CRTs due to the shadow mask (or Sony’s Trinitron aperture grille), there was no extreme separation between pixels or massive bleed-over into nearby pixels to create some built-in anti-aliasing as is often claimed unless you were using a very old/cheap or dying CRT TV. Where such effects did happen was mostly in the signal being fed into the CRT, which ranged from the horrid (RF, composite) to the not-so-terrible (S-Video, component) to the sublime (SCART RGB), with RGB video (SCART or VGA) especially busting the CRT effect myth.

Where the pixel art of yester-year shines is in its careful use of dithering and anti-aliasing to work around limited color palettes and other hardware limitations. Although back in the Atari 2600 days this led to the extreme cubism which we’re seeing again in modern ‘retro pixel art’ games, yesterday’s artists worked with the hardware limitations to create stunning works of arts, which looked great on high-end CRTs connected via RGB and decent via composite on the kids’ second-hand 14″ color set with misaligned electron guns.

A LEGO CNC Pixel Art Generator

June 14, 2024 by Jenny List 2 Comments

If you are ever lucky enough to make the trip to Billund in Denmark, home of LEGO, you can have your portrait taken and rendered in the plastic bricks as pixel art. Having seen that on our travels we were especially interested to watch [Creative Mindstorms]’ video doing something very similar using an entirely LEGO-built machine but taking the images from an AI image generator.

The basic operation of the machine is akin to that of a pick-and-place machine, and despite the relatively large size of a small LEGO square it still has to place at a surprisingly high resolution. This it achieves through the use of a LEGO lead screw for the Y axis and a rack and pinon for the X axis, each driven by a single motor.

The Z axis in this machine simply has to pick up and release a piece, something solved with a little ingenuity, while the magazine of “pixels” was adapted with lower friction from another maker’s design. The software is all written in Python, and takes input from end stop switches to position the machine.

We like this build, and we can appreciate the quantity of work that must have gone into it. If you’re a LEGO fan and can manage the trip to Billund, there’s plenty of other LEGO goodness to see there.

Continue reading “A LEGO CNC Pixel Art Generator” →

side by side of upscaling in the AGI engine

Upscaling The Sierras

June 13, 2022 by Matthew Carlson 22 Comments

If you played many games back in the mid-80s to 90s, you might remember the iconic graphics from Sierra’s Online Adventure Games. They were brightly colored (16 colors) and dynamic with some depth. To pay homage, [eviltrout] worked to upscale the images. Despite being rendered at 160×200 at 16 colors and then stretched, storing all those bitmaps even at only 4 bits per pixel would take all the storage available on the floppy disk. The engineers on the game decided instead to take a vector approach to a raster problem.

When [eviltrout] came through to try and upscale the backgrounds, he started by writing some code to extract the draw commands from the engine of the game, known as Adventure Game Interpreter (AGI). Comparing the vector commands to equivalent PNG versions with the best compression, the AGI vector versions were around half the size. Not bad for a couple of game developers in the 80s. Since it is all vector commands under the hood, it should be relatively simple to draw them at a much higher resolution. At least, that’s what he thought. The first issue was with flood fills. Since the canvas is larger, there are gaps between lines, and the flood escapes. A few approaches were taken, such as using a low-resolution reference and marching squares, but neither was satisfactory. Eventually, [eviltrout] expanded flood fills and used thicker lines. He also first rendered to a lower resolution and connected neighboring lines of the same color. Finally, he used ImageMagick to denoise white specs in the output.

We find the effect charming, but some might say you’re distorting art into what the artist never intended to be. But, as with all graphical enhancements, some artistic liberties are being taken without the original artist involved. The code is available on GitHub under an MIT license. Video after the break.

Continue reading “Upscaling The Sierras” →

Alien Art Drawn With Surprisingly Simple Math

April 13, 2021 by Michael Shaub 20 Comments

Programmer [aemkei] Tweeted the formula (x ^ y) % 9 alongside code for more “alien art”. But how can a formula as simple as (x ^ y) % 9 result in a complex design? The combination of Bitwise XOR (^) and Modulo (%) generate a repeating pattern that’s still complex enough to satisfy the eye, and it’s ok if that doesn’t sound like an explanation. Bitwise operations are useful when working with memory and shift registers, but also worth learning if you want to drive lines or matrices of LEDs or interpret combinations of multiple switches, or in this case a great way to throw an interesting test pattern up on a new flip-dot display or low-res LED matrix. Are you into it? We are, so let’s jump in.

XOR Truth Table
	0b00	0b01	0b10	0b11
0b00	0b00	0b01	0b10	0b11
0b01	0b01	0b00	0b11	0b10
0b10	0b10	0b11	0b00	0b01
0b11	0b11	0b10	0b01	0b00

Bitwise XOR compares each binary digit of the two inputs. The XOR returns a 1 when only one of the two digits is a 1, otherwise, it returns a zero for that position. Let’s say the coordinates were 3, 2. Converted to binary we have 0b11 and 0b10. From this truth table, we can see the most-significant digits are both 1, returning a 0, while only one of the least-significant digits is a 1, so the comparison returns a 1.

Moving onto the %, which is the Modulo operator has nothing to do with percentages. This operator divides two numbers and returns the remainder if any. Take 9 % 5. When dividing 9 by 5, 5 goes in once with a remainder of 4 so 9 % 5 = 4. Now our original formula from the top will draw a black box for every ninth number except that the bitwise XOR throws a wrench into that count, varying how often a number divisible by 9 appears and supplying the complexity necessary for these awesome patterns.

What are the most interesting designs can you create in a simple formula?

The Game Boy Camera, Or: How I Learned To Stop Worrying And Love The Pixels

October 26, 2020 by Erin Pinheiro 11 Comments

Never underestimate the power of nostalgia. In an age when there are more megapixels stuffed in the sensor of a smartphone camera than the average computer display can even represent, why would jagged images from a 20-year-old grayscale camera with pixels numbering in the thousands still grab attention? Maybe what’s old is new again, and the coolness factor of novelty is something that can’t be quantified.

The surprise I had last Monday when I saw my Twitter notifications is maybe only second to the feeling I had when I was invited to become a Hackaday contributor. I’d made a very simple web app which mimics a Game Boy Camera using the camera from your phone or desktop, and it got picked up by people so much that I’m amazed my web host is still holding. Let’s look at why something seemingly so simple gained so much traction.

Continue reading “The Game Boy Camera, Or: How I Learned To Stop Worrying And Love The Pixels” →