Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Image compression

Author
Message
David T
Retired Moderator
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: England
Posted: 23rd Aug 2003 19:44 Edited at: 23rd Aug 2003 20:22
Link
Hi,

I'm working on an image compression routine in DBPro.

So far I've got about a 30% decrease in file size. However, one thing I'd really like to do and know how to do in practice is to trap repeated blocks, like so:

1 1 1 1 1 1 1 1 2 2 2

would be stored as

8 lots of 1 : 3 lots of 2

thus taking up much less space. However, I've no idea how to code this. If anybody has any ideas / suggestions about how to do this or how to compress an image further, please post

There's no place like 127.0.0.1

There are 10 people in this world, those who understand binary and those who don't.
Back to top
Profile PM Email Website
OSX Using Happy Dude
22
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 23rd Aug 2003 19:48 Edited at: 23rd Aug 2003 19:49
Link
It works something like :

Get a byte. Get another byte. If the two are the same then read a byte until the value read is different from the starting two. You then store the number of duplicates, after storing the intitial 2 bytes.


Back to top
Profile PM Email Website
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 23rd Aug 2003 19:53
Link
So you might reserve a byte value of 1 to 127 as the number of repeats of the next character (so 1 to 127 repeats), and byte values of 128 to 255 less 127 for the number of literal bytes that follow.

You might also think of using 32 bit values instead of 8 bit, coz that would remove repeating colours.
Back to top
Profile PM Email Website
David T
Retired Moderator
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: England
Posted: 23rd Aug 2003 20:21 Edited at: 23rd Aug 2003 20:26
Link
Quote: "It works something like :

Get a byte. Get another byte. If the two are the same then read a byte until the value read is different from the starting two. You then store the number of duplicates, after storing the intitial 2 bytes."


Thank for the replies guys

That was initial idea, the challenge would be to code it (it sounds so simple on paper, yet my first attempt was rubbish).

Currently I'm saving an image from the screen, so I have a 2D array to play with. However, when I modify it to read directly from a bitmap, it'll be easier then

IanM: I don't understand about how using 32-bit values can trap repeating colours (I don't understand much about bytes actually, apart from how much they can hold and the binary logic behind them) but if it helps here's the file format at the moment:



There's no place like 127.0.0.1

There are 10 people in this world, those who understand binary and those who don't.
Back to top
Profile PM Email Website
David T
Retired Moderator
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: England
Posted: 23rd Aug 2003 21:21
Link
Well I managed to work out how to code the repeat trapping code, and now at 50% quality an image that as a BMP took 124kb takes 9kb

Time to read it back now - I'm a bit worried about that.

There's no place like 127.0.0.1

There are 10 people in this world, those who understand binary and those who don't.
Back to top
Profile PM Email Website
OSX Using Happy Dude
22
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 23rd Aug 2003 21:43
Link
Its a very easy compression routine to code - the de-compression system is almost as easy too. Of course, the only problem is that you will only get a 'good' compression rate with data that has lots of repetative data (like music files and probably graphics).


Back to top
Profile PM Email Website
David T
Retired Moderator
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: England
Posted: 23rd Aug 2003 22:22
Link
Quote: "Its a very easy compression routine to code - the de-compression system is almost as easy too. Of course, the only problem is that you will only get a 'good' compression rate with data that has lots of repetative data (like music files and probably graphics)."


My only problem now is that somewhere along the way all of the tokens held in the original array turn into stupidly large negative numbers - something that reeks of arrays being out of bounds.

There's no place like 127.0.0.1

There are 10 people in this world, those who understand binary and those who don't.
Back to top
Profile PM Email Website
OSX Using Happy Dude
22
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 24th Aug 2003 00:18 Edited at: 24th Aug 2003 00:21
Link
Why are you using arrays to aid the compression, if your using the compression system mention by me ? Its 'designed' to work on the fly with only around 4 or 5 variables, and no need for tables


Back to top
Profile PM Email Website
David T
Retired Moderator
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: England
Posted: 24th Aug 2003 00:49
Link
What I have to work with is an array of an image. It's loaded from the screen using point().

I do not read directly from a BMP file so I don't exactly enmulate your idea. I know that's slow and inefficient but that's me

- I then run through the array and create a palette for the image, replacing each entry in the array with a token.

- The colour data would also be reduced here.

- The 2D array is transformed into a 1 string of bytes. Then I would remove all repeats and write the info to a file.

And for reading back, I would read back the file sequentially and not use arrays.

Plus, I think I've found my bug

There's no place like 127.0.0.1

There are 10 people in this world, those who understand binary and those who don't.
Back to top
Profile PM Email Website
OSX Using Happy Dude
22
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 24th Aug 2003 01:09 Edited at: 24th Aug 2003 01:11
Link
Fair enough

Its a pretty good compression system (whilst there is repetitive data), but as soon as there isn't you'll start to find the compressed data takes up more disk space that the uncompressed version!


Back to top
Profile PM Email Website
David T
Retired Moderator
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: England
Posted: 24th Aug 2003 01:12
Link
Well I then fall back onto the other 2 compression system to help me out

I finally got the loader working - time to test it on a photo. I got 85kb lossless ocmpression before - let's try it with the new repeat-trapping routine...

There's no place like 127.0.0.1

There are 10 people in this world, those who understand binary and those who don't.
Back to top
Profile PM Email Website
David T
Retired Moderator
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: England
Posted: 24th Aug 2003 01:21
Link
Ok final test for the night:


PHOTO:

original BMP = 124kb

compressed quality 1 (lossless) - 19,000 distinct colours = 200kb
compressed quality 10 (lossy) - 900 distinct colours = 108kb

SIMPLE GRADIENT:

original BMP = 124kb
compressed ~ 8-10kb

There's no place like 127.0.0.1

There are 10 people in this world, those who understand binary and those who don't.
Back to top
Profile PM Email Website
OSX Using Happy Dude
22
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 24th Aug 2003 01:34
Link
Not bad at all...


Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2026-07-23 15:49:34
Your offset time is: 2026-07-23 15:49:34