X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f996b,bd38886e2812d092 X-Google-Attributes: gidf996b,public X-Google-ArrivalTime: 2002-02-25 14:40:07 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news-x2.support.nl!easynet-monga!easynet.net!dispose.news.demon.net!news.demon.co.uk!demon!xemu.demon.co.uk!dave From: Dave Bird Newsgroups: alt.ascii-art Subject: Re: images to ascii conversion algorithm ? Date: Mon, 25 Feb 2002 21:33:18 +0000 Organization: Smelling--nose Dogs for the Anosmic Message-ID: References: NNTP-Posting-Host: xemu.demon.co.uk X-NNTP-Posting-Host: xemu.demon.co.uk:158.152.196.209 X-Trace: news.demon.co.uk 1014676766 nnrp-08:14861 NO-IDENT xemu.demon.co.uk:158.152.196.209 X-Complaints-To: abuse@demon.net MIME-Version: 1.0 X-Newsreader: Turnpike Integrated Version 5.00 U Lines: 80 Xref: archiver1.google.com alt.ascii-art:15041 In article, Harm Cuppens writes: >Hello all, > >I'm thinking of creating a little program that would convert greyscale >bmp's to ascii art. (I know i'm certainly not the first one to do >this, it's just for fun and learning) > >The conversion from pixels to an ascii character troubles me the most. >I was thinking of grouping chunks of pixel data and then select a >character for that group but what particular character should that be? >What determines the choice for a character. > >If anybody has some info that clears my head up a bit, it would be >appreciated very much. >(don't know if this off topic, if so, sorry) There are a number of ways you might do it. Take the image and make sure it is literally a collection of lines of pixels each presumably 32bits (10bits each R, G and B). For practical purposes it is best to reduce these to 8bits meaning R, G, B, and Spare. To get differentials (outlines) you might want to calculate the colour distance ,/'''R2+G2+B2 and record the popularity (occurrence) of each of the 255 values. You might take >= the most popular occurrence at the high end as definitely being a line. Collapse these into 1 bit, yes or no line present. You can have a table of how many bits correspond to each byte. Filter somehow, only keep bits where there is one \|/ - - /|\ from it too, like (row[n-1]<<1)|(row[n-1])|(row[n-1])>>1 | (row[n ]<<1) |(row[n ])>>1 | (row[n+1]<<1)|(row[n+1])|(row[n+1])>>1 ; You have an interesting problem whether you consider pixels in a panel of fill on/off according to a certain level of colour only. What you might do is cull them down according to the number on so, say, if it is dark then lots of pixels get to be on, but if it is pale then the threshold is low. Squeeze these also into 1 bit per pixel on or off. Then you'd have to look what defines an ascii-character bitmap, maybe 8 pixels wide by 10 high? So you take cells of this form, look to minimise PicBits xor AhrBits across the cell trying each of the possible ascii characters. In this way you might get something which takes accounts of edges and which fits character shape, as well as average darkness, to get something like a humanly produced conversion. For best results, why not combine it with human intervention. A "TV Screen" with buttons down the side to get GIF file, produce edges, (threshold up/down to improve fit), edit edge dots, and so forth. _____ | | / / / \ \ / -- -| Duck! | \__ ____ / \_____/ / \ / \ | Dave@xemu.demon.co.uk /| / You \ / | \ \ / |_\called?/__/ / | |_____________///////// < |____\_______| | |(______________ () \ | \ / () | () | | \\\\\\\\\ \| | __|__ | | _|___/___ \___ | | TWOING !!! __---- ----__\---\_ / __ | ______________________ \____-------------______/ \ / \ / / / / _/ ---| hmm, it theemth | / \ / / / | i thlighly | / $ / / | mithtook | / / / | your meaning there, | | | / | buthtah !!! | \______________// \______________________/ \________/