Question

I am looking at the problem of reducing storage space when storing multiple JPEG images together as a single bigger image. The basic intuition is that images tend to have some similarities (like those taken at the same location or around the same point of time) and can we exploit this similarity to save space ?

The overall flow is : Input JPG Images -> Each image converted into RGB Image Tiles -> Reorganize similar RGB tiles together -> Again transform to JPG format . Naturally, when retrieving images, we will need to reverse the process.

Using the DC coefficient of Y component as the similarity measure for tile reorganization, I obtained ~8% space savings for 10 images. When I do this for 100 images, the savings are reduced to ~3%.

  • How do I get savings after tile reorganization - i.e. which part of the JPEG encoding process takes advantage of this image tile reorganization ?

  • Instead of Y component's DC coefficient, are there some other metrics you could think of that will be better exploited by JPEG encoding


Revised:

Is there some other image format besides JPG that can exploit this kind of similarity better when aggregating multiple images ? Like PNG for instance ?

Was it helpful?

Solution

You are most probably using JFIF for encoding.

I'm not sure how you expect this method to work. If I understand correctly, you're splitting up images into tiles, aggregating them into one mega-image, with "similar" tiles arranged close to each other.

AFAIK, JPEG implementations do a separate DCT per individual 8x8 tile in an image, called a macroblock. Put another way, JPEG cannot take advantage of coherence among neighboring macroblocks (which appears to be the fundamental assumption for your compression technique).

If your own tiles are larger than macroblocks, you will not see any improvement beyond the savings in image header space.

Eg: 10 JPG image headers replaced by 1 will give you a 90% space savings, but only in the header. When you look at the overall file, the header is a small portion of the entire file, so your space savings are meager. When replacing 100 image headers by 1, you save 99%, but again only on the header. In both cases, all macroblocks are still being encoded and stored exactly as before.

OTHER TIPS

There are two areas where you will see benefits:

Firstly, when you put similar regions next to each other (especially if the edges of the images match up perfectly with no discontinuity - though this will be very rare), the DCT (frequency space) part of the jpeg algorithm works by progressively approximating big-ish regions (not sure what the biggest size is), then looking at the error between the approximation of the large region and multiple smaller regions, and production a more localisation correction.

I suspect that this effect is small, unless your images are very similar, or very small (so that their edges are long in proportion to their area).

Secondly, the Huffman coding part of the jpeg compression will see a benefit because the same bit patterns would appear in multiple sub-images, and be compressed with the same (short) token).

This aspect won't depend on what arrangement you compress your images in - as long as they are in the same image.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top