Technically the scrolling is only drawing the edges as required so its not really animation I guess.

The first image test I did was half res 16 colour stored in nibbles. Was just a quick test but did use pucrunch since that's pretty simple. What compression techniques are you using currently and planning to use in the future?

Also when you say 8bit colour you mean 8bit index to a 16bit colour table?

I posted a WikiTI page about making applications for the TI-84+CSE. Maybe you can turn this into a full library with API?

I posted a WikiTI page about making applications for the TI-84+CSE. Maybe you can turn this into a full library with API?

Cool! I've just applied for a WikiTI account as per your suggestion via email the other day too.

Turning this into a library is something I'd love to do. I haven't really looked at this for the last fortnight, but when I get some free time I'll be digging back into it again and seeing what else I can do. I have started preliminary work on 16-colour splash screens / graphics as another alternative, which will help to get image sizes down for those that aren't after a huge colour depth.

Hey James, whats the compression ratio using your huffman program? When I try to use the build.bat file it says that it cant create ab.bin and I dont get the .asm file. I made IViewer and it stores images as app vars and displays them but the max size for the app var is 65400 bytes. I cant fit complex images such as a jungle with a lot of leaves using only RLE unless I reduce the quality to an unacceptable level. From what I've read about huffman compression, it sounds good for text but is it better than RLE for images?

It depends on the image. I'm certainly no expert on compression and the various techniques, Huffman just tends to be the one I use thanks to the tools that Jimmy Mardell made available with Sqrxz.

Did you want to email me the original image you're trying to compress? I'd be happy to see how it works with the program I've been working on (although admittedly, I haven't done any work on it in around a month, but it's still fairly fresh in my mind )

RLE is typically not that great for images that have a lot of detail. Huffman should work better, but i would also suggest trying puCrunch as well (though most puCrunch compressors wont work with anything over 64KB so it may need to be split? (Though im sure this can be rectified)).

EDIT - I tested it with a puCrunch compressor just quickly and it compressed the image down to 50.5% of its original size, which is promising.

Well that said, huffman should fare pretty good as well.

Really with images the ideal compression schemes to use are those that are already established in other OS's, like gif, jpeg, png etc. However there arent any on-calc decompression routines that i am aware of (Perhaps png variants). Either way it would be a good exercise .

I only tried puCrunch since i already had the tools lying around. Bare in mind that with other types of images, puCrunch might not be most viable solution.

My first test with the 84C was an image viewer that uses puCrunch (since it was only a quick test). I did limit this to half resolution (160x120) at 16 colours (pixel index packed into nibbles). Uncompressed images are 9632 bytes, but with compression it can be a lot lower (depending on the image). At 256 colours (standard palette) this would be 19200 bytes for an uncompressed image, with compression bringing it down also ... anyway it was just a test and not as feature filled as this project.

We need a good image viewer and JamesV is the man to do it .

EDIT - Uhuh! Now i see your interest in this project .

http://www.ticalc.org/archives/files/fileinfo/454/45449.html

Looks to work pretty nicely, although the menu messes up a bit in jsTIfied. Ill test it on hardware when i get home.

Yeah jsTIfied is still not very accurate. For example, it lacks 160x240 support and Buttonz is messed up. I guess the calc is just not documented enough to allow jsTIfied to support them or there was just lack of time.