i did a run-length encoded version. there is significant size savings.
On Jun 12, 2009 5:31 PM, "Michael Evans" <horse...@hotmail.com> wrote:
Just been looking at the cost/benefit of using an image decoder... Whatever I use would need to be open and make the code bloat worth the image size reduction. (Including code bloat for people that don't want a splash screen)
Standard linux JPG libs are approx 170k - no doubt that size would be significantly reduced as all I would need is basic decode functionality.
- Current BB logo is approx 410k of raw uncompressed data.
- GZIPped BB logo is approx 100k.
- 80% quality JPEG is approx 20k (barely noticeable artefacts)
- 93% quality JPEG, no obvious artefacts, approx 35k
Image data size reduction is good, but code bloat might be a bit bigger than expected...
PNG libraries appears to be much the same size as JPG.
GIF libraries are 32k... hmm, now what was the latest on GIF format woes... :] perhaps not!
I'll poke around, but I'm sure there's a GPL / free-as-in-beer "mini" library out there somewhere...
> Date: Fri, 12 Jun 2009 14:38:18 -0700
> Subject: [beagleboard] Re: Beagle Board Graphic > From: david....@aeroflex.com > To: beagleboa...
> On Jun 12, 4:05 pm, Michael Evans <horse_d...@hotmail.com> wrote: > > - add a new UBoot command "s...
Could something like miniLZO be useful? Or maybe UCL (used in UPX
executable files compressor)?
Many executable file compressors have really small and simple LZ-based
decoders (typically just a few hundreds of bytes of code).
> On Sat, Jun 13, 2009 at 1:30 AM, Michael Evans wrote:
>> Image data size reduction is good, but code bloat might be a bit bigger than
>> expected...
>>
>> PNG libraries appears to be much the same size as JPG.
>> GIF libraries are 32k... hmm, now what was the latest on GIF format woes...
>> :] perhaps not!
>>
>> I'll poke around, but I'm sure there's a GPL / free-as-in-beer "mini"
>> library out there somewhere...
>
> Could something like miniLZO be useful? Or maybe UCL (used in UPX
> executable files compressor)?
Use one of the compression formats already present in u-boot for
loading kernels.
--
Måns Rullgård
ma...@mansr.com
A good point. Additionally, there is such a thing as "lossy
LZ-compression" to evaluate if the best possible size reduction is
wanted: http://membled.com/work/apps/lossy_png/
Good luck.
FM
I think the delay depends a lot on the size of the bitmap and the way
it is decompressed.
I recall that rendering a 640x480 jpeg on a 108 Mhz cpu took about 1
second (and this was heavily optimised code).
Then again if you use RLE things are probably a lot faster (no
transformation, dequantisation etc which is there in jpg).;
FM