>>>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
Reply by Frank Bemelman●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 terry●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 Paul Keinanen●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 results
About 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 Tim Mitchell●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 Roland Mathijssen●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 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?
Cheers
Roland
Reply by Tim Mitchell●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 Jim Stewart●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.
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!