Further Jpeg compression for known resolution? Possibly storing header?

Question

My application requires VERY small size jpeg files (less than 2.5KB) to be stored as DATA (CANNOT BE A LINK) in a QR code. Both quality and size are a concern. Any byte I can save might mean that I can make the QR code easier to read. Luckily, they all have a standard resolution (160x240) and color depth (24 bits).

I had an idea of taking part of the header out of the JPEG files themselves, and have the application add the header back into the data array later, which would save a good 600 bytes (wow). The way I'm doing compression so far is to keep a "gold standard file" and compress that file with Q = 80-10% until it fits into 2.5KB.

Because a different compression ratio means a different header, my idea would be to pass the final compressed image through ANOTHER pass of a known, standard compression. But then if the "standard compression" is greater than the original compression the image settled on, the size may actually be GREATER than the final compressed image.

Is there a standard method of doing something like this? I feel like I might be onto something, but I can't seem to get it to work.

I've read over this three times, and the only thing I can think of is that this is a terrible idea. What is the end goal of having the JPEG data in a QR code? With that compression, not only will the image be unusably bad, but fitting that amount of data into a QR code will make it unable to be scanned by lower quality phone cameras. QR codes are not designed for what you're trying to do. — Kevin Coppock
The idea is that it simply has to be recognizable to the actual high quality image. Quality should be a concern to the point of recognizability. — yhyrcanus
Hmm, okay. Well, I just tried a Save for Web on a 240x160 image in Photoshop (which strips excess data), set it to 0 quality, and maximum blur for lossiness, and still couldn't get it below 2.5K. And it looked absolutely horrid. Honestly I don't think I could give you a satisfactory idea to go on with your requirements. If you could give a little more detail as to how your app would function, I'd be glad to suggest an alternative. — Kevin Coppock
So far, I've been able to get every image I have to compress below 2.5 KB, with standard java image libraries. The content of the image is a photo of a person. The verifier scans the image on the QR code and compares it to a hash, and to the person. Maybe because portraits have very simple lighting and similar colors on the individual image the images I'm using are smaller? — yhyrcanus
That's probably it. Compression varies a lot depending on the complexity of the content. (mine was pretty detailed). I suppose I'm just confused why you can't simply send a user ID, or the hash itself, rather than the image. Seems like an added layer of complexity for no real reason, but admittedly I'm unclear of what you're really doing. Just my opinion. :) — Kevin Coppock

yhyrcanus yhyrcanus · Accepted Answer · 2012-07-11T12:48:17

What I eventually ended up doing was having multiple levels of compression, and I stored the header (D0-DB) and the Huffman Table (C4). I am able to save roughly 550 bytes this way with a simple replace algorithm. It's not 100% ideal, but it's not half bad either. I lose around 50 bytes, but the trade off with increased quality and app program memory size makes it worth it.

To make it easier to scan, I decreased the maximum size to 1.9KB prior to the replace algorithm.

Further Jpeg compression for known resolution? Possibly storing header?

1 Answers