Hi, I want to store 16x16 font image in EEProm. My MCU Rom size is 512. So the total number of fonts stored is 512*8/16/16=16. Do anyone know if there exist font compression algorithm in the world which can compress one font in the eeprom so that I can get more fonts. Thanks!
Font compression and decompression
Started by ●July 21, 2004
Reply by ●July 21, 20042004-07-21
terry wrote:> Hi, > > I want to store 16x16 font image in EEProm. My MCU Rom size is 512. So > the total number of fonts stored is 512*8/16/16=16. Do anyone know if > there exist font compression algorithm in the world which can compress > one font in the eeprom so that I can get more fonts.Just off the top of my head, I'd say that run-length encoding would save you quite a bit. Here's a link: http://datacompression.info/RLE.shtml
Reply by ●July 22, 20042004-07-22
In article <Xd2dnRHg4K9wWWPdRVn-hQ@omsoft.com>, Jim Stewart <jstewart@jkmicro.com> writes>terry wrote: >> Hi, >> I want to store 16x16 font image in EEProm. My MCU Rom size is 512. >>So >> the total number of fonts stored is 512*8/16/16=16. Do anyone know if >> there exist font compression algorithm in the world which can compress >> one font in the eeprom so that I can get more fonts. > >Just off the top of my head, I'd say >that run-length encoding would save you >quite a bit. Here's a link: > >http://datacompression.info/RLE.shtml >but you'd have to have enough RAM to store the decompressed results -- Tim Mitchell
Reply by ●July 22, 20042004-07-22
"Tim Mitchell" <timng@sabretechnology.co.uk> wrote in message news:jvNxyqH7P5$AFAEz@tega.co.uk...> In article <Xd2dnRHg4K9wWWPdRVn-hQ@omsoft.com>, Jim Stewart > <jstewart@jkmicro.com> writes > >terry wrote: > >> Hi, > >> I want to store 16x16 font image in EEProm. My MCU Rom size is 512. > >>So > >> the total number of fonts stored is 512*8/16/16=16. Do anyone know if > >> there exist font compression algorithm in the world which can compress > >> one font in the eeprom so that I can get more fonts. > > > >Just off the top of my head, I'd say > >that run-length encoding would save you > >quite a bit. Here's a link: > > > >http://datacompression.info/RLE.shtml > > > but you'd have to have enough RAM to store the decompressed resultsOne only has to store the decompressed characters you need to display. One would expect that there is room for the display info, or am I wrong? Cheers Roland
Reply by ●July 22, 20042004-07-22
In article <cdo5pk$1vs$1@news.tue.nl>, Roland Mathijssen <rolandmathijssen.nospam@yahoo.com> writes> >"Tim Mitchell" <timng@sabretechnology.co.uk> wrote in message >news:jvNxyqH7P5$AFAEz@tega.co.uk... >> In article <Xd2dnRHg4K9wWWPdRVn-hQ@omsoft.com>, Jim Stewart >> <jstewart@jkmicro.com> writes >> >terry wrote: >> >> Hi, >> >> I want to store 16x16 font image in EEProm. My MCU Rom size is 512. >> >>So >> >> the total number of fonts stored is 512*8/16/16=16. Do anyone know if >> >> there exist font compression algorithm in the world which can compress >> >> one font in the eeprom so that I can get more fonts. >> > >> >Just off the top of my head, I'd say >> >that run-length encoding would save you >> >quite a bit. Here's a link: >> > >> >http://datacompression.info/RLE.shtml >> > >> but you'd have to have enough RAM to store the decompressed results > >One only has to store the decompressed characters you need to display. One >would expect that there is room for the display info, or am I wrong? >The way run-length encoding works, you'd need to decompress the whole thing to extract one character. You could do this every time you want a character but it would use up a lot of processor time. -- Tim Mitchell
Reply by ●July 22, 20042004-07-22
On Thu, 22 Jul 2004 11:16:27 +0100, Tim Mitchell <timng@sabretechnology.co.uk> wrote:>>> I want to store 16x16 font image in EEProm. My MCU Rom size is 512.>>Just off the top of my head, I'd say >>that run-length encoding would save you >>quite a bit. Here's a link:>but you'd have to have enough RAM to store the decompressed resultsAbout 16 _bits_ :-) However, you have to select the compression order to be match the display controller protocol or display memory organisation. If the display requires that horizontal scan line is written in a single operation and the lines under it in separate operations, use the same RLE algorithm as in a telefax machines, i.e. use a full horizontal RLE of the _first_ scan line only. When compressing further scan lines, compare the scan line to the line just above it and note the differences. RLE encode the differences. When decoding, uncompress the first line, save it (requires as many bits as the character is wide:-) and write it to the display. When decoding the subsequent lines use the decoded and saved previous line as a starting point and apply changes. If the display expects that a column is written at a time, RLE encode the leftmost column of the character. For subsequent columns, encode differences compared to the column immediately to the left. When decoding RLE decode the leftmost column and save it (requires as many bits as the character height) and write it to display. For the other columns, apply changes to the saved version and write result to display. Paul
Reply by ●July 24, 20042004-07-24
> > > >One only has to store the decompressed characters you need to display. One > >would expect that there is room for the display info, or am I wrong? > >Any algorithm not required to decompres the whole?
Reply by ●July 25, 20042004-07-25
"terry" <leonlai2k@yahoo.com> schreef in bericht news:9904d48.0407211121.b726eb7@posting.google.com...> Hi, > > I want to store 16x16 font image in EEProm. My MCU Rom size is 512. So > the total number of fonts stored is 512*8/16/16=16. Do anyone know if > there exist font compression algorithm in the world which can compress > one font in the eeprom so that I can get more fonts.How do you calcultate that? 512 bytes rom size? 16x16 pixel characters? 512*8/16/16=16 -> characters, not fonts. Not even enough for a complete character set. RLE encoding is a rather simple encoding scheme to implement, and probably the best choice for monochrome bitmaps. Or emulate 14 segment character display, two bytes for each character needed, and draw lines to display your characters, at any size you want. -- Thanks, Frank. (remove 'x' and 'invalid' when replying by email)
Reply by ●July 25, 20042004-07-25
terry wrote:>>>One only has to store the decompressed characters you need to display. One >>>would expect that there is room for the display info, or am I wrong? >>> > > > Any algorithm not required to decompres the whole?Yes, you can get algorithms that are character-aligned, but that can restrict the savings. Compression is a trade off, you need to define before you start: CODE & RAM size that can be used for the algorithm ? EEPROM size needed/available to store the fonts ? Options during un-compress : do they have to come out in raster-order ? Next, you should analyse the characters/fonts themselves, and their bit-spreads, and coherence. The best compression schemes use the non-random nature of the data to best effect, and you can also use the users eyes. Call this compression by pixel reduction :) eg a very simple one, is to take your 16x16 char area, and encode as 8x8 where possible : Customer may decide 4 times as many, but chunkier, soft characters is a good idea. LCDs are workable down to ~5x7 fonts : that's a 7.3:1 compression Or, going further to a 14 or 16 segment stroke- font, and stroke-decode sw, turns the 256 bits into 16 bits, for 16:1 compression. If you design your own 32 segment font, that's 8:1 compression, so you get the general idea. Of course, serial memory is also very cheap, and starts in SOT23 packages... -jg
