Help with C# file output compression.

[Josef]

You'd really want some sort of run-length encoding in order to achieve your goal. Run-length encoding would be like looking ahead at all your pixels for groups that are identical and then saving the color information once, along with a little extra info telling how many times in a row to repeat that color. For large areas of uniform color the space savings can be tremendous, but for random or photograph-quality pictures this method usually does not save any space, and could potentially increase the size.

Alternatively, if you converted your colors into a binary stream and then broke that into 7-bit lengths and used the ASCII printable characters, you could store 7 bits for every byte of text, giving you nearly ideal usage of space (7:8), but a 256x256 image would still take up 225KB. The best you could hope for is 170x170.

[Josef]

I'll have to try that next, but my main goal was to make it work universally with any jpeg or bitmap, you just import the pic, select your resolution size, and it makes a compatible E2 file.

Or how about an E2 that reads JPEGs natively? 100KB of jpeg can go a long way. I might even try my hand at this one day. I've got it mostly figured out already. Would require significant decompression time in the E2 though...

[Matte]

What about compressing the colors by using one hex digit or one base 32 digit for each component of the pixel?

[N00bDud3]

Maybe you could try saving it as multiple files, like "Image01", "Image02", etc. and then check the list of files for "Image*.txt" and load each of them, then when you read and reach the end of one, jump to the next.

[Drunkie]

Okay using hex, I can get pictures up to 112x112, and they end up being 99kb. I'm going to try some of the other methods suggested but I really think this is as good as its gonna get. If I really need a hi-resolution picture I'll have to convert this to use the CPU.
Here's the quality so far:

[Black Phoenix]

I'll have to try that next, but my main goal was to make it work universally with any jpeg or bitmap, you just import the pic, select your resolution size, and it makes a compatible E2 file.

It works very good, you can replace very similar colors with one; generally reducing image quality just a tiny bit, but receiving huge compression. You can have 1296 colors in your picture, and use just TWO letters per every entry! Maybe you can fit even more in there; 1296 colors is already enough for most pictures.

[Syranide]

It should otherwise be fairly simple to implement a huffman-encoding/decoding (but instead of on bits, on characters... hex even). Should allow you to considerably cut the size of the files. I realize palettes are far easier, but it would perform worse than RAW for "real" images.

[Drunkie]

So far I'm stuck on hex along with a separating character ';', which allows at the most, a 120x120 resolution picture and equals 99KB.

Maybe you could try saving it as multiple files, like "Image01", "Image02", etc. and then check the list of files for "Image*.txt" and load each of them, then when you read and reach the end of one, jump to the next.

I'm really against loading multiple files, I don't know, something about it seems redundant.

You'd really want some sort of run-length encoding in order to achieve your goal. Run-length encoding would be like looking ahead at all your pixels for groups that are identical and then saving the color information once, along with a little extra info telling how many times in a row to repeat that color. For large areas of uniform color the space savings can be tremendous, but for random or photograph-quality pictures this method usually does not save any space, and could potentially increase the size.

Alternatively, if you converted your colors into a binary stream and then broke that into 7-bit lengths and used the ASCII printable characters, you could store 7 bits for every byte of text, giving you nearly ideal usage of space (7:8), but a 256x256 image would still take up 225KB. The best you could hope for is 170x170.

I totally understand the run-length coding; finding similar groups of pixels and having something define its amount to reduce repetitiveness. But that wont be very efficient for dynamic pictures. As for your second suggestion, the binary stream part, can you explain to me a bit more about it, I don't understand. Thanks.

[GUN]

use more than one text file? when the e2 is done loading the first file, itl start transferring the data to the screen while it starts to load the next file, its probably not how you would want it, but it works.


edit; ignore this post, didn't see page 2, was replying to page 1.

[Drunkie]

Yeah I think I'm gonna break the files into 64kb segments, its the only way to do it I guess.
64kb instead of 100, because 100kb upload hangs the server for 2-3 seconds.