Received: by 10.224.207.66 with SMTP id fx2mr1117609qab.7.1351799420818;
        Thu, 01 Nov 2012 12:50:20 -0700 (PDT)
Received: by 10.236.181.234 with SMTP id l70mr4173942yhm.5.1351799420796; Thu,
 01 Nov 2012 12:50:20 -0700 (PDT)
Path: gf5ni14056677qab.0!nntp.google.com!c7no2336301qap.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.compression
Date: Thu, 1 Nov 2012 12:50:20 -0700 (PDT)
In-Reply-To: <k6tg55$j0j$1@news2.informatik.uni-stuttgart.de>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=128.105.14.11;
 posting-account=-11hqQoAAACK2e9ALobo3pMl7sSoXE2D
NNTP-Posting-Host: 128.105.14.11
References: <1448da41-2888-4483-91d8-f57a911dd70f@googlegroups.com>
 <k6qjs9$rd4$1@news2.informatik.uni-stuttgart.de> <e275babd-9591-4acd-b799-fe21d138eb58@googlegroups.com>
 <k6tg55$j0j$1@news2.informatik.uni-stuttgart.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9f80fa0f-ec37-43a2-9ed3-18ba1abee433@googlegroups.com>
Subject: Re: libjpeg : storing similar images optimally
From: Joy James Prabhu <prabhu.l...@gmail.com>
Injection-Date: Thu, 01 Nov 2012 19:50:20 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> > Will storing *similar* pixels from multiple images within a *single* bl=
ock give better compression ?
>=20
>=20
>=20
> How do you find similar pixels, and how do you encode which pixels=20
>=20
> belong to which image?
>=20
>=20
>=20
> There is not much to be gained, unless you have additional information=20
>=20
> on the image. For example, if the two shots are from the same scene, so=
=20
>=20
> you could use motion compensation.
>=20

I too agree that merging pixels is not really going to give better compress=
ion.
To be clear, by similarity, I meant similarity of the DCT coefficients of Y=
CrCb components or something derived from that. This similarity metric make=
s atleast some sense for larger subblocks (like 64x64 or 512x512 pixels) of=
 images rather than at pixel granularity, but as JPEG does 8x8 block compre=
ssion primarily and does not exploit similarity at larger granularity, I gu=
ess this will not really be a good fit for JPEG.=20

For encoding, I was thinking of using some simple mechanism like interleavi=
ng image blocks in some custom predefined order or using some hash function=
 (so that no indexing data overhead is incurred.)

I definitely cannot assume images are correlated pixel by pixel. Atmost, I =
can assume some larger blocks of these images are similar with respect to c=
olor and brightness like multiple images of the same building or a group of=
 people. I think other standard compression utilities like libgzip or libta=
r or packJPG(?) would itself be good fit for this usecase.=20

But, will rearranging the blocks of these images and then compressing them =
using these utilities make a difference ? Also, can you suggest some utilit=
ies that are suitable for JPG images in particular.

Thanks,
Joy

>=20
>=20
> > Do you have any suggestions for addressing this multiple-image problem =
(like rearranging the data smartly in some manner etc.) ?
>=20
>=20
>=20
> It all depends on how the images are related to each other. If they just=
=20
>=20
> "look similar", I don't believe much can be gained. There have been a=20
>=20
> couple of advanced object-oriented image compressions out, it was a hot=
=20
>=20
> research topic more than ten years ago and did not keep the promise of=20
>=20
> providing more advanced compression rates compared to the known=20
>=20
> transform-based codecs (it just created stranger artifacts).
>=20
>=20
>=20
> Transform coding in Z direction (transforming the two images in common -=
=20
>=20
> a very simple example would be coding the difference image) also does=20
>=20
> not provide much gain, unless the images are really correlated pixel by=
=20
>=20
> pixel.
>=20
>=20
>=20
> Thus, in the end, it boils down to the question of finding a good model=
=20
>=20
> for creating one image from the other.  You did not mention how the=20
>=20
> images are related, so I cannot really give any advice.
>=20
>=20
>=20
> Greetings,
>=20
> 	Thomas