Alternative technology to JPEG (30% better)

[IgorC]

new StuffIt Image Compression Technology.

Please use the link below to view/download the White Paper (.pdf)

http://www.stuffit.com/imagecompression/wp_stuffit_imgcomp.pdf

[DeathTheSheep]

Interesting... Is it as versitile though?

Anyway, I think a 30% increase is no small acheivement. Kudos to the Stuffit team!

[Leak]

Originally posted by DeathTheSheep
Interesting... Is it as versitile though?

Anyway, I think a 30% increase is no small acheivement. Kudos to the Stuffit team!

Well, if I take a bitmap and instead of using regular ZIP use 7-Zip (or RAR, or any newer lossless packer) on it, it's also getting smaller - I just can't unzip it with a regular ZIP unpacker any more.

Here, they replaced one (quite old) lossless compression algorithm with a different and newer one, but the result of course isn't a JPEG anymore.

I really wouldn't call that revolutionary.

np: Zorn - The City's Collapsing (But Not Tonight) (The City's Collapsing (But Not Tonight))

[Sergei_Esenin]

It may not be revolutionary, but JPEGs aren't easy to further compress. 30% added compression is certainly a remarkable and skillfull acheivement, even if it won't take the world by storm. :cool:

[sysKin]

In fact, jpeg is quite simpilstic. It decorrelates data within 8x8 pixel blocks (using dct) but it has almost no decorrelation *between* 8x8 blocks. All blocks are coded independently, with no prediction from one to another (except for mean brightness, and even this is only predicted from left).
Mpeg-4 (a)sp's intra frames use the same technology as jpeg and yet they are much more effecient because of data prediction. They can still be improved with arithmetic coding - and 30% becomes quite easy to achive.

[Sirber]

but a standart is a standart right? They won't change it...

[virus]

At the medium/low bitrates they're aiming for (they talk about "quality 50" for their test JPEGs), you can reach up to 20-30% improvement simply by replacing the very simple Huffman+RLE entropy coder used in JPEG with an arithmetic one. You can use an adapted version of EBCOT, for example (EBCOT is the basis of JPEG2000's arithcoder). Such coders give excellent bitrate savings, especially at low rates.

[bond]

who says 30%? the company itself? do people really still believe such marketing claims?

[slavickas]

Originally posted by bond
who says 30%? the company itself? do people really still believe such marketing claims?
http://www.compression.ca/act/act-jpeg.html

[bond]

Originally posted by slavickas
http://www.compression.ca/act/act-jpeg.html thats more believeable than the claims in the white paper, thx :)

[gotaserena]

Still, one cannot help but feel a little uneasy about the "lossless-but-cannot-get-your-jpeg-back" thingie...

[Leak]

Originally posted by gotaserena
Still, one cannot help but feel a little uneasy about the "lossless-but-cannot-get-your-jpeg-back" thingie...

What do you mean by that?

In the comparison they linked to, the original JPEG wasn't 1:1 restoreable only in the case where they used jpegtran or jpeg optimizer on the image, which are separate programs not connected to the StuffIt.

Of course, I'd rather have an open source solution so I'm not dependent on one company not screwing up... :D

np: Pan Sonic - Mutaaattori / Mutator (Kesto (234.48:4) (Disc 1))

[CyberGuy]

I've compared many truly lossless image codecs and the one by far that had the best compression ration was JPEG2000 by http://www.kakadusoftware.com. Download it and try it for yourself.

[Leak]

Originally posted by CyberGuy
I've compared many truly lossless image codecs and the one by far that had the best compression ration was JPEG2000 by http://www.kakadusoftware.com. Download it and try it for yourself.

Ummm... this thread is not about lossless image compression, it's about squeezing an extra 30% out of an already existing JPEG image by replacing the lossless compression part inside the JPEG algorithm with a different one.

np: Pan Sonic - Lautturi / Rafter (Kesto (234.48:4) (Disc 1))

[gotaserena]

Originally posted by Leak
What do you mean by that?

I meant this quote:
...there is no loss of quality to the image but it is not possible to get back an identical (bit for bit) version of the original JPEG you started with.
Since I didn't do any tests myself, I cannot verify that the Allume files are truly of the same quality as the jpeg source, but something does feel fishy about the fact that the proccess is not reversible.

In the comparison they linked to, the original JPEG wasn't 1:1 restoreable only in the case where they used jpegtran or jpeg optimizer on the image, which are separate programs not connected to the StuffIt.

Really? I had the impression that the *uncompressed* (BMP) files from the jpeg and Allume sources were identical, which is surely nice but not quite there yet.

[iapir]

Originally posted by CyberGuy
I've compared many truly lossless image codecs and the one by far that had the best compression ration was JPEG2000 by http://www.kakadusoftware.com. Download it and try it for yourself.

JPEG2000 is lossless ?

[Sirber]

it can be.

[akupenguin]

Originally posted by gotaserena
Since I didn't do any tests myself, I cannot verify that the Allume files are truly of the same quality as the jpeg source, but something does feel fishy about the fact that the proccess is not reversible.
That's perfectly reasonable, if you think about what they're doing: They unpack the jpeg into a bunch of DCT coefficients and entropy code them in their own format. On extraction, they turn it back into _a_ jpeg with the same coefficients, so it will decode into the same image as before. But you have some choices when making a jpeg (i.e. what jpeg optimizer helps with), and they don't store those choices in the archive.

[gotaserena]

So much for the second law of thermodynamics! :)

If the software indeed does what you say, one should be able to recover the original JPEG file from the processed one -- as you say, they process IDCT and entropy into their own format, and recover these data on extraction. In other words, the process should be reversible.

But then they clearly state that the process is *not* reversible in the sense that the original JPEG is lost during conversion but even so, the amount of information in both files is still the same (despite the 25% size difference).

Isn't there some fact of Information Theory preventing this sort of "free lunch"? At least in Thermodynamics irreversible processes always increase the entropy... Unless you talk about some freak effect from quantum mechanics, but I rather doubt these would play any role in this kind of problem.

[Sirber]

http://members.lycos.nl/diezijngek/magicgallery/Bunny@pancake.jpg

[Leak]

Originally posted by gotaserena
If the software indeed does what you say, one should be able to recover the original JPEG file from the processed one -- as you say, they process IDCT and entropy into their own format, and recover these data on extraction. In other words, the process should be reversible.

Ah, but since JPEG is a chunk based format, you could for example change the order of some chunks - the decoded image will stay the same, but the files will differ.

This means the image data isn't changed, but probably not the meta- and meta-meta-data.

np: Zorn - Early Shift (The City's Collapsing (But Not Tonight))

[Manao]

Isn't there some fact of Information Theory preventing this sort of "free lunch"Not at all, because JPEG isn't optimal considering the entropy of the DCT coefficient : First, it uses VLC table, which can only approach ( not reach, except in some special cases ) the lowest bitrate. A more efficient coding ( arithmetic ) can be optimal, which often means a gain around 10% in filesize.

Then, there's the order of the prediction. There are almost no prediction at all in JPEG, so what you encode is roughly a bunch of numbers which tend to be around zero, but not that much. With a good prediction scheme, you can increase a lot the tendency of the numbers you're coding to be close to zero, hence lowering the entropy, which, combined with an arithmetic coder assures you of lowering the filesize.

The information theory states that the theorical bitrate limit isn't simply the 0-order entropy, it's the infinity-order entropy ( entropy-rate ). So you aren't breaking any mathematical laws by doing what they do

[virus]

... and, more generally, don't get confused between entropy as defined in physics and that defined in information theory. They are two totally different concepts, with a completely different range of application, which just happen to share the same name.

[DeathTheSheep]

don't get confused between entropy as defined in physics and that defined in information theory. They are two totally different concepts, with a completely different range of application...

Ouch. <licks appendage, then swiftly applies to wool amidst a sizzling sound> Burn. InfoTheory, eh?

Enthropy basically means "disorder" either way... Physics=matter, PC=data. So a high enthropy factor results in less efficient compression, n'est pas?