shpaint: For the Toulouse-Lautrec of the terminal

Part of the fun in spending two and a half years sifting through random text-based software has been the occasional joy in finding something amazingly cool. On occasion I’ve stumbled over stuff I didn’t even think was possible, and yet there it is, in plain view.

That’s Martin Bruchanov’s shpaint, which is a simple, mouse-driven ANSI art editor for terminal emulators. You can probably figure out how to use shpaint just by looking at that screenshot; click on a foreground color, a background color and a glyph, and click away until your artwork is complete.

It’s all the more impressive when you realize it’s written in bash. And to really blow your mind, Martin points out that it’s done in only 180 lines of bash. 😯

If I have 180 lines to work with, I’m lucky if I get “Hello, world” to appear on the screen.

shpaint isn’t perfect, but that doesn’t detract from its coolness. For one thing, it doesn’t work in a virtual console; I tried to fire up gpm and draw my rendition of the Mona Lisa (imagine a stick figure in garish colors), but apparently shpaint doesn’t work that way.

shpaint also can’t really do more than plot a glyph at a time. No line functions or paint-fill buckets. You have to do this old-school, like we used to do things back in the 80s.

Martin admits that occasionally something goes haywire between shpaint, bash and the terminal emulator, and clicking a cell will cause weird and random painting effects. That happened to me once or twice, but the fix is easy — just exit shpaint with CTRL+C, which saves your file automatically, then restart it and all is well.

shpaint sends your rendition of Whistler’s Mother to a flat file that will spill out the same image just with the cat command, meaning you can probably work this into other, more advanced editors to handle more intricate touchup. Don’t feel guilty doing that; our artist at work regularly sketches with a pencil, then scans her work into a computer and does everything else in Photoshop.

In fact, I’m no Picasso, but I daresay there are probably some parts of text-based artistry that would be well-served by relying on shpaint as an option to aewan, cavewall or duhdraw, even if it’s just for the speed of plotting points with the mouse, as opposed to cursor controls.

shpaint wins points from me just for being amazing and cool, but also for doing its job cleanly, obviously and without unnecessary bloat. I know this technically falls down on some of the points I like to see in text-based programs, but I think it deserves a star anyway: ⭐ Give it a try. 😉

driftnet: Dutifully duplicating

I’ve been tinkering with driftnet over the past day or so, in a little experiment born out of a suspicion that a web site was preloading images before a link was clicked. It’s completely out of context for this site, but it did introduce me to another console tool.

Mostly I want to keep a note of driftnet here, because I have a feeling I will want to use it again in the future.

And to be honest, as far as driftnet’s console output, there isn’t much to see. In its “default” form, driftnet sends its findings to a viewer window, which suggests it is more intended for a graphical audience anyway.

But it does have an “adjunct” mode that omits that. Instead it keeps a running list of images it senses, and otherwise follows its standard operating procedures. Armed with that much function, you could make a case that it has a nongraphical format as well. (It supposedly can also sense audio files that are transferred, but I didn’t test that.)

And as you can see in that wide and spacious screenshot above, it does a good job grappling with images that pass through an interface, and stashing them for your later perusal.

Of course, the obvious uses for driftnet would be threefold: (1) too keep a local copy of images that your machine retrieves, (2) to access images that are otherwise unsave-able from a browser, or (3) to later accuse some miscreant of abusing their Internet access privileges by requesting images that are inappropriate. 😡

There may be other applications; however you use it, in its console-only format it should be lightweight enough to run in a spare tty, and duly make duplicates of what activity transpires.

driftnet is in Debian-based distros as you can see above. It’s also in AUR but neither the GTK nor Debian patch version would build for me. I didn’t work to hard to get an Arch copy though; it may be acceptable just to hijack the binary from Debian and run from there. 😉

cam and cam: One for the eyes, one for the ears

In a rather odd twist, I have two programs entitled “cam,” one which has a visual focus, and another which has an audio purpose. Let’s start with the eyes.

And I am beginning to believe that tools that translate from standard image formats to terminal output are not so rare after all.

This cam is available in the AUR as cam-git, but to be honest, the version given there wouldn’t build for me.

However, following the instructions on the home page made a workable cam, and as you can see, it converts our old pal Smiley into its text-only version with no real effort. It also manages a fair representation of the original colors, and shades things appropriately where it can.

cam also squeezes its output to fit the current terminal dimensions, without losing the aspect ratio — something I liked in the last converter we saw, and in others from years past.

cam seems eager to take on the role of a slideshow tool as well, with options for pausing between separate image files, preset looped shows, sizing in proportion to the terminal dimensions, and eight- or nine-position alignment that overwrites the current terminal content. It’s a nifty effect.

This cam is a solid thumbs-up in terms of graphics viewing for console environments, and unless you have something specific that you need from another converter tool, it might usurp others you already know.

