new ABO compression
micro...@gmail.com
http://www.matrixview.com/en/archive/articles/downloads/mv%20technology/MatrixView%20White%20Paper%20-%20Honey%20I%20Shrunk%20the%20Bits!.pdf
claims 4-5 times better than JPEG and says lossless compression ..
has anyone done any public domain work similar to that ??
-micromysore
Phil Frisbie, Jr.
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....
> -micromysore
>
--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com
Erpy
news:6%7le.2097$W51....@typhoon.sonic.net...
> micro...@gmail.com wrote:
>
> > ppl,
> >
http://www.matrixview.com/en/archive/articles/downloads/mv%20technology/Matr
ixView%20White%20Paper%20-%20Honey%20I%20Shrunk%20the%20Bits!.pdf
> >
> > 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.
:)))))
Best,
E.
Matt Mahoney
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
Erpy
news:1117062914.5...@g44g2000cwa.googlegroups.com...
> ppl,
>
http://www.matrixview.com/en/archive/articles/downloads/mv%20technology/Matr
ixView%20White%20Paper%20-%20Honey%20I%20Shrunk%20the%20Bits!.pdf
>
> 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
Best,
E.
Erpy
"Matt Mahoney" <matma...@yahoo.com> ha scritto nel messaggio
news:1117073075.7...@g14g2000cwa.googlegroups.com...
> micro...@gmail.com wrote:
> > ppl,
> >
http://www.matrixview.com/en/archive/articles/downloads/mv%20technology/Matr
ixView%20White%20Paper%20-%20Honey%20I%20Shrunk%20the%20Bits!.pdf
> >
> >
> > 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"...
;)
http://matrixview.com/index.html
Best,
E.
Thomas Richter
> claims 4-5 times better than JPEG and says lossless compression ..
> has anyone done any public domain work similar to that ??
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.
So long,
Thomas
Erpy
"Thomas Richter" <th...@mersenne.math.tu-berlin.de> ha scritto nel messaggio
news:d740br$gu2$1...@mamenchi.zrz.TU-Berlin.DE...
> Hi,
>
> 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.
Best,
E.
jacko...@yahoo.com
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.
Matt Mahoney
> 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.
-- Matt Mahoney
Phil Frisbie, Jr.
> "Phil Frisbie, Jr." <ph...@hawksoft.com> ha scritto nel messaggio
> news:6%7le.2097$W51....@typhoon.sonic.net...
>
>>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
"Matt Mahoney" <matma...@yahoo.com> ha scritto nel messaggio
news:1117122594.6...@z14g2000cwz.googlegroups.com...
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.
Best,
E.
micro...@gmail.com
? 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)..
-micromysore
Matt Mahoney
> 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.
-- Matt Mahoney
Thomas Richter
Hi,
> 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.
So long,
Thomas
Matt Mahoney
> On Thu, 26 May 2005 02:21:18 GMT, "Erpy" <in...@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.
>
> 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.
-- Matt Mahoney
rain
Look at these weblinks;
http://www.ecogito.net/anil/2005/05/rediffs-foot-in-mouth-affliction.html
http://www.geocities.com/truth_out_there/truthexposed.html
Download a copy of the echoview program (Zip file) from here
http://www.geocities.com/truth_out_there/Echoview.zip
and use a decompiler to see what's inside........
"compressor.dll.pec2bac"
http://www.geocities.com/truth_out_there/Echoview_ABC.jpg
Support Open Source, keep it free for all !
byb...@rocketmail.com
> http://www.geocities.com/truth_out_there/truthexposed.html
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.
-t
shi...@gmail.com
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 in...@matrixview.com
-SSS
guenther vonKnakspott
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 in...@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.
And by the way, don't top post.
Earl Colby Pottinger
> 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 in...@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
rain
......When I unzip the Echoview.zip file I see:
Directory of \Echoview\Echoview
05/28/2005 11:11 PM DIR .
05/28/2005 11:11 PM DIR ..
01/26/2004 10:25 PM 73,728 ABOImgCmp.dll
05/25/1995 07:03 PM 47,104 compressor.dll
05/25/1995 07:03 PM 90,624 compressor.dll.pec2bac
01/27/2004 11:34 AM 28,672 DongleDLL.txt
01/27/2004 10:11 PM 57,344 EchoView.exe
01/27/2004 09:37 PM 1,262 license.txt
01/27/2004 09:41 PM 1,088 readme.txt
05/28/2005 11:11 PM DIR res
03/25/2000 10:16 AM 32,768 RYDLL32.DLL
02/03/2004 06:40 PM 43,008 uninstall.exe
02/03/2004 06:40 PM 1,423 uninstall.log
10 File(s) 377,021 bytes
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.
Earl Colby Pottinger 写道：
Pete Fraser
<shi...@gmail.com> wrote in message
news:1117341208.0...@g49g2000cwa.googlegroups.com...
> 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?
taru...@yahoo.com.au
taru...@yahoo.com.au
Patentability Report on the patentability of its application:
http://www.matrixview.com/files/release%20-%20PCT%20Patent%20020605.pdf
Presumably the details at this page are relevant:
http://pericles.ipaustralia.gov.au/ols/searching/patsearch/search_section.jsp?sectionCode=DTL&keyNo=2003226616&type=S
I emailed MVU,and they confirmed that the post from shi...@gmail.com on
29th May is official.
taruatoi
rain
stop pretending, you are also one of matrixview staff.....sigh! You
don't even need to email shi...@gmail.com, just shout across the
walkway in your tiny Shenton way office.....
taru...@yahoo.com.au
How many jobs can a person hold down at once?You would,I
suspect,already have read at
http://www.ecogito.net/anil/2005/05/rediffs-foot-in-mouth-affliction.html#comments,my
declaration that I am a shareholder in Matrixview.I'd have more than
half a dozen jobs if I worked for every company on which I post
positive input.If you're sufficiently motivated and wish to check my
bona fides, avail yourself of free registration at
http://www.hotcopper.com.au/ and do a search on 'taruatoi'.Be sure to
select the "100 posts" option;50 provides a truncated record.You'll
find I've been commenting on different stocks since 2002.Yes,I'll
concede it does'nt irrefutably prove my case.Nevertheless, I submit
that it contributes sufficient plausibility to make my claim credible.
taruatoi
Pete Fraser
<taru...@yahoo.com.au> wrote in message
news:1118157376....@g43g2000cwa.googlegroups.com...
> Rain,
> How many jobs can a person hold down at once?You would,I
> suspect,already have read at
> http://www.ecogito.net/anil/2005/05/rediffs-foot-in-mouth-affliction.html#comments,my
> declaration that I am a shareholder in Matrixview.I'd have more than
I'm not sure of the importance of your coupling coefficient with Matrixview.
You didn't give us any substantive information in your previous posts
anyway.
Sportman
> I suspect,already have read at
> http://www.ecogito.net/anil/2005/05/rediffs-foot-in-mouth-affliction.html
For sure he did:
"Anonymous" there and "rain" and "Earl Colby Pottinger" are all the
same person.
And editor of:
http://www.geocities.com/truth_out_there/truthexposed.html
He reveals his identity in the "rain May 30, 4:35 am" reply with
signing as "Earl Colby Pottinger" and to be the only one knowing where
to download the Echoview.zip file.
Sportman
> He reveals his identity in the "rain May 30, 4:35 am" reply with
> signing as "Earl Colby Pottinger"
Earl Colby Pottinger
> taru...@yahoo.com.au wrote:
> > I suspect,already have read at
> > http://www.ecogito.net/anil/2005/05/rediffs-foot-in-mouth-affliction.html
>
> For sure he did:
> "Anonymous" there and "rain" and "Earl Colby Pottinger" are all the
> same person.
>
> And editor of:
> http://www.geocities.com/truth=AD_out_there/truthexposed.html
>
> He reveals his identity in the "rain May 30, 4:35 am" reply with
> signing as "Earl Colby Pottinger" and to be the only one knowing where
> to download the Echoview.zip file.
Please learn how to read quoted messages, person in fear of using his real
name.
Earl Colby Pottinger
Earl Colby Pottinger
> taru...@yahoo.com.au wrote:
> > I suspect,already have read at
> > http://www.ecogito.net/anil/2005/05/rediffs-foot-in-mouth-affliction.html
>
> For sure he did:
> "Anonymous" there and "rain" and "Earl Colby Pottinger" are all the
> same person.
>
> And editor of:
> http://www.geocities.com/truth=AD_out_there/truthexposed.html
>
> He reveals his identity in the "rain May 30, 4:35 am" reply with
> signing as "Earl Colby Pottinger" and to be the only one knowing where
> to download the Echoview.zip file.
Sorry, but you are wrong. There is only one Earl Colby Pottinger, and that
is me. I never use handles anymore as they are a waste of time. I last use
my handle CyberNerd about four-five years ago. Personally, I can found by
just doing a google search for my name.
And I NEVER USE 'ANONYMOUS' as I consider people who have to use such to be
cowards.
Come on and sue me if you want, but you better bring a working copy of your
program before you do it. Also as a computer tech I am more than willing to
point out to the court all the diffirent ways compression scams can be set
up. Which means EVIL of EVIL, I will demand that any so-called compressed
file will need to be copied between disks/machines with my own machine acting
as a filter first.
That mean no hidden files, no IR, WIFI, ultrasonic transfers. You will be
surprise what I will strip out of a machine before I will let you decompress
on it. Disks that get wiped by first formating with total diffirent
filesystems. Why anyone thinks I need an alias when I am already so hostile
to magic compressors is something I don't understand. That's why I question
someone who is not prepared to use thier real name
What's more Sportman are you blind, can't you tell what is quoted text? He is
quoting me, get a better news reader. Rain's message reads:
See the latest update from http://www.endlesscompression.com/
.=2E....When I unzip the Echoview.zip file I see:
Directory of \Echoview\Echoview
Earl Colby Pottinger =E5=86=99=E9=81=93=EF=BC=9A
> shi...@gmail.com :
>
> > 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 in...@matrixview.com
>
> Well, since you clearly read here, what is wrong in just talking in publi=
c?
>
> Look, I am not claiming you are scam artists, but I am saying your market=
ing
> happens to be a very close match to what we see from scam artists, year a=
fter
> year. Instead of worrying about us, if you are legit maybe you should lo=
ok
> at what your marketting department is up to. If you have a shady markett=
ing
> that thinks only sell, sell, sell - and they end up selling the wrong pro=
duct
> to the wrong person you can cause lots of harm if the use is in the medi=
cal
> field.
Earl Colby Pottinger
Thank you very much.
Question, why don't you use your real name?
Earl Colby Pottinger
jacko...@yahoo.com
we want to know about A B O!!! unofficial protest banners up :)
GLoca...@gmail.com
jacko...@yahoo.com wrote:
> we want to know about A B O!!! unofficial protest banners up :)
It seems like you guys want everything handed to you on a silver
platter...
But tell me, how hard is it to type a company's name in the search box
of the online patent database...?
I mean, the freakin' patent that describes their algo has been online
for the public for more than 1 year.
Go see it. If not, you shouldn't complain, bacause you're either too
lazy or your search tactics suck.
micro...@gmail.com
I meant .. search DOESNOT give any results
-mic
micro...@gmail.com
I guess searches online are mostly for patents that are already been
*granted* ..
"I mean, the freakin' patent that describes their algo has been online
for the public for more than 1 year. "
Could you post the link where you found it ??
-mic
Sportman
> Could you post the link where you found it ??
Visit: http://ep.espacenet.com
Click: Number Search
Type: WO03084205
Click: REPETITION CODED COMPRESSION FOR HIGHLY CORRELATED IMAGE DATA
Click: Original document
Enjoy: 28 pages (PDF format)
Claudio Grondi
the link to the patent text. I have got the entire
document and did a fast read over it .
If I understand it right, I should probably be able to
get a new patent for working with diagonal bit maps
instead of horizontal and vertical ones?
I can't imagine this "invention" was not already
evidently known long long time ago.
I can maybe see the trick here - the first step is to look
what is worldwide available as written material which
can be used to claim prior art and then check if
something obvious is not yet covered by it, so
it can be patented, because must be considered new.
I had myself same idea for sure more than twenty years
ago, but how can I provide the evidence I had?
Isn't it nothing else than the idea of arithmetic coding
expressed in terms of bitmap planes?
Knowing the patent text it is probably easy to write some
code which can be run on a collection of pictures to see
if it works better than other image compression methods.
Maybe someone has already written it, so why not make
it public here?
Claudio
"Sportman" <spor...@gmail.com> schrieb im Newsbeitrag
news:1118978464.9...@g49g2000cwa.googlegroups.com...
Sportman
> I can't imagine this "invention" was not already
> evidently known long long time ago.
You are not the only one :-)
Arvind Thiagarajan:
"Yes, I wondered why nobody in the world thought of this before because
it is such a simple thought. Thousands of papers are produced all
around the world on compression of data but, somehow, nobody has
thought of this fundamental problem."
Erpy
news:1119012420.0...@g43g2000cwa.googlegroups.com...
I agree. And that's not the only simple one thing that was not patented
before. ;)
People tends to work on *given* bases, like that bases are the true and only
simplest things one could ever simplify. That's not always true. :)
Best,
E.
Jim Leonard
> Isn't it nothing else than the idea of arithmetic coding
> expressed in terms of bitmap planes?
So that's the big invention? Aritmetic coding of each bitplane?
Could anyone summarize the patent for us? I hate reading patents;
after a few pages of lawyer-speak, I lose the ability to blink my eyes
in unison (hemorrhaging usually follows).
ParkerOn
And about the last few messages about doing in a diagonal manner, isn't
it possible that they would have thought about it already?
Who knows what they have not disclosed and for whatever reason... I
hope this thread is not about just trying to find the obvious fault
visible than what could be fundamental....
Parker
atta...@yahoo.com
they have showed is a very simple image in black and white. A
compression from 188k to 44k. :-)). In this patent is possible to see
the algorithm principle they apply. It is based on near pixel with the
same color. If in the picture there aren't contiguos pixel with the
same color the file dimension is more large than a BMP. It can't work
with real world images. I would like to ask they why have promoted that
their compression is better than JPEG and it is the best choice for
movie compression. At this moment no lossy image compression is better
than JPEG (maybe in some circumstance...).
Matt Mahoney
European patent WO03084205 is surprisingly readable compared to most
patents.
Store two bit planes, one where a bit indicates if the pixel is
different than the one to the left, and the other to indicate if it is
different from the pixel above. If both values differ, then also store
the pixel value. For lossy compression, use a threshold to determine
if pixels differ.
Presumably the compression depends on how the bit planes and remaining
pixels are represented, but this isn't specified by the patent.
I wouldn't bother with this patent. I'm sure it works but I can't see
that the compression would be any better than PNG. Based on the
results in their white paper and the other comments in this thread, I
doubt this is what ABO is actually using.
-- Matt Mahoney
Matt Mahoney
> European patent WO03084205 is surprisingly readable compared to most
> patents.
>
> Store two bit planes, one where a bit indicates if the pixel is
> different than the one to the left, and the other to indicate if it is
> different from the pixel above. If both values differ, then also store
> the pixel value. For lossy compression, use a threshold to determine
> if pixels differ.
>
> Presumably the compression depends on how the bit planes and remaining
> pixels are represented, but this isn't specified by the patent.
I tested how a naive lossless implementation of ABO would compress a
color image of lena (512 x 512 x 24) and it makes the file larger. In
all 3 color planes there are 786,432 8-bit pixel values. Of these,
31,644 are identical to the same color pixel to the left, and of the
remaining 38,985 are identical to the pixel below (scanning upwards as
in a .bmp file). The horizontal bitplane takes 98,304 bytes. For the
vertical bitplane I only counted a bit for the case where there is a
horizontal difference (otherwise you are going to take the value to the
left anyway). This bitplane takes 94,349 bytes. Finally the 715,803
remaining pixels would take 1 byte each. The total size would be
908,456 bytes. For comparison, the PNG file is 511,988 bytes
compressed with Paint Shop Pro 4.0 noninterlaced. The uncompressed
.bmp file is 786,486 bytes.
Now I know I could be smarter about encoding the bitplanes and
remaining pixels, but since the patent didn't specify a storage format,
I didn't try to be smart.
-- Matt Mahoney
ParkerOn
Thanks for taking the time to do what you did and post your results on
the thread.
I have a question. What RCC looks like is more of a transformation to
me... Is it possible that they have modeling and source coders which
compress this transformed data. Do you think any specific or generic
context modeling schemes can imrpove or substantiate the claim?
-Parker
Matt Mahoney
It would make more sense to me to use it as a preprocessor as you
describe. It should get reasonably good compression this way, but not
a breakthrough. To do this you would code two binary decisions to an
arithmetic coder specifying whether the two adjacent pixels are the
same, and if not, code the error in the next pixel prediction. I don't
think this would compress any better than coding the prediction errors
directly but might be faster.
-- Matt Mahoney
Benjamin Johnston
I too have read the patent, and it strikes me that ABO (after
eliminating coding redundancy) is pretty much equivalent to a kind of
2D run length encoding scheme.
As I understand it:
You effectively have 3 streams of data.
The first two stream's values are read bit-by-bit to indicate whether
to take the value of the previous pixel or the above pixel:
both = 0 - use value from 3rd stream
first stream = 1 - use value of previous pixel
second stream = 1 - use value of above pixel
And the 3rd stream is just a sequence of pixel values.
It seems to me that if the 3 streams were interleaved with each other
then it would be pretty much equivalent to many other run length
encoding schemes. The MatrixView ABO seems to be based on the idea of
having the run-lengths kept separate from the pixel values.
This doesn't strike me as particularly innovative -- yes, it is
possibly a small innovation if nobody has thought of separating
compression into control and data streams (though, I'm sure things like
this have been invented, but possibly not become mainstream because it
doesn't lend itself to streamed compression and decompression -- if the
three streams aren't interleaved then the whole of the first and second
stream must be received before the third stream can be decoded). Based
on the patent, and results in the thread, I would say that this
algorithm is "just another" lossless compression algorithm.
The reported benefits of MatrixView against JPEG seem to be rather
unfairly biased. If we consider ultrasound images such as these:
http://images.google.com.au/images?q=ultrasound
then under the right conditions, you could claim fantastic compression:
Start with a full color bitmap (of the grey scaleimage) - 66%
compression just by converting back to greyscale.
Use a really simple technique such as run length encoding on the large
(fixed) black areas to avoid storing all the large areas of black
(another 66% compression)
Then just store the remaining data as-is - that's 9 times compression
already and we haven't really even touched on compression.
Now if we do some kind of differential or predictive encoding on the
remaining data to get, say, another 4x compression - we've ended up
with 36x compression without much sweat.
A JPEG implementation is going to be lossy, and such images are exactly
what JPEG isn't designed for. The comparison is completely unfair, and
I bet you'd get ho-hum results if MatrixView compared its algorithms to
other algorithms with a similar purpose (in fact, we can see that the
algorithm isn't much when we look at the independent technical report
that compares ABO with JBIG1).
I suspect that MatrixView is keen on raving on-and-on about DCT
transforms and JPEG for three reasons:
- talking about fourier transforms sounds impressive and intelligent
to the investor
- to the average investor compression=JPEG, and this is a very
convenient misconception when ABO compares so favorably against JPEG in
this particular domain (even though JPEG would never and should never
be used in such a domain)
- you have to read deeper past the "intimidating" mathematics before
you even see the comparison against JBIG1 that shows almost no benefit
-Benjamin Johnston
Erpy
messaggio news:1119227281.6...@g43g2000cwa.googlegroups.com...
>
> ....
> It seems to me that if the 3 streams were interleaved with each other
> then it would be pretty much equivalent to many other run length
> encoding schemes. The MatrixView ABO seems to be based on the idea of
> having the run-lengths kept separate from the pixel values.
>
> This doesn't strike me as particularly innovative -- yes, it is
> possibly a small innovation if nobody has thought of separating
> compression into control and data streams (though, I'm sure things like
> this have been invented, but possibly not become mainstream because it
> doesn't lend itself to streamed compression and decompression -- if the
> three streams aren't interleaved then the whole of the first and second
> stream must be received before the third stream can be decoded). Based
> on the patent, and results in the thread, I would say that this
> algorithm is "just another" lossless compression algorithm.
>
> The reported benefits of MatrixView against JPEG seem to be rather
> unfairly biased. If we consider ultrasound images such as these:
> http://images.google.com.au/images?q=ultrasound
> then under the right conditions, you could claim fantastic compression:
Don't know about ABO, but I did experiment myself with some sort of
grayscale image compression ideas some time ago.
SSE was developed and dedicated infact to grayscale images:
www.forwardgames.com/temp/SSE_test2.bmp
(RLE encodes this in 27328 bytes)
It can be visually lossless while the algorithm actually discards/changes
some original pixel data.
The compression ratio can be largely improved, while the current ratios
compares to a GIF compression of the same visual quality.
It is based on an extremely simple idea indeed...."may I have the patent
please then?!"...and moreover..."get the investors in!" ^_^
Best,
E.
Thomas Richter
> Store two bit planes, one where a bit indicates if the pixel is
> different than the one to the left, and the other to indicate if it is
> different from the pixel above. If both values differ, then also store
> the pixel value. For lossy compression, use a threshold to determine
> if pixels differ.
This sounds like a naive predictor approach; the PNG predictor works
very similarly, and so do various FAX/JBIG/JBIG2 approaches. Another
remarkable compression scheme along these lines is JPEG-LS which works
similarly.
Presumably, either I don't get it, or the patent office didn't notice
that similar and more elaborate patents exist in the area of b&w
compression, especially FAX.
> Presumably the compression depends on how the bit planes and remaining
> pixels are represented, but this isn't specified by the patent.
> I wouldn't bother with this patent. I'm sure it works but I can't see
> that the compression would be any better than PNG.
Exactly. That's because the PNG predictor works basically the same way.
So long,
Thomas
taru...@yahoo.com.au
others that MVU has applied for.They were referenced in their
prospectus of
June,2004(http://www.asx.com.au//asxpdf/20040615/pdf/3lvry89s67dq1.pdf).I
couldn't open them at the time.Maybe it will be easier if the
international patent numbers are available.The first-listed of the
following is apparently not the one that has been discussed here.
SG200307062-0----filed 7 Mar 02---------------priority date 1 Apr
02------repetition coded compression for highly correlated image data
IN 1012/CHEN/2003---filed 15 Dec 03-------priority date 15 Dec
03----unique method of data encryption by repetition coded compression
IN 1013/CHEN/2003---filed 15 Dec 03-------priority date 15 Dec
03---novel algorithm for adaptive and scalable data compression
IN 1014/CHEN/2003---filed 15 Dec 03-------prioity date 15 Dec
03---novel algorithm for lossless data compression
IN 1015/CHEN/2003---filed 15 Dec 03--------priority date 15 Dec
03---unique method of data encryption by repetition coded compression
IN 1016/CHEN/2003--filed 15 Dec 03----priority date 15 Dec
03-------novel algorithm for data compression
taruatoi
ParkerOn
How do you get these compression numbers: Are these approximation,
estimated or speculated?
I think this thread would like to know facts and possible pointers to
what you have said. What I am curious is how can you say you will get
66%. Have you used any particular coder/implmentation?
-Parker
Earl Colby Pottinger
> European patent WO03084205 is surprisingly readable compared to most
> patents.
>
> Store two bit planes, one where a bit indicates if the pixel is
> different than the one to the left, and the other to indicate if it is
> different from the pixel above. If both values differ, then also store
> the pixel value. For lossy compression, use a threshold to determine
> if pixels differ.
>
> Presumably the compression depends on how the bit planes and remaining
> pixels are represented, but this isn't specified by the patent.
>
> I wouldn't bother with this patent. I'm sure it works but I can't see
> that the compression would be any better than PNG. Based on the
> results in their white paper and the other comments in this thread, I
> doubt this is what ABO is actually using.
Maybe I am just dumb as I really do very little compression coding myself.
But two bit planes equals 2 biits per pixel equals 4 possibilities.
(1) No match.
(2) Same vertical.
(3) Same Horizontal.
(4) Same as both.
Option (4) could be replaced with (2) or (3) suggesting there is already a
lot of waste in the encoding. Do the other patents cover this?
Matt Mahoney
> "Matt Mahoney" <matma...@yahoo.com> :
>
> > European patent WO03084205 is surprisingly readable compared to most
> > patents.
> >
> > Store two bit planes, one where a bit indicates if the pixel is
> > different than the one to the left, and the other to indicate if it is
> > different from the pixel above. If both values differ, then also store
> > the pixel value. For lossy compression, use a threshold to determine
> > if pixels differ.
> >
> > Presumably the compression depends on how the bit planes and remaining
> > pixels are represented, but this isn't specified by the patent.
> >
> > I wouldn't bother with this patent. I'm sure it works but I can't see
> > that the compression would be any better than PNG. Based on the
> > results in their white paper and the other comments in this thread, I
> > doubt this is what ABO is actually using.
>
> Maybe I am just dumb as I really do very little compression coding myself.
>
> But two bit planes equals 2 biits per pixel equals 4 possibilities.
> (1) No match.
> (2) Same vertical.
> (3) Same Horizontal.
> (4) Same as both.
>
> Option (4) could be replaced with (2) or (3) suggesting there is already a
> lot of waste in the encoding. Do the other patents cover this?
>
> Earl Colby Pottinger
In my experiment on lena.bmp I assumed that if the horizontal pixel was
the same then there is no need to record a bit to indicate if the
vertical pixel was the same, so I didn't count those bits. Still, it
expanded the image. The reason, I think, is that only a small fraction
of the pixels are identical, so you end up storing most of them.
I read their prospectus describing the tests by Ernst & Young. They
compared ABO with JPEG (lossy, max quality) and JPEG2000 (lossless) on
32 frames of an echogram video converted from AVI to color BMP. They
claim ABO has better compression. I assume ABO is coding the bit
planes and pixels in some way not described in their patent.
They also compared their program on CCITT bilevel test images (scanned
documents) with CCITT level 4 and JBIG. They did better than CCITT but
about the same as JBIG.
-- Matt Mahoney
ParkerOn
Thats what I meant in one of my previous replies. RCC looks like more
of a transform and any content specific context modeling followed by a
suitable source coder can do the job(to achieve ratios as claimed by
them). Yeah, it is possible that they have not disclosed all these in
their patents for reasons only known to them.
Whether they do on one bit plane, be it vertical or horizontal or both
or take a common bit plane from the two bit planes could be data
specific. May be one route works well for some and the other of some
others. Can that be the case?
-Parker
Matt Mahoney
ParkerOn wrote:
> Matt,
>
> Thats what I meant in one of my previous replies. RCC looks like more
> of a transform and any content specific context modeling followed by a
> suitable source coder can do the job(to achieve ratios as claimed by
> them). Yeah, it is possible that they have not disclosed all these in
> their patents for reasons only known to them.
>
> Whether they do on one bit plane, be it vertical or horizontal or both
> or take a common bit plane from the two bit planes could be data
> specific. May be one route works well for some and the other of some
> others. Can that be the case?
Probably. They have some other patent applications (that I haven't
seen) and one of them might cover the coding of this data.
Wimjan
> Benjamin,
>
I'm not Benjamin, but please allow me to reply.
> How do you get these compression numbers: Are these approximation,
> estimated or speculated?
>
Some are kind of exact, some are speculated and others are estimates.
> I think this thread would like to know facts and possible pointers to
> what you have said.
>
> > "Start with a full color bitmap (of the grey scaleimage) - 66%
> > compression just by converting back to greyscale.
>
> What I am curious is how can you say you will get 66%. Have you used
> any particular coder/implmentation?
>
Well, if you convert a 24 bits/pixel colour image to an 8 bit/pixel
greyscale one like Benjamin implies, you'll easily get the mentioned 66%.
Without any other algorithm than some kind of weighing of the say RGB
components.
> -Parker
>
[snip apparent integral quote of Benjamin's text]
Regards,
Wimjan
--
Sleet is van vroeger, tegenwoordig gaat alles kapot.
shamee...@gmail.com
shamee...@gmail.com
> ppl,
> http://www.matrixview.com/en/archive/articles/downloads/mv%20technology/MatrixView%20White%20Paper%20-%20Honey%20I%20Shrunk%20the%20Bits!.pdf
>
> claims 4-5 times better than JPEG and says lossless compression ..
>
> has anyone done any public domain work similar to that ??
>
>
>
> -micromysore
can anone post me the code for abo compression please