Any good algorithms for image compressions.

taeric · November 2008

So, I have a pipe dream of a requirement that I'm supposed to be working on right now. We are looking to compress images down to about 25k/image. This is an average value and we are definitely ok with degradation of the value. The requirement I have is that it must be "legible." The images are just screenshots. I tried doing this using ffmpeg and can get frames resized to about 800x600 that are still fairly readable. (Small text is not.)

My question, are there better algorithms I should look towards to make this requirement a reality? There is a preference that this be doable in Java, but I feel confident in the workforce to incorporate any solution. (We are also open to buying one.)

Thanks!

Sevorak · November 2008

How big are the files to begin with? And lossy or lossless compression?

taeric · November 2008

Apologies. The average screen size will be 1280x1024. Lossy is perfectly fine.

I have already toyed with using mpeg. Not sure I can get that easily done in java, nor if it is acceptable by my client.

Hlubocky · November 2008

Maybe I am missing something... why would you use mpeg to compress images? It seems like what works for motion (taking advantage of temporal similarities) would not be of any use to still images.

Ganluan · November 2008

Maybe the OP meant JPEG? It's a fairly efficient standard, especially if you go for the lower quality/higher efficiency compression modes. It's really bad at continually compressing, but I assume you'll only be compressing them once.

UncleSporky · November 2008

I think ffmpeg is a program that can resize/convert stuff for you, and he's looking for a similar program that can reduce quality for him that way. Not necessarily in .mpeg format.

It might be easier if we had one of these images to play with, to see what we can do with it and post the results, and you can tell us if it's good enough?

I mean, are we talking mostly just text, images plus text, or what.

Technicality · November 2008

Yeah, I'd guess if all you wanted was the text you'd get better results by filtering out what you don't want (eg. colour reduction) than heavy compression.

taeric · November 2008

I used mpeg because there is some similarity between all of the images. They are screenshots of the same computer, so at the least, mpeg will erase the cost of the background image between all of the screenshots. Same is true if they are working on a web application that they keep open for a long time. (Even if not, this can reduce the costs of the window decorations across all images.)

And annoyingly, the only images I have to work with are just screenshots of my own machine. The client is not giving me examples of the screens they expect.

taeric · November 2008

Also, I've been using ffmpeg because you can stuff all images into an mpeg and treat it just like an archive. Later, I can pull the individual frames out.

I have also used ImageMagick, as well as just resizing with Gimp. I can easily get down to 40 to 50k per image with easily readable screenshots. Getting it down to 25k, the only way I have had success with this is using mpeg. And then, the small text on the screen is somewhat tough to read. (Though doable.)

embrik · November 2008

I see the problem. 25K is small for quality images at 800x600 (plus, reducing a 1280x1024 image to 800x600 is distorting the image too (not the same aspect ratio)). You have to drop the Jpeg quality setting down to around 12-15, which makes text (except for large text) essentially unreadable. The screenshots themselves aren't that attractive either. That is given the fact that I'm taking a capture of a fairly busy screen. If it was something where there's a large percentage of a single color, the quality might be able to be better.

Saving it as a PNG, and dropping the bit depth to 8, I could get a screenshot down to just under 50K, which looked better than a jpeg at the same size, but I couldn't get it lower than that. The Gif format was larger than that with the same type of settings as a PNG.

Maybe messing with black & white screenshots would help, but I doubt it if you want any kind of quality. To me, a 25K image at that size is asking a LOT.

taeric · November 2008

Pretty much exactly.

I messed with mpeg because they were hoping to basically do a "diff" based approach from one screen to the next. Since that is effectively what mpeg does, I thought I would try it and see. (And, when compressing multiple images together, this can get some benefit. I did not try playing with the order the images are compressed, as that may make a difference in size, but would substantially increase computation.)

Black and White doesn't help in mpeg, as they store the images in YUV. I could potentially strip out the UV parts on the send side and add them back in on the receive one. I am not sure how much space that could save me, though. (At least, my understanding is that if I am doing grayscale, u and v would both be 0.)

That said, it is an area I'm looking at.

Dman · November 2008

I think knowing more about the pre-compression images and what type of degradation is acceptable is important here.
Also, do they really need to compress it down to 25k/image? Memory/bandwidth is cheap. You might find a way to compress them them that much and still have quality, but compressing and decompressing them might take up so much CPU resources that the trade off isn't worth it.

taeric · November 2008

We're talking about just standard screenshots from a client running a web application. Amusingly, I have not been allowed to see the web application. I've made my own test images from my machine just going to amazon, google, etc. I can start with a blank screen (desktop only), go to gmail, check two messages, go to amazon, open new window to do google search, and a few other shots. Using ffmpeg, I can push these into 800x600 frames that are legible with a size of about 30k/image no problem.

All of that said, I still agree with you 100%.

Penny Arcade

Quick Links

Any good algorithms for image compressions.

Posts