Here’s the other cam, which is an acronym for CPU’s Audio Mixer. I’ve looked high and low for a home page for this cam, but the only sites I can see in the source code, and the only addresses I find in the Debian packages are all dead.

Which might be a foregone conclusion, since cam’s source codes show dates as early as 1994, and I don’t expect the home page for an OSS-era audio mixer to survive 20 years until now. Not that it can’t be done, only that it doesn’t surprise me if it didn’t.

This cam seems to work well in hand with alsa-oss, but the only mixer controls I can muster are the ones you see in the screenshot.

I also can’t account for the oddball characters used in cam’s display, but I’m willing to either chalk that up to cam’s age, or to my less-than-expert setup, or using the Mint live environment. Any one or all could be a factor there.

This second cam might be a little less useful for those reasons, but it also has most of the requisites I look for in a decent console application — good use of color, onboard help and key cues, and a straightforward focus that doesn’t wander all over the map.

Still, it’s good to know it’s available, even if it’s not altogether as employable as it may have been. 😦

jp2a: Jack be nimble, Jack be quick

Quick, nimble, short and fast programs are always to my liking. We’ve been through plenty of image-to-text converters for the console, but here’s one that just plain works, on the first try: jp2a.

 

I’m showing two screenshots there because I wanted to point out one small thing about jp2a that I really like: It’s smart enough by default to keep the original aspect ratio, and confine it to the available terminal space.

I know that seems like a small issue, but the original smiley face image that I used was 1024×1024, and some utilities try to convert that as pixel-to-character, on a one-to-one basis. Which complicates things.

jp2a can certainly do that, and if you dig through its flags you’ll see that it can do quite a bit more too. I used only the --colors flag to generate the images above, but you can set output dimensions, redirect to a file, flip an image on conversion, put borders on output and a mess of other options.

If you’re looking for a quick, fire-and-forget conversion tool this might be the one. And given that it has only libjpeg (and curl) as its dependencies, it definitely won’t burden your system with random and impractical features that draw in obtuse libraries.

And once you’ve got your conversion tucked away, you’re only a hop, skip and a jump away from completing your text-only masterpiece. Don’t forget to invite us to the unveiling. 😉

duhdraw: For the Van Gogh of the vc

duhdraw, as I understand from the home page, has been around for almost 20 years in one form or another, and has its beginnings as an offshoot of a DOS program called TheDRAW. And so if you’re familiar with accents among native English speakers, you may better understand that name. 😉

Having a near 20-year history may make it look weak when compared to tools like aewan or cavewall, or even cadubi, but duhdraw might still have a few tricks up its sleeve.

That is not the world’s strongest screenshot, and for that I apologize. That was my passive-aggressive way of pointing out that duhdraw, regardless of your terminal dimensions, is going to confine itself to that small window.

Your canvas will actually stretch down to about 1000 lines, if the README file is to be believed, but width-wise, 80 appears to be its limit.

And the unreadable characters there in the screenshot are supposed to be “high ASCII” characters — pipe symbols and others, I believe — but were not properly rendered by my framebuffer …. or by rxvt-unicode, which was more disappointing. It may be a sign of its age, but apparently duhdraw had trouble reaching that high.

Most of duhdraw’s features are accessible through ALT keys, so the help screen, for example, is ALT+H. Erasing the canvas and starting over is ALT+E. Saving is ALT+S and loading is … well, you get the picture.

I found a copy-and-paste feature, such as was in cavewall or aewan, but it seemed quite primitive (or perhaps was incomplete) to me and hard to control. No transparent stamp effects or editable polygons, sorry.

duhdraw is not without its own interesting gimmicks though. ALT+D enters a line drawing mode, where just moving the cursor begins a continuous line you can control.

And I like the pickup commands of ALT+P and ALT+U, where you can instantly adopt the character and the color scheme of any character on the screen, and use it elsewhere. It’s quicker than running back and forth to the ALT+F keys for the color palette. And attribute mode is even easier, turning your cursor into a sopping wet paint roller, wherever you go on the screen.

And to be honest, trapping commands against the ALT keys is a good way to do business, since it frees up virtually every other key as a stamp, without losing out to shifted characters or special sequences. I like the way duhdraw does that.

It’s unfortunate that I couldn’t see all the characters duhdraw offered, because I have a feeling that duhdraw had more interesting approaches to ASCII art than just what the bigshots like aewan or cavewall could offer.

But duhdraw is not the do-all, be-all end of the line for ASCII art tools. In fact, if anything, it may be just the beginning, or as close as Linux users could get in 1996. 😎

aewan: For the Klimt of the console

I’ve seen about three or four ASCII art editors for the console now, and it’s becoming clear that each one has unique features that are very appealing, but misses out on something another one offers.

