I read a press release today from a company called Qbit, LLC, which is in no way affiliated with my similarly-named kitten. At least, I don’t think they are. But then, Qubit has been up to a lot of mischief lately, and I suppose she and former Apple CEO John Scully could have started the company while I wasn’t looking.

Anyway, the point is, Qbit has announced an amazing new video compression technique which they’re calling “Z-Image”, because compression algorithms without at least one “z” in the name never make it big. When was the last time you saw an ARJ file, eh? 1995? Even RAR is only popular among evil software pirates (presumably because “rar” is the sort of noise pirates like to make, although, come to think of it, the same argument could be made for “arj”).

Just like every amazing new compression algorithm ever announced in a press release, Z-Image is apparently capable of tricking the universe into looking the other way while it teleports bits into the eighth dimension, where they float around in a holding pattern until decompression time, when they are retrieved and reintroduced into the real world. Specifically, Qbit claims that Z-Image achieves “a 3 to 5x lossless encoding improvement using interframes, and 10x lossless using intraframes”.

Let’s examine that statement. First, note the use of the word “lossless”. They use it twice, to ensure that we haven’t missed it. Lossless compression means that, when the data is uncompressed, you get exactly the same bits as before (such as with your standard ZIP compression), as opposed to lossy compression, in which the end result will always be at least a little bit inferior to the original (like MP3 or JPEG or, since we’re talking about video here, MPEG). Okay. So they claim that this compression is lossless. That’s fine. There are lots of lossless video compression algorithms out there. There’s nothing wrong with that. But let’s look at some of the other words they use: “interframe” and “intraframe”.

Interframe compression, to put it very simply, is when you compare two or more frames of video and keep only the differences between them. So if you have a video of, say, a plastic bag flitting about in the wind with a brick wall behind it, the brick wall is mostly staying in the same place, while the bag is moving around. To save bits, you can throw in one full frame containing the whole scene (a keyframe), and then follow it with a bunch of frames containing only the bag. When the video is decoded, the video player will automatically combine the appropriate frames, and for the most part everything will look normal.

Problem is, you’re still throwing out bits. Technically, it’s possible to track every single pixel that changes between frames, in which case you could chop out redundant data and still be able to restore every single bit, but in reality this is completely impractical and would probably result in an increase in file size rather than a decrease, due to the overhead involved in tracking what could potentially be millions of pixels per frame. This is why most video compressors break each frame up into 8×8 (or, more commonly, 16×16) pixel blocks, which are then easier to track since there are less of them. But that results in the blocky compression artifacts we all know and love. Since Qbit claims they’re seeing at least 3x compression, they can’t possibly be doing true lossless interframe encoding. By definition, they must be getting rid of bits somewhere.

Next up: “intraframe”. As you might suspect, intraframe compression is compression that takes place within a single frame. While it’s possible for intraframe compression to be lossless, the results are rarely much smaller in size than the original; certainly not ten times smaller, as Qbit claims in their statement. Thus, lossless intraframe compression is very rarely used, because the results just aren’t worth the effort. That said, it’s perfectly possible to get a 10x decrease in size using intraframe compression—but only if you throw bits away, which makes it lossy.

Let’s look at an example, shall we? The master copy of Pie Trip 2.5, 5 minutes and 47 seconds of video at 704×400 pixels, weighed in at about 1.7 gigabytes. The low-quality Windows Media version, resized down to 352×192 and heavily compressed using a modern lossy compression algorithm, came to 14.5 megabytes, about 120 times smaller than the original. Not bad, huh? But the quality sucks.

The high quality version of the video, compressed using XviD, one of the best lossy video compression codecs available, came to 71.5 megs at the same resolution as the original. That’s about 24 times smaller, but it’s still nowhere near the same quality; at that level of compression, most people can still see obvious compression artifacts.

My archival copy of the video, compressed at XviD’s highest possible quality setting and with an average bitrate of 9,561 kilobits per second (well above the maximum bitrate of most DVDs), weighs in at 403 megabytes. That’s a compression ratio of about 4.3x, which falls nicely within the midrange of what Qbit claims Z-Image can do, but it’s still lossy!

Granted, these calculations don’t take into account audio data or container format overheads, but I still find it laughable that anyone can pretend to be able to achieve such incredible compression without losing a single bit.

I’ll believe it when I see it.

Comments

Nice hidden meme, there. Douglas Hofstadter would be proud of you.

if this company turns out to have mystical methods of magical compression, i will laugh at you.

ha.
ha.
ha.

...the Wolfram & Hart science division! I'm tired alright, give me a break. It was funny at the time.

Anyone remember the hoax compression utility that actually stored the source files in a hidden directory on your hard drive, so the resulting compression looked amazing, and seemed to restore files without lossy compression?

It has now been six months since John Scully’s Qbit proclaimed that it has amazing compression.

Yet no numbers are available.
Yet no one can back up Qbit’s claims of 10 to 1 or their claim of 32 to 1.
Yet no one can back up Qbit’s claims of compression any type of random data.

Qbit is truly the next hoax compression company and John Scully is either a fool or a crook for going along with it.
I've been hoping Qbit's confusion between "intra" and "inter" was just a typo. But there's no such easy way out for their inflated compression figures.

Our own research shows it's just barely possible to average 3X lossless intraframe compression for real-world images. But today's processors can't get that kind of compression in anywhere near real time yet. On the other hand, Qbit is nowhere near real-time yet either... Statistics on their website show it running 4 to 5 times slower than real-time for SD, 25 to 30 times slower than real-time for HD.

However, venture beyond 3? for lossless intraframe compression, and you run up against the intrinsic entropy of natural images. Think of a photo of a forest or a beach where each leaf or grain of sand is about the size of a pixel. Common sense tells us that the coloration, size, shape, orientation, and illumination of each leaf and grain of sand have enough completely unpredictable variation to cause easily visible differences at each pixel. But 10? compression stores only 1 bit for every 10 bits in the original image, which leaves too few bits to store any perceptible random variation at each pixel. In fact, even the statistical fluctuation in the number of photons reaching a photosite of a typical image sensor between video frames of a completely static scene varies more than that. And even the thermal noise in a typical image sensor varies more than that. Saying a codec can losslessly compress natural images by 10? is saying it can store 3 bits of information in 1 bit. It can't.

Incidentally, as uncompressed Y'CbCr 8bv 4??, your 5? min (= 347 s) Pie Trip master would have been 347 s x 30 f/s x 704 x 400 p/f x 2 B/p x 1/2^30 B/GB = ~5.46 GB. Since it was actually only 1.7 GB, it must already have been compressed by more than 3X - presumably with a lossy codec.

By the way, our real-time lossless SheerVideo codec doesn't have a "z" in its name, although our company name, BitJazz, has two. Does that count? Or should we call it Shzzr instead of Sheer?

Yep, the Pie Trip footage was shot on MiniDV, which is indeed lossy.

Copyright © 2002-2012 Ryan Grove. All rights reserved.
Powered by Thoth.