News & Commentary: 2006-02-12

Australian Technology Investment

A Case Study: MatrixView

An initial glance at the price chart shows a typical struggling tech stock that had (over just six months) seen over one third of its value dwindle away. The eye catching feature of the chart is the recent steep upturn that just happened in the last week. Wow! They must have done something good to turn it around just like that.

A quick glance at the announcements shows they won a "Global Innovation Award", which sounds rather impressive but what sort of award could give such a massive boost to a flagging stock price? What do MatrixView actually do anyhow?

The only explanation of MatrixView's products that you get from the ASX is "Adaptive Binary Optimization (ABO)" which sounds high-tech and computer-related but means nothing much. Fortunately, there's always Wikipedia with an answer and this at least explains that we are dealing with image compression. It also provides a link to the MatrixView website.

So MatrixView are developing a patented image compression technology and using this primarily for medical images. There are a few immediate points raised here:

• The image compression technology arena is a mature market, existing formats such as JPEG, PNG, GIF, etc are already popular and widely used. At least 20 years of mathematical research has gone into various types of data compression technology and resulted in solidly well-respected algorithms such as Huffman compression, LZW, Burrows-Wheeler, etc.
• The medical industry has demonstrated stubborn recalcitrance when it comes to accepting computer technologies and thus no image compression technology has been specifically tuned for medical images.
• Any algorithm encumbered by an expensive patent is unlikely to become a broadly accepted standard, but it might become a standard within a specialised arena (such as medical imaging).
• Once you have a good algorithm, there isn't much of a production phase involved -- you grab all your patents, write a reference implementation, release the technical details and try to get support from the existing players in the imaging field. They either go with it (and you rock) or they don't (and you're sunk).
• You don't need a bit marketing effort (except perhaps getting the medical industry to trust you at all) because the market already exists and the benefit for high quality compression algorithms is self evident.

Thus we have an answer to one key question: "Is there something useful you can do with the technology?" -- answer YES there certainly is.

That leaves two questions still requiring answers: "Can they get the investment that they need?" and "Is this technology actually any good?"

Evaluating Technological Merit

The only thing we can be sure about the future is that there will be changes, the only thing we can base our judgement on is the presumption that most things will stay the same.

The first step of our analysis is to understand this image compression algorithm a bit better.

• Here is a link to the MatrixView white paper.
• Here is a link to the summary of their patent number AU2003226616.
• Here is a link to the summary of their patent number AU2004284829.

The patent document is shortish, I'm not sure if there is more of it that hasn't been published yet or if my browser can't read it or if it really is that short. The key paragraph that I managed to find is this:

A method for compressing image data of an image, comprising; transforming the image data into a bit plane of first and second values; comparing each image element with a previous image element and if they are equal, recording a first value into a bit plane; and if they are not equal, recording a second value into a bit plane; and encoding repeating first and second values in the bit plane into a bit plane index; wherein the compressed image is able to be decompressed using the bit plane index and the bit plane.

Back in the years of yore there was the concept that a patent should contain enough information that a person skilled in the art could reproduce the invention by using the instructions in the patent. Somewhere along the line, this concept was thrown out, patent examiners pay no attention to it anymore. There certainly is not enough information in the above patents to be able to build an ABO compression engine.

The "bitmap" compression concept is further explained with a diagram in this web article. The web article explains it better than the patents do (in my humble opinion). The bitmap compression seems like an interesting idea but can it really achieve the claim on Matrixview's website?

How good is the quality of ABO™ vs traditional block processing image/ video compression techniques?

ABO™ surpasses current standards in terms of both its quality and compression ratios. We are able to achieve mathematically lossless quality at breakthrough ratios and speed. Our performance is significantly better as demonstrated by our ability to optimize echocardiograms by 30x as compared to current systems of around 7x-10x.

Moreover, images optimized with ABO™ will look clearer (no block distortion) as ABO™ processes the whole image at once. Current systems does block processing (typically 8x8 pixel blocks) and their images looks "blotchy".

Let's do some quick and dirty calculations...

Presuming the images are standard greyscale medical images of 8 bits per pixel. The bitplane must retain at least one bit per pixel so it seems the the best compression achievable for the bitplane phase is a factor of 8 -- and that is completely ignoring the table of actual pixel values. Possibly a follow Huffman phase might reduce that further but there seems no particular reason to believe that the bitplane would contain a more easily compressible input than the original image. Suppose the Huffman phase gets and extra factor of 2, that's still only a factor of 16. Still a good result for lossless compression but it would need an additional factor of 2 in order to reach the claimed performance.

At least, that's my back-of-the-envelope calculation. Not a full scale examination by any means but it seems to fall short even in an ideal case. In a less than ideal case we have a substantial number of actual pixel values that must be put in the side table which will take up additional space.

Linux World ran an article on the image compression technology

Thiagarajan, named India's Junior Scientist of the Year in 2001, has run a shop of 40 mathematicians for the past five years to research Adaptive Binary Optimization technology, the backbone of .Muv, resulting in what he says are new limits to algorithm compression.

"The .Muv is a completely new image," he said, adding that because of the lower complexity of compression it makes less demand on hardware, and is much faster to transfer and compress.

"Based on the algorithm [ABO] we have shown that we can exceed the so-called theoretical limits of compression.

"For example, if an original image size was 368,000 bytes, theoretical limits so far calculate it [the image] can be compressed one-way to 142,000 bytes, but we have shown it can be compressed up to 48,000 bytes - it is almost optimizing the binary system."

So in summary, Thiagarajan is claiming that the theoretical limit of compression is about 2.6x but he can compress to about 7.7x, unfortunately with no idea of what sort of image he is talking about, it's impossible to compare these figures with the 30x and 7x-10x quoted above. Presumably Thiagarajan is talking about lossless compression here (he was earlier).

Another article talks about ABO, Arvind Thiagarajan and MatrixView

In the case of echocardiograms (ECG), ABO technology can achieve a compression ratio that is 50-300 per cent superior to conventional technology.

So if we take the JPEG as the conventional standard with around 7x compression factor then "50-300 per cent superior" would be a compression factor of 10x to 28x. This claim does match up with the echocardiogram example from above. However, all the above claims are different to what we see in MatrixView's FAQ. I wonder why there is inconsistency? Which one is more accurate?

In the case of radiology images such as CT and MRI scans, the compression ratio is 10-50 per cent better than existing techniques such as JPEG.

This is very interesting as well... the compression works better for some types of image than it does for others. This is not surprising at all. JPEG was designed and optimised primarily for photographs and for this job it is well suited. Applying JPEG to EGC and MRI scans will still give moderate results but those images have different characteristics and the doctors using those images have different expectations so it makes perfect sense that JPEG is not quite the right tool for the job. All methods of compression are going to be "tuned" for particular applications and thus be less effective outside their primary target application.

So we still don't know what the real achievable compression ratios are and for what types of images... The big question at hand is, "Is MatrixView's ABO the right tool for the job of compressing medical images and can they really deliver a product that equals their claims?"

How it works

REPETITION CODED Compression invented by MatrixView assigns a value of `1' for successively similar values (pixels) in an image. If the value in an image is different from the previous value, `0' is assigned and the corresponding original value is stored in a table called `Data Store'. This process is done for all the values in an image.

The collection of zeroes and ones is called a bit plane. At the end of the process, there is a `Data Store' table and a bit plane.

Such a process makes it possible to increase the compression without losing any data.

This is a very similar explanation to the earlier article so at least we are getting some consistency here. The calculations above would apply the same for this case -- still leading to the conclusion that claims of a lossless 30x compression factor are unlikely to be realised.

Another technical presentation by Arvind Thiagarajan puts ABO under a somewhat different light.

• ABO - Adaptive Binary Optimisation
• Not a compression technique
• ABO increases the "Compressibility"
• Data arrangement is important for ABO
• ABO uses "Transformations" for Data rearrangement

This sounds suspiciously similar to the bzip2 program which uses the "Burrows-Wheeler block sorting text compression algorithm, and Huffman coding".

There are a bunch of strange things about the above document... pages are stamped "Private & Confidential" but it is available for download on the Internet after nothing more than a simple Google search. The claimed compression ratios vary greatly throughout the document and do not match up with other claims made in other articles about the same technology.

This report reveals a whole host of different variations of the ABO technology and demonstrates it beating other compressors on almost every different image type -- from medical images through to colour documents. Could those original 10 lines of code really represent a breakthrough in so many different imaging arenas?

The other weird thing about this report is that the compression ratios for colour documents seem rather low (only a ratio of between 2x and 3x). They are comparing ABO to JPEG2000 for colour documents but JPEG2000 is primarily designed for photographs, not for documents. Quite likely a PNG approach to compression might work better for documents... without access to the test material and without any idea of their methodology, it is impossible to reproduce their figures.

More unexpected compression ratios are presented for bi-level (black & white) documents, the compression ratios are up above 100x for several of the test cases. I would expect that colour documents are harder to compress but the jump from 3x to 100x seems a totally surprising difference. To test this, I grabbed some random pages (two pages from the Grandstream GXP2000 phone handset user guide, and one page from the Australian Institute of Criminology fact-sheets) converted them to 24 bit BMP (nearly the least efficient storage format, surpassed only by ASCII representation of floating point RGB values) then compressed them with both JPEG, PNG and G3 FAX (using the "ImageMagick 6.2.2 05/26/05 Q16" package on Fedora Linux), also compressed to JBIG using . Here are my results:

The first thing that stands out here is that compression results vary hugely depending on the picture type and that compression ratios vary from 1.3x through to over 100x. Choosing the right compressor for the right job is crucial. Looking at the compression figures quoted by MatrixView in comparison (NB, they don't make the original images available and they don't say which are lossless compressions, nor do they state what format the "standard" original is stored in):

• It is difficult to get any public information about how the algorithm works and Matrixview are very secretive about the details of their techniques even when there is no particular requirement for them to be secretive (they have patents and in the long run trade-secret protection can never work for something that is intended to become a data transmission standard).
• The patents offer a substantial lack of detail compared to other patents covering similar material. Other patents often try to hide the real gist of the concept in a morass of verbosity but the Matrixview patents just don't seem to contain much gist.
• Where information is available that does describe the algorithm (i.e. the bitplane diagrams) it suggest moderate improvements in compression (at best) and falls short of the 30x (or better then 100x in some cases) compression factor that is claimed.
• Some explanations of the techniques seem to be at odds with other explanations (some say "indexing technique", others say "compression technique", others say "increases compressibility", even others suggest that ABO is a method of encryption. It seems like they are searching around for something to cling to.
• The claims are not consistent (depending on where you look) and the methodology for how those figures were achieved is not explained. In many cases the stated behaviour of well-known compression algorithms in the MatrixView tests does not match the typical results that would be expected.
• The test images that the claims were based on have not been made available (or at least, were not found by myself and no link was provided to make it easy to follow-up and download the images), thus MatrixView ensure there is no way to validate their data.
• The claims are remarkably lofty and involve no "trade-off", the ABO technique is supposed to provide higher compression, lower loss, reduced algorithmic complexity and faster operation. Almost all of real-world engineering is based on trade-off, swings and roundabouts -- it just seems impossible to believe that any technology could be better in every possible aspect.
• The graphs of compression comparisons never show a case where a competing technology actually beats an ABO-based technology. This has the feel of "too good to be true": either something suspicious is happening in the test methodology or the test images have been carefully selected.
• In the case of data files, if these guys can already beat winzip so soundly (and other products like bzip2 or 7zip do beat winzip but not by such huge margins) then why do they need further development? They should have a product already out there.

Evaluating Corporate Merit

On the other hand, you can evaluate the company itself independent of the technology... Do they have promising people? Are they well organised? Are they moving forward in the manner that one would expect given the market and the company goals?

Going back to the article above:

The company, with a team of 50 researchers working out of India, is also working on audio and video compression methods.

Interesting, 50 researchers... that's quite a lot, but the same article said that it all boils down to 10 lines of code and that Arvind Thiagarajan stumbled across the idea quite suddenly. Does it take 50 researchers to write 10 lines of code? Obviously not... those 10 lines might be the key to it but there is a lot more work required to achieve a real result. The article does not make it clear whether those 50 researchers were hired before or after the company raised money from their float on the Australian Stock Exchange, not is it clear who the researchers are or exactly what they are working on.

Once again we see rubbery figures because the LinuxWorld article quoted a team of 40 mathematicians working for 5 years.

I could see that it might require research to fully explore the implications of a useful discovery and develop working products based on those... What I don't see is why a company would spread out into so many possible applications before they even have a working product in one single area. If they have a good result for ECG compression then it would make sense to focus right in on that particular market and push out a profit-making product in that area before moving to document management, general data storage and various other areas.

This seems almost like a delaying tactic to put off product development and collect as much investment as possible by constructing a tempting array of "almost products" each of which is extremely promising and right on the verge of success but all of which need a heap more investment before they can move. The tactic only makes sense if they really don't have a product and they want to pull in as much money as possible before people start to figure that out.

In summary, looking at the corporate behaviour points to the same conclusion that MatrixView just will not deliver the goods. My gut feeling says that the investors have blown their dough.

Some Real Problems With Investment

Sadly, that's the position almost all shareholders are in when they buy any high-tech shares. Most of the people buying those shares don't have the necessary background to make solid decisions and they don't even understand what it is that they are not being told, or what they should be asking. There are lots of promising-looking tech companies on the stock market, but each one of them tries to provide investors with a tightly controlled peep that barely uncovers one corner of their operation. Let's not forget that all high-tech development is also high risk, but it's a complete shot in the dark without the tools and the visibility to make a sensible evaluation.

The common excuse with these development companies is that they have to keep everything secret to protect against competitors and the less they tell anyone anything, the more the shareholders will make money. It should be obvious that this is a recipe for tears but strangely enough, plenty of people fall for such a lame trick.

2006-06-10: Newer developments

A register article, about secrecy in government contracts shows a similar problem to the lack of information available to stock investors. Rather than provide a convincing case for their decisions, it is so much easier to just make decisions in secret and cite "commercial sensitivity" as a catch-all explanation.

2006-11-28: Another Indian Student Makes an Amazing Storage Discovery

Another tech sensation turns up with improbable figures as the humble Indian student Mr Abideen figures out how to store 2.7GB on a square inch of ordinary laser-print paper. Of course there are plenty of good reasons why this is completely impossible and Mr Abideen's claims are at least 1000 times larger than anyone believes possible but hey, anything is worth a try when there are millions of investment dollars up for grabs.

You know that gambling is a tax on people who cannot do maths... I think that applies to tech shares as well.

2007-05-20: Ed Felton's Snake-Oil Indicators

I've quoted from Ed Felton's article about cryptographic technology where he explains the warning signs:

1. the flamboyant, self-promoting entrepreneur, newly arrived from another field;
2. the vaguely articulated theoretical breakthrough, described in mystical terms unintelligible to experts in the field
3. the evidence that the product hadn't been demonstrated or explained to its customers;
4. the claims to invalidate an accepted, fundamental principle in the field but without really explaining how it is done.

All of which applies to MatrixView and their ABO compression technique.

UPDATE 2007-09-15:

As an example, if you try to spend some time reading the WhitePapers at MatrixView website, which are SUPPOSED to describe their technology, you will notice that they have not even bothered to mention the set of images which were used for benchmarking.

This work is licensed under a Creative Commons License.

Back to News Commentary Index