After I found cavewall, I figured any other ASCII art editor was going to fall flat. After all, cavewall had a slew of features that I hadn’t thought possible in text-art program, and didn’t expect to see again.

And along came aewan.

The ASCII Editor Without A Name actually includes layer management, much like you’d see in GIMP or That Other Graphics Program which shall go unnamed and unlinked. The one that starts with “foto” and ends with “shoppe.”

If you’re skeptical, so was I, but aewan pulls it off quite gracefully. And those layers are the key to copy and pasting, moving blocks of images, creating stamp pad effects and even transparent stamping. It’s amazing.

You can add dozens of layers to text drawings, set their visibility, name them and rearrange them. Set their dimensions and move them around until you complete your masterpiece.

aewan has hotkeys for the color palette, a menu-driven interface with key commands for some of the most important features, and can save all your work into a file that (supposedly; I didn’t try it) can be used in a pager to display animation effects.

Wow. 😯 That’s impressive for a program that saw its last update in 2005. My hat is off. Again. For that alone, an incredibly rare and immeasurably valuable K.Mandla gold star is warranted: ⭐ Well done.

But … I can see where some features from cavewall don’t appear in aewan. cavewall has adjustable stepping features for example, making line drawing and the like more convenient. aewan doesn’t have that, or if it does, I don’t recall seeing it.

aewan does have a specific line-drawing mode though, and that’s quite handy. Pressing the hyphen or pipe symbol actually draws the appropriate extended line, so you can draw in continuous bars, instead of just the text character. But vertical lines aren’t as easy with aewan as they are with cavewall.

And neither aewan nor cavewall has the polygon drawing and editing features that were in textdraw. But that’s only black-and-white, and so loses an edge to cadubi, which behaved more like a colorized stamping program that could import images rendered by caca, and edit them.

So I’m at the point now where each of these has a particular feature that makes it shine, but misses out on something mastered by its brethren. Perhaps at some point a Grand Unifying Text-Based Art Tool will appear. And it shall be known as GUTBAT, and the people shall rejoice. … 🙄

cavewall: For the Kahlo of the console

I had to scrounge around the Internet for a while, before I could find the home page for cavewall. It was worth it:

cavewall is another ASCII “image editor” allowing you to draw and create pictures using text symbols and so forth. We’ve seen a few of these in the past, to include classics like cadubi, or hidden gems like textdraw.

A lot of the files that are in the latest cavewall tarball date back to 2006 or even earlier. I didn’t expect it to compile, but as you can see, it worked more or less flawlessly.

For as hard as it was to find cavewall, it’s a huge step forward in ASCII drawing programs. It has, for example …

• Block selection and range functions, which is a huge addition, because it adds things like …
  • Copy and paste functions
  • Fill functions
  • Paste from clipboard options
  • Custom box and frame creation, and more
• Stepping modes, so pressing a character moves you in a specific direction — not just to the right
• Menus for most program functions, plus hotkeys for the most common ones
• Export to plain text or HTML
• Import back from those formats

And a lot more. cavewall manages to take a lot of cadubi’s high points, and some of textdraw’s best functions, then add a few bonuses of its own, and combine them all in a very usable way.

It’s clear not everything is finished (I would have loved to see the “inject figlet-ized text” feature work), and it needs a little polishing on some points (the menus are sometimes obtrusive, or overwrite themselves, and cavewall intercepts some command sequences as text … small points). But the majority of it seems to be working.

Like I said, cavewall doesn’t appear to have seen attention in almost a decade. Very rarely do I wish for someone to adopt a program and bring it up to date (well, okay, sometimes I do), but cavewall is so very nearly perfect, that it’s sad to see it languish unnoticed in a corner of the Internet. 😦

I’m going to give cavewall a great big shiny gold K.Mandla star though, in the hopes that someone will see its potential and give it the boost it deserves: ⭐ 😉 Enjoy!

Bonus: fbff, fbpad … and fbpdf too

I do feel obligated to list some framebuffer-specific software here, and I realized a week or two ago that my last list of framebuffer applications was not only almost a year old, but also omitted a worthy pair.

I don’t have much to show for fbff and fbpad, but they are both by the author of fbpdf, and mentioning one without the other two was an oversight. To complicate things, I don’t have a machine right now that will take faithful images of framebuffer output, so here’s my best effort at fbff, and to be fair, fbpdf.

 

Laughable, I know. Just don’t ask about fbpad. 🙄

fbff is probably my favorite of the three, as an alternative to running mplayer against the framebuffer. At 2Ghz on an ATI Mobility Radeon 7500 with an xvid-encoded avi file, the results were quite good. If you could see what it was showing, you’d be watching the opening credits for the first episode of season 11 of Gunsmoke. 😕 (Sorry, in my culture, people are mad for anything Western.)

And if you could see fbpdf at work above, it would be a classy black-and-white page with the words, “Sample text here.” I am nothing, if not inventive. 🙄

Please don’t blame the software for the shortcomings you see there. Both fbff and fbpdf accurately rendered the media against the framebuffer, and offered basic controls for each application. In spite of what you see above, they did actually work right. I just lack a proper screenshot.

fbpad was another issue, but that one was working against the clock for me. Configuring fbpad requires some heavy-duty font setup, the use of an outside font conversion tool, then editing the source code and recompiling fbpad to show the converted font.

I can’t say this is a better way than, perhaps, configuring fbterm. If you wade through those steps, show us a screenshot and we’ll all think highly of you. 😉

Dependency-wise, fbff and fbpdf were the heaviest, with fbff pulling in the ffmpeg structure (of course) and fbpdf requiring mupdf, some poppler and some djvulibre. If you have other options for video/audio/image playback and pdf display at the framebuffer, I’d recommend weighing them against what fbff and fbpdf will need.

fbpad didn’t strike me much heavier than fbterm, truth be told — unless you count the time and tools it would take to convert and configure and compile the font. And that, knowing full well I wouldn’t get a proper image of it anyway. 😦

One last question you might ask: So why make so much fuss about a couple of framebuffer-based applications? Well, for one thing, alternatives to the industry-standard tools, like mplayer or fbida, are always welcome. Neither of those is such a perfect fit for a framebuffer-only machine that someone new can’t wedge their way into my system.

Second, and probably more importantly, access to a framebuffer can sometimes be what saves a machine from the eternal reward. There’s a big difference between a 233Mhz machine that can run text programs fullscreen at 80×25, and a 233Mhz machine that can run a full suite of terminal applications at 1024×768 using the terminus font overlaid atop a picture of Miles Davis.

One is functional, but the other is crazy, funky and cool. 😉

imgcurses: Best of most worlds

My quick run-in with img2xterm yesterday reminded me that I have another curses-based image viewer in my list: imgcurses. If you’ve ever used something like fbida or fim, imgcurses might strike you as the best amalgamation of a framebuffer image viewer and a strict console environment.

With imgcurses you can get from this to any of these:

   

imgcurses has four “modes” that it supports, in the way it renders the image to text-only format. Depending on the image, one mode or another might be the best representation. (The last mode, “detail,” can be somewhat taxing to render, so be patient when you switch to it.)

The best parts of imgcurses are in the simple controls it offers. Left and right square brackets zoom the image in your viewing window, “m” changes the mode and “q” quits the program.

You can see a small on-screen display too, showing the original dimensions and zoom setting, and the mode you’re using. That’s about it.

imgcurses fills in a lot of the gaps that some others — like img2xterm — omit … like fitting an image to your available terminal space. So you won’t have to resize your image before you view it.

I don’t see controls for some higher-level image functions, like rotating or flipping, so you might have to rely on imagemagick for that. And according to the home page, imgcurses only handles JPEG, PNG and TGA formats.

I like this though, and plan to include it on my next text-only systems. It handles the task gracefully, gives a few options for display, and doesn’t overburden my system. Good show all around. Have a star: ⭐ 😉

img2xterm: Dot by dot, block by block

For img2xterm, the idea is to translate from conventional images to block characters visible in a terminal emulator. I say that up front because if you try this in a virtual console, I’m fairly certain you won’t get quite the same results.

To be fair, usually when I say, “You can’t do this in a virtual console,” I go straightaway and try it, to make sure I’m not being stupid. This time it honestly did work, but the results were rather … alarming. The image was there, but Smiley looked a little sinister. 😯

Be that as it may, what’s happening is a translation from pixel to block character, staying faithful to the color, shade and even a certain degree of visual accuracy. It’s rather impressive, when you think about it: img2xterm take make a picture on your screen pixel by pixel, and convert it into block character sequences that your terminal understands.

A couple of caveats though: Note that I said “pixel by pixel.” That means exactly that: It’s a one-to-one representation of the image you feed it. img2xterm — as far as I can tell — doesn’t resize images to fit your terminal, it only translates between the two “modes.” That means if you feed it a 1600×1200 image, it will faithfully trudge through 1,920,000 pixels, dumping its best efforts to your terminal, scrolling and scrolling and scrolling until it finishes the entire field.

So … you’ll probably want to resize your image first. 😉 What you see above was shrunk for a 114×46 terminal, and probably could have been shaved down a little more.

Second, the output is terminal escape sequences, which you can see if you dump img2xterm to a file and open it in a text editor, or if you use the img2cow utility. So while things like caca or aalib are converting to text and shade or color, img2xterm is using block characters to “render” the results. It can look a little different.

All that aside, this is a nifty tool for making custom logins, converting small-scale icons or images into text-based artwork, or … or you decide. I am sure you can think of one or two things to do with this. 😀