> claims 4-5 times better than JPEG and says lossless compression ..
> has anyone done any public domain work similar to that ??
I have only read through the first 8 pages so far, but I see a fair number of 'buzz words'. Either that or the paper was written by a non-native English speaker. More to follow....
> > claims 4-5 times better than JPEG and says lossless compression ..
> > has anyone done any public domain work similar to that ??
> I have only read through the first 8 pages so far, but I see a fair number of > 'buzz words'. Either that or the paper was written by a non-native English > speaker. More to follow....
Read the first page first, where it says "Singapore"...then the other 7. :)))))
> claims 4-5 times better than JPEG and says lossless compression ..
> has anyone done any public domain work similar to that ??
> -micromysore
Looks like a lot of hype accompanied by nice charts showing good but irreproducible results. How does their compression software reduce battery drain in laptops? How do they get around Shannon's channel capacity limits by rearranging data, as they claim? I don't buy it.
OK, table 4 shows some real data. They compress ccitt5.tif, which I think is just pic from the Calgary corpus plus a 738 byte TIFF header, to 30385 bytes, which is easily achieved by many good compressors with image models. paqar compresses pic to under 24K bytes. They don't explain what "preprocessed" or "visually lossless" is (where they quote better numbers), but I bet it is lossy.
> claims 4-5 times better than JPEG and says lossless compression ..
> has anyone done any public domain work similar to that ??
...well...this one looks like a winner to me. :)
Let me say that doing 4 times better than Jpeg and losslessly...does break a few rules here. Unless the "normalization" process they talk about leads *exactly* to the Shannon limit. ;)
Excellent nonetheless.
Public domain? <_< If you know of someone that got this kind of technology and is not interested to money...bring him to me! :D
> > claims 4-5 times better than JPEG and says lossless compression ..
> > has anyone done any public domain work similar to that ??
> > -micromysore
> Looks like a lot of hype accompanied by nice charts showing good but > irreproducible results. How does their compression software reduce > battery drain in laptops? How do they get around Shannon's channel > capacity limits by rearranging data, as they claim? I don't buy it.
> OK, table 4 shows some real data. They compress ccitt5.tif, which I > think is just pic from the Calgary corpus plus a 738 byte TIFF header, > to 30385 bytes, which is easily achieved by many good compressors with > image models. paqar compresses pic to under 24K bytes. They don't > explain what "preprocessed" or "visually lossless" is (where they quote > better numbers), but I bet it is lossy.
> -- Matt Mahoney
You should probably read their "news"...other than the 2002 "white paper"... ;)
No, scam doesn't work if you disclose the sources so everyone's able to see it.
I like especially this statement:
> It is based on a simple but powerful logical formula. Implementation > is carried out with basic mathematical operations. Unlike existing > approaches that generate floating points (decimal values), ABO ? 's > data is completely binary (integers).
Gee, do they know that floating point is also "completely binary" and even then there's little problem in doing DCT,DWT.. in fixpoint with "integers"?
Then, we have:
> 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".
Neither JPEG2000 nor JPEG-LS nor JBIG use blocking; they all process the image "at once".
> No, scam doesn't work if you disclose the sources so everyone's able > to see it.
> I like especially this statement:
> > It is based on a simple but powerful logical formula. Implementation > > is carried out with basic mathematical operations. Unlike existing > > approaches that generate floating points (decimal values), ABO ? 's > > data is completely binary (integers).
> Gee, do they know that floating point is also "completely binary" and > even then there's little problem in doing DCT,DWT.. in fixpoint with > "integers"?
> Then, we have:
> > 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".
> Neither JPEG2000 nor JPEG-LS nor JBIG use blocking; they all process > the image "at once".
> It goes on like this. Entertaining.
Might sound more "entertaining" to them indeed...signing contracts with Agfa health care must make them pretty happy I suppose.
Alright there's a lot of trolling around... but it's not like you use trolls in the Singapore's biggest hospital everyday. ;))
They're not claiming they compress stuff down to a bit... so I don't see the point in "miscredit" something we do not actually know - or just because it's not given to the public domain charity.
it's probably an corelation technique, perform an auto correlation, remove the biggest peak by encoding the freq? or may be its just a definition of an adaptive all-pass filter and a simple coding of the localized impluse response.
Erpy wrote: > Might sound more "entertaining" to them indeed...signing contracts with Agfa > health care must make them pretty happy I suppose.
> Alright there's a lot of trolling around... but it's not like you use trolls > in the Singapore's biggest hospital everyday. ;))
> They're not claiming they compress stuff down to a bit... so I don't see the > point in "miscredit" something we do not actually know - or just because > it's not given to the public domain charity.
They might have some legitimate image compression software, but their white paper seems to serve the purpose of misinforming and selling rather than informing. Anyone who knows anything about compression will recognize this, but we're not their intended audience.
Compressing pic to 30K can be done reasonably fast using predictive arithmetic coding in the context of surrounding pixels. They probably can't patent whatever they are doing because it's already been done, so instead they have to keep it secret.
>>I have only read through the first 8 pages so far, but I see a fair number > of >>'buzz words'. Either that or the paper was written by a non-native English >>speaker. More to follow....
> Read the first page first, where it says "Singapore"...then the other 7. > :)))))
Yes, I read that, but I am not going to assume that because the paper originated in Singapore the writer was not a native English speaker any more than a paper originating in the US is automatically from a native English speaker ;)
> Erpy wrote: > > Might sound more "entertaining" to them indeed...signing contracts with Agfa > > health care must make them pretty happy I suppose.
> > Alright there's a lot of trolling around... but it's not like you use trolls > > in the Singapore's biggest hospital everyday. ;))
> > They're not claiming they compress stuff down to a bit... so I don't see the > > point in "miscredit" something we do not actually know - or just because > > it's not given to the public domain charity.
> They might have some legitimate image compression software, but their > white paper seems to serve the purpose of misinforming and selling > rather than informing. Anyone who knows anything about compression > will recognize this, but we're not their intended audience.
> Compressing pic to 30K can be done reasonably fast using predictive > arithmetic coding in the context of surrounding pixels. They probably > can't patent whatever they are doing because it's already been done, so > instead they have to keep it secret.
Infact, that "paper" is more of a marketing seller than a scientific/technical revelation. ;)
That chart showing "normalization" of "probability" is rather interesting...but I do not know if arithmetic coding can actually redistribute symbol (or whatever is their base) probability in that way...maybe you could tell us more about it.
Well I was more interested in the math or rather than the business hype ? Itz a known fact that companies do beat their own drums to be heard ..
By saying public domain, I wanted to know if they *invented* a whole new way of looking at compression or is it that they came up with a neat little trick using already available things. I couldn't get hold of a public domain paper, but seems like it is supposed to have been published in some journal(somewhere in India) and and later on the company was started, patents filed .. blah blah .. if anyone figure out the math or the paper which deals with this technique (links or insight will be great)..
Erpy wrote: > That chart showing "normalization" of "probability" is rather > interesting...but I do not know if arithmetic coding can actually > redistribute symbol (or whatever is their base) probability in that > way...maybe you could tell us more about it.
This is typically what you get when you take the difference of adjacent pixels. The distribution becomes narrow with a peak around 0. This is a well known technique. For example, JPEG uses it to code the DC components prior to Huffman coding. You can improve on this a little by subtracting a weighted average of several surrounding pixels.
> Infact, that "paper" is more of a marketing seller than a > scientific/technical revelation. ;) > That chart showing "normalization" of "probability" is rather > interesting...but I do not know if arithmetic coding can actually > redistribute symbol (or whatever is their base) probability in that > way...maybe you could tell us more about it.
Any "suitable" pixel decorrelation will give statistics that are narrow-peaked around zero, approximately Lorenzian (or generalized Gaussian). And, you may call a subtraction of nearest pixel neighbours either "a simple mathematical operation based only on addition/subtraction on integers", or you call it by its filtering characteristics, "the Haar wavelet". It boils down to the same, but the latter is the proper technical term.
What makes we feel suspicious is that you'll get a lot of misleading (to avoid stronger words) information on their web page, and it lacks the proper technical language to describe what they're doing. Too much obfuscination, too little information.
SuperFly wrote: > On Thu, 26 May 2005 02:21:18 GMT, "Erpy" <i...@forwardgames.com> > wrote:
> -snip-
> >...well...this one looks like a winner to me. :)
> >Let me say that doing 4 times better than Jpeg and losslessly...does break a > >few rules here. > >Unless the "normalization" process they talk about leads *exactly* to the > >Shannon limit. ;)
> >Excellent nonetheless.
> They probably created a set of models for specific (medical) image > files with a lot of redundancy in it, which isn't detected by jpeg. > But you would need some example images to determine exactly how > (non)excellent their method is.
The results are meaningless if the data isn't released. But they do at least include some public data (CCITT test images). However they try to make the results look good by comparing their program with weak methods such as CCITT fax compression. These were designed when hardware was expensive, so they were designed to be fast and simple at the cost of compression. CCITT models only in one dimension, using a fized Huffman table, then deliberately adds some redundancy to allow resyncing over a noisy phone line.
I see results inflation all the time, even in peer reviewed papers where the profit motive is less obvious.
The sad part is that if you go here http://www.data-compression.info/ ABC's author even says that medical image processing is one of his fields of interest. So it's not only the open source aspect that MV took advantage of in order to raise VC, but the usage of the code wasn't exactly novel, either.
So based on this, how much of MV's patent doesn't jibe?
BTW, are there any versions of the ABC sourcecode out there translated to C/C++? I've experimented with the executable before using wine but wouldn't mind trying to roll it into some sort of useful library code as the 5MB blocksort buffer does wonders on some of the circuit simulation-related datasets I throw at it.
This is an official response to the recent posting that has appeared on this website. We wish to confirm that ABO is an original technology invented and developed by Scientists at Matrixview. We would like to further confirm that none of our commercial versions contain any kind of open source codes. ABO is a revolutionary algorithm that deals with pixel data in the spatial domain. This will be clarified further when we publish the theory of ABO on our website in the following weeks. As much as we appreciate your interest in ABO, we request you to hold your comments till reviewing our theory paper after which, we will be happy to engage in further discussions. In the meantime, if you would like to contact us on anything, please mail us at i...@matrixview.com
> The sad part is that if you go here http://www.data-compression.info/ > ABC's author even says that medical image processing is one of his > fields of interest. So it's not only the open source aspect that MV > took advantage of in order to raise VC, but the usage of the code > wasn't exactly novel, either.
> So based on this, how much of MV's patent doesn't jibe?
> BTW, are there any versions of the ABC sourcecode out there translated > to C/C++? I've experimented with the executable before using wine > but wouldn't mind trying to roll it into some sort of useful library > code as the 5MB blocksort buffer does wonders on some of the circuit > simulation-related datasets I throw at it.
shi...@gmail.com wrote: > This is an official response to the recent posting that has appeared on > this website. We wish to confirm that ABO is an original technology > invented and developed by Scientists at Matrixview. We would like to > further confirm that none of our commercial versions contain any kind > of open source codes. ABO is a revolutionary algorithm that deals with > pixel data in the spatial domain. This will be clarified further when > we publish the theory of ABO on our website in the following weeks. As > much as we appreciate your interest in ABO, we request you to hold your > comments till reviewing our theory paper after which, we will be happy > to engage in further discussions. In the meantime, if you would like to > contact us on anything, please mail us at i...@matrixview.com
> -SSS
It would seem that your marketing people have done quite a mess of a crappy job. If it seems to you that there is a negative aura about the comments on your purported achievements, it is the sole responsibility of those who have chosen to post the information available on your site. Nobody is commenting on your explanatory papers or comercial products, because there are none. Your request not to comment on what you have published is ridiculous. If you would like to contact this forum on anything, feel free to do so.
> > The sad part is that if you go here http://www.data-compression.info/ > > ABC's author even says that medical image processing is one of his > > fields of interest. So it's not only the open source aspect that MV > > took advantage of in order to raise VC, but the usage of the code > > wasn't exactly novel, either.
> > So based on this, how much of MV's patent doesn't jibe?
> > BTW, are there any versions of the ABC sourcecode out there translated > > to C/C++? I've experimented with the executable before using wine > > but wouldn't mind trying to roll it into some sort of useful library > > code as the 5MB blocksort buffer does wonders on some of the circuit > > simulation-related datasets I throw at it.
> This is an official response to the recent posting that has appeared on > this website. We wish to confirm that ABO is an original technology > invented and developed by Scientists at Matrixview.
Saying so, does not make it so.
> We would like to > further confirm that none of our commercial versions contain any kind > of open source codes.
Saying so, does not make it so.
> ABO is a revolutionary algorithm that deals with > pixel data in the spatial domain.
Do you realize how many times we have seen this claim from people who turn out to be scam artists, kooks, and even both?
> This will be clarified further when > we publish the theory of ABO on our website in the following weeks.
We will see, I have heard that one before too.
> As > much as we appreciate your interest in ABO, we request you to hold your > comments till reviewing our theory paper after which, we will be happy > to engage in further discussions.
Pardon? You do realize that this is what scam artists also want us to do all the time. The less comment/questions raised the more rubes they can pull in.
> In the meantime, if you would like to > contact us on anything, please mail us at i...@matrixview.com
Well, since you clearly read here, what is wrong in just talking in public?
Look, I am not claiming you are scam artists, but I am saying your marketing happens to be a very close match to what we see from scam artists, year after year. Instead of worrying about us, if you are legit maybe you should look at what your marketting department is up to. If you have a shady marketting that thinks only sell, sell, sell - and they end up selling the wrong product to the wrong person you can cause lots of harm if the use is in the medical field. -- I make public email sent to me! Hydrogen Peroxide Rockets, OpenBeos, SerialTransfer 3.0, RAMDISK, BoatBuilding, DIY TabletPC. What happened to the time? http://webhome.idirect.com/~earlcp
It looks like this early EchoView test version (27 January, 2004) use the compressor.dll.pec2bac with "ABC - Advanced Blocksorting Compressor code" as suggested at Geocities, but I see also an ABOImgCmp.dll what give the idea that MatrixView own patented ABO compression is also used. The software needs a dongle to use compression, so I can't test that part. In MatrixView's new statement they only acknowledge that their commercial software don't contain open source codes. But it looks like MatrixView used open source code in their old EchoView version (maybe test version) and "forgot" that to mention in their November 2004 response to me.
> > This is an official response to the recent posting that has appeared on > > this website. We wish to confirm that ABO is an original technology > > invented and developed by Scientists at Matrixview.
> Saying so, does not make it so.
> > We would like to > > further confirm that none of our commercial versions contain any kind > > of open source codes.
> Saying so, does not make it so.
> > ABO is a revolutionary algorithm that deals with > > pixel data in the spatial domain.
> Do you realize how many times we have seen this claim from people who turn > out to be scam artists, kooks, and even both?
> > This will be clarified further when > > we publish the theory of ABO on our website in the following weeks.
> We will see, I have heard that one before too.
> > As > > much as we appreciate your interest in ABO, we request you to hold your > > comments till reviewing our theory paper after which, we will be happy > > to engage in further discussions.
> Pardon? You do realize that this is what scam artists also want us to do all > the time. The less comment/questions raised the more rubes they can pull in.
> > In the meantime, if you would like to > > contact us on anything, please mail us at i...@matrixview.com
> Well, since you clearly read here, what is wrong in just talking in public?
> Look, I am not claiming you are scam artists, but I am saying your marketing > happens to be a very close match to what we see from scam artists, year after > year. Instead of worrying about us, if you are legit maybe you should look > at what your marketting department is up to. If you have a shady marketting > that thinks only sell, sell, sell - and they end up selling the wrong product > to the wrong person you can cause lots of harm if the use is in the medical > field. > -- > I make public email sent to me! Hydrogen Peroxide Rockets, OpenBeos, > SerialTransfer 3.0, RAMDISK, BoatBuilding, DIY TabletPC. What happened to > the time? http://webhome.idirect.com/~earlcp
> This is an official response to the recent posting that has appeared on > this website.
Which website? I would have thought an "official response" would come from a company email address -- not gmail. Who are you, and what is your position in the company?
> We wish to confirm that ABO is an original technology > invented and developed by Scientists at Matrixview. We would like to > further confirm that none of our commercial versions contain any kind > of open source codes. ABO is a revolutionary algorithm that deals with > pixel data in the spatial domain. This will be clarified further when > we publish the theory of ABO on our website in the following weeks.
You plan to publish it in stages over the following weeks, or you will publish it in one chunk, but you're just not sure when, or you won't publish, but hope we will forget?
> Which website? > I would have thought an "official response" would come from > a company email address -- not gmail. > Who are you, and what is your position in the company?
> > We wish to confirm that ABO is an original technology > > invented and developed by Scientists at Matrixview. We would like to > > further confirm that none of our commercial versions contain any kind > > of open source codes. ABO is a revolutionary algorithm that deals with > > pixel data in the spatial domain. This will be clarified further when > > we publish the theory of ABO on our website in the following weeks.
> You plan to publish it in stages over the following weeks, > or you will publish it in one chunk, but you're just not sure when, > or you won't publish, but hope we will forget?
|
