If I go with this procedure what difficulties will I face?
Now I've a file of 1GB i.e 110101010001001010 of 1gigabits.
Next step I'll try to make a image of it,arranging individual 1s & 0s
as in the original file in "CCITT Group 4 format"

assuming that 12000x8000 pixels bi level image is appx 100-200KB
1GB will give you anywhere b/w  1-2MB.Now the file is ready
Again to retrieve the original file what shall I've to do?

Nimo wrote:
> If I go with this procedure what difficulties will I face?
> Now I've a file of 1GB i.e 110101010001001010 of 1gigabits. 
> Next step I'll try to make a image of it,arranging individual 1s & 0s
> as in the original file in "CCITT Group 4 format"
> 
> assuming that 12000x8000 pixels bi level image is appx 100-200KB
> 1GB will give you anywhere b/w  1-2MB.Now the file is ready
> Again to retrieve the original file what shall I've to do?

a) Understanding what you're trying to do. Applying CCITT to data that 
is *not* a scanned bi-level image is not a smart idea. Specifically, try
to understand the concept of a "random source" and "a (data) model".

b) Read the CCITT specs how to reconstruct the data.

c) Don't expect miracles (but do a) first).

So long,
	Thomas

> c) Don't expect miracles (but do a) first).
>
> So long,
> =A0 =A0 =A0 =A0 Thomas


why can't I expect better compression ratio
whats the reason?

Nimo schrieb:
>> c) Don't expect miracles (but do a) first).
>>
>> So long,
>>         Thomas
> 
> 
> why can't I expect better compression ratio
> whats the reason?

How should I know? Better than what? The compression ratio depends on
the source you want to compress (to repeat myself). Unless you are
compressing scanned bi-level images (text, lineart, etc...) you will not
get any reasonable compression because the random model underlying CCITT
compression fits to the sources it is designed for.

So long,
	Thomas

Ok thanks for your good hint,any how I put myself this weekend
my target as to come up with a sloution to this 50 or 60 years of saga
of compression world.

"At the end data compression is not at all Rocket Engineering".
I'm going to start a new thread all the ideas I've in my mind to
discuss.

On Oct 24, 3:07=A0am, Nimo <azeez...@gmail.com> wrote:
> Ok thanks for your good hint,any how I put myself this weekend
> my target as to come up with a sloution to this 50 or 60 years of saga
> of compression world.
>
> "At the end data compression is not at all Rocket Engineering".
> I'm going to start a new thread all the ideas I've in my mind to
> discuss.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


(Hello, Nimo!  Welcome.)


I've been working on compression issues for a little less than 15
years.  And only now, after working on this topic only part-time,
(well, most of the time,) probably the equivalent of about five years,
have I accomplished what I set out to do, and to do it efficiently.

Today, in one quick pass, I took a 92k-byte bzip2 file (ie., a file
that had already been compressed,) and piped it through the compressor/
decompressor I intend to use when I come down to Texas to take Mark's
hard earned money.

My program isn't really very good at all -- it only does about 3,000
to 1, and in a single pass!  And worse, most files are made so small
that they don't present a sufficiently significant chunk for my
program to perform a second physical pass.

The facts with one omission are accurate as stated in the prior
paragraph.

And what's the omission?  I have a very complex getBIT/putBIT
arrangement, not the usual bit-I/O stuff but something very
different;  Well, the data comes in okay, but leaves not-so-hot.  Over
the course (this is measured,) of 1450 bytes, about 25 are faulty,
those bytes contain single bit-errors.

I know, with savings like this (92k to 32 bytes,) I could simply do it
three or even five times and vote the bits -- and it may come that.

I'm spending this week looking at the problem.

I realize that few people believe me;  For now, that's alright.  Some
things take time and when my investors say "okay", well, we have
plans.

But soon.  How soon?  Soon.  A month?  Yes, probably about a month.

And what will happen then?  Well, for one thing a lot of you folks
will look so incredibly foolish -- though I'll stick up for you.  I'll
say that we live in different worlds, the rules are different in my
world.

Do we share the same physical space?  Yes.  The same physics?  Yes.
The same math?  Yes.  Then what's different?  It works better if you
work this out yourself...

--jg

jules Gilbert wrote:
> On Oct 24, 3:07=EF=BF=BDam, Nimo <azeez...@gmail.com> wrote:
> > Ok thanks for your good hint,any how I put myself this weekend
> > my target as to come up with a sloution to this 50 or 60 years of saga
> > of compression world.
> >
> > "At the end data compression is not at all Rocket Engineering".
> > I'm going to start a new thread all the ideas I've in my mind to
> > discuss.
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
> (Hello, Nimo!  Welcome.)
>
>
> I've been working on compression issues for a little less than 15
> years.  And only now, after working on this topic only part-time,
> (well, most of the time,) probably the equivalent of about five years,
> have I accomplished what I set out to do, and to do it efficiently.
>
> Today, in one quick pass, I took a 92k-byte bzip2 file (ie., a file
> that had already been compressed,) and piped it through the compressor/
> decompressor I intend to use when I come down to Texas to take Mark's
> hard earned money.
>
> My program isn't really very good at all -- it only does about 3,000
> to 1, and in a single pass!  And worse, most files are made so small
> that they don't present a sufficiently significant chunk for my
> program to perform a second physical pass.
>
> The facts with one omission are accurate as stated in the prior
> paragraph.
>
> And what's the omission?  I have a very complex getBIT/putBIT
> arrangement, not the usual bit-I/O stuff but something very
> different;  Well, the data comes in okay, but leaves not-so-hot.  Over
> the course (this is measured,) of 1450 bytes, about 25 are faulty,
> those bytes contain single bit-errors.
>
> I know, with savings like this (92k to 32 bytes,) I could simply do it
> three or even five times and vote the bits -- and it may come that.
>
> I'm spending this week looking at the problem.
>
> I realize that few people believe me;  For now, that's alright.  Some
> things take time and when my investors say "okay", well, we have
> plans.
>
> But soon.  How soon?  Soon.  A month?  Yes, probably about a month.
>
> And what will happen then?  Well, for one thing a lot of you folks
> will look so incredibly foolish -- though I'll stick up for you.  I'll
> say that we live in different worlds, the rules are different in my
> world.
>
> Do we share the same physical space?  Yes.  The same physics?  Yes.
> The same math?  Yes.  Then what's different?  It works better if you
> work this out yourself...
>
> --jg





yeah can you give more details,it will helpful for me
Thanks.

On Oct 27, 12:14 am, jules Gilbert <jules.sto...@gmail.com> wrote:
> On Oct 24, 3:07 am, Nimo <azeez...@gmail.com> wrote:
>
> > Ok thanks for your good hint,any how I put myself this weekend
> > my target as to come up with a sloution to this 50 or 60 years of saga
> > of compression world.
>
> > "At the end data compression is not at all Rocket Engineering".
> > I'm going to start a new thread all the ideas I've in my mind to
> > discuss.
>
> ==========
>
> (Hello, Nimo!  Welcome.)
>
> I've been working on compression issues for a little less than 15
> years.  And only now, after working on this topic only part-time,
> (well, most of the time,) probably the equivalent of about five years,
> have I accomplished what I set out to do, and to do it efficiently.
>
> Today, in one quick pass, I took a 92k-byte bzip2 file (ie., a file
> that had already been compressed,) and piped it through the compressor/
> decompressor I intend to use when I come down to Texas to take Mark's
> hard earned money.
>
> My program isn't really very good at all -- it only does about 3,000
> to 1, and in a single pass!  And worse, most files are made so small
> that they don't present a sufficiently significant chunk for my
> program to perform a second physical pass.
>
> The facts with one omission are accurate as stated in the prior
> paragraph.
>
> And what's the omission?  I have a very complex getBIT/putBIT
> arrangement, not the usual bit-I/O stuff but something very
> different;  Well, the data comes in okay, but leaves not-so-hot.  Over
> the course (this is measured,) of 1450 bytes, about 25 are faulty,
> those bytes contain single bit-errors.
>
> I know, with savings like this (92k to 32 bytes,) I could simply do it
> three or even five times and vote the bits -- and it may come that.
>
> I'm spending this week looking at the problem.
>
> I realize that few people believe me;  For now, that's alright.  Some
> things take time and when my investors say "okay", well, we have
> plans.
>
> But soon.  How soon?  Soon.  A month?  Yes, probably about a month.
>
> And what will happen then?  Well, for one thing a lot of you folks
> will look so incredibly foolish -- though I'll stick up for you.  I'll
> say that we live in different worlds, the rules are different in my
> world.
>
> Do we share the same physical space?  Yes.  The same physics?  Yes.
> The same math?  Yes.  Then what's different?  It works better if you
> work this out yourself...
>
> --jg

Nimo, don't listen to this psychopath, he's full of shit.

On Oct 28, 12:30=A0pm, Industrial One <industrial_...@hotmail.com>
wrote:
> On Oct 27, 12:14 am, jules Gilbert <jules.sto...@gmail.com> wrote:
>
>
>
> > On Oct 24, 3:07 am, Nimo <azeez...@gmail.com> wrote:
>
> > > Ok thanks for your good hint,any how I put myself this weekend
> > > my target as to come up with a sloution to this 50 or 60 years of sag=
a
> > > of compression world.
>
> > > "At the end data compression is not at all Rocket Engineering".
> > > I'm going to start a new thread all the ideas I've in my mind to
> > > discuss.
>
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> > (Hello, Nimo! =A0Welcome.)
>
> > I've been working on compression issues for a little less than 15
> > years. =A0And only now, after working on this topic only part-time,
> > (well, most of the time,) probably the equivalent of about five years,
> > have I accomplished what I set out to do, and to do it efficiently.
>
> > Today, in one quick pass, I took a 92k-byte bzip2 file (ie., a file
> > that had already been compressed,) and piped it through the compressor/
> > decompressor I intend to use when I come down to Texas to take Mark's
> > hard earned money.
>
> > My program isn't really very good at all -- it only does about 3,000
> > to 1, and in a single pass! =A0And worse, most files are made so small
> > that they don't present a sufficiently significant chunk for my
> > program to perform a second physical pass.
>
> > The facts with one omission are accurate as stated in the prior
> > paragraph.
>
> > And what's the omission? =A0I have a very complex getBIT/putBIT
> > arrangement, not the usual bit-I/O stuff but something very
> > different; =A0Well, the data comes in okay, but leaves not-so-hot. =A0O=
ver
> > the course (this is measured,) of 1450 bytes, about 25 are faulty,
> > those bytes contain single bit-errors.
>
> > I know, with savings like this (92k to 32 bytes,) I could simply do it
> > three or even five times and vote the bits -- and it may come that.
>
> > I'm spending this week looking at the problem.
>
> > I realize that few people believe me; =A0For now, that's alright. =A0So=
me
> > things take time and when my investors say "okay", well, we have
> > plans.
>
> > But soon. =A0How soon? =A0Soon. =A0A month? =A0Yes, probably about a mo=
nth.
>
> > And what will happen then? =A0Well, for one thing a lot of you folks
> > will look so incredibly foolish -- though I'll stick up for you. =A0I'l=
l
> > say that we live in different worlds, the rules are different in my
> > world.
>
> > Do we share the same physical space? =A0Yes. =A0The same physics? =A0Ye=
s.
> > The same math? =A0Yes. =A0Then what's different? =A0It works better if =
you
> > work this out yourself...
>
> > --jg
>
> Nimo, don't listen to this psychopath, he's full of shit.

@ industrial one any problem with this guy?
Thanks:)

Nimo wrote:

>> Nimo, don't listen to this psychopath, he's full of shit.
> 
> @ industrial one any problem with this guy?

Since you seem to new here, a couple of facts (and I mean facts and not 
"conjectures"):

Jules is around here for more then ten years, claiming every time he's 
showing up having invented the ultimate compression program, and failed 
every single time to provide any evidence for its existence, usually 
with rather goofy arguments. Most of his inventions break elementary 
rules of logic, such as that there is no invertible N to M mapping for N 
 > M, so only very little training will allow you to prove him wrong. I 
throw $100 into the pot for betting he's unable to give a demonstration 
of his invention this time yet again. Demonstration again by the very 
same rules people posted here over again:
a) Jules makes binaries for his compressor available,
b) I (or someone else) downloads that executable,
c) I (or someone) creates a test-corpus of files,
d) Jules compresses the files
e) Jules makes the files available for download,
f) I (or someone else) expands the files with the executable from the 
step b) above,
g) if all expanded files compare equal to the original, and all 
compressed files are smaller than the input files, Jules wins, otherwise 
I (or someone else) wins.

 From the same argument also follows that you cannot compress any file 
to 77 bits, we're making only a bit fun of you here - sorry.

As a survival kit for this group, make sure you understand the "counting 
argument", one of the very easy, and very basic foundations of 
compression, also known as pigeon hole principle. I don't want to spoil 
your fun learning it, so I won't post it here, but it's really a matter 
of counting correctly to see that it is impossible to compress *every* 
possible file, you always must make most of them larger while only 
making some of them smaller.

The art is picking the sub-set of the files that get smaller under 
compression such that it contains *interesting* files. Not to avoid any 
expansion, which is impossible.

So long,
	Thomas

On 29 Okt., 21:52, Thomas Richter <t...@math.tu-berlin.de> wrote:
>  From the same argument also follows that you cannot compress any file
> to 77 bits, we're making only a bit fun of you here - sorry.
>
> As a survival kit for this group, make sure you understand the "counting
> argument", one of the very easy, and very basic foundations of
> compression, also known as pigeon hole principle. I don't want to spoil
> your fun learning it, so I won't post it here, but it's really a matter
> of counting correctly to see that it is impossible to compress *every*
> possible file, you always must make most of them larger while only
> making some of them smaller.
>
> The art is picking the sub-set of the files that get smaller under
> compression such that it contains *interesting* files. Not to avoid any
> expansion, which is impossible.
>
> So long,
>         Thomas

Richie, you forget that you backed off during that discussion with
Jacko, so you got no place pretending to be dissing anyone here.

The counting argument for the most part is valid, but only pertaining
to space. What about time? If a bit is in a different state next
millisecond, then the amount of existing physical constants is
irrelevant. At least, that's how I understand the abstract of Jacko's
thereom. I'm way too dumb to grasp his math and follow discussion.

Industrial One schrieb:
> On 29 Okt., 21:52, Thomas Richter <t...@math.tu-berlin.de> wrote:
>>  From the same argument also follows that you cannot compress any file
>> to 77 bits, we're making only a bit fun of you here - sorry.
>>
>> As a survival kit for this group, make sure you understand the "counting
>> argument", one of the very easy, and very basic foundations of
>> compression, also known as pigeon hole principle. I don't want to spoil
>> your fun learning it, so I won't post it here, but it's really a matter
>> of counting correctly to see that it is impossible to compress *every*
>> possible file, you always must make most of them larger while only
>> making some of them smaller.
>>
>> The art is picking the sub-set of the files that get smaller under
>> compression such that it contains *interesting* files. Not to avoid any
>> expansion, which is impossible.
>>
>> So long,
>>         Thomas
> 
> Richie, you forget that you backed off during that discussion with
> Jacko, so you got no place pretending to be dissing anyone here.
> 
> The counting argument for the most part is valid, but only pertaining
> to space. What about time? If a bit is in a different state next
> millisecond, then the amount of existing physical constants is
> irrelevant. At least, that's how I understand the abstract of Jacko's
> thereom. I'm way too dumb to grasp his math and follow discussion.

Mathematics is not about physical existence; it is a logical argument,
not a physical one. Whether the stream exists in space, or time, or not
at all doesn't matter. If I want to be able to reconstruct a given
sequence, let them exist in time or in space, or not at all, I need to
make sure that no two input sequences map to the same output. Thus, the
counting argument is not a limitation of physics. It is a limitation
that is implied by what is meant by compression (namely, to be able to
uniquely recover the source). You cannot have one without the other.

So long,
	Thmas

On Oct 29, 9:39=A0pm, Industrial One <industrial_...@hotmail.com> wrote:
> I'm way too dumb to grasp his math and follow discussion.

While I'm going to sidestep the obvious jokes I could make in the
above, I will say that you are not "too dumb to grasp his math" -- his
math is flawed like all of the other infinite compression nutjobs.

Jacko's method is actually a variation on the "magic function" theory
(this is the same as Jules, actually), where people think that they
are able to analyze random data, find a pattern or patterns, and come
up with a function (ie. a random number generator) that produces
either the same or nearly the same output as the source.

Most people who try to write "magic function" compressors find that
the output is nowhere near close to the original, and then assume that
they can still use their idea and store the differences in the output
to reconstruct the original.  After implementing this, they find that
(function + list of differences) > (size of original file) and give
up.  Well... except for Jules and Jacko.

On Oct 30, 7:35 am, Thomas Richter <t...@math.tu-berlin.de> wrote:
> Industrial One schrieb:
>
>
>
> > On 29 Okt., 21:52, Thomas Richter <t...@math.tu-berlin.de> wrote:
> >>  From the same argument also follows that you cannot compress any file
> >> to 77 bits, we're making only a bit fun of you here - sorry.
>
> >> As a survival kit for this group, make sure you understand the "counting
> >> argument", one of the very easy, and very basic foundations of
> >> compression, also known as pigeon hole principle. I don't want to spoil
> >> your fun learning it, so I won't post it here, but it's really a matter
> >> of counting correctly to see that it is impossible to compress *every*
> >> possible file, you always must make most of them larger while only
> >> making some of them smaller.
>
> >> The art is picking the sub-set of the files that get smaller under
> >> compression such that it contains *interesting* files. Not to avoid any
> >> expansion, which is impossible.
>
> >> So long,
> >>         Thomas
>
> > Richie, you forget that you backed off during that discussion with
> > Jacko, so you got no place pretending to be dissing anyone here.
>
> > The counting argument for the most part is valid, but only pertaining
> > to space. What about time? If a bit is in a different state next
> > millisecond, then the amount of existing physical constants is
> > irrelevant. At least, that's how I understand the abstract of Jacko's
> > thereom. I'm way too dumb to grasp his math and follow discussion.
>
> Mathematics is not about physical existence; it is a logical argument,
> not a physical one. Whether the stream exists in space, or time, or not
> at all doesn't matter. If I want to be able to reconstruct a given
> sequence, let them exist in time or in space, or not at all, I need to
> make sure that no two input sequences map to the same output. Thus, the
> counting argument is not a limitation of physics. It is a limitation
> that is implied by what is meant by compression (namely, to be able to
> uniquely recover the source). You cannot have one without the other.
>
> So long,
>         Thmas

Exactly. I'm saying you're only applying the counting argument to the
first case and ignoring the other.

On Oct 30, 4:00 pm, Jim Leonard <MobyGa...@gmail.com> wrote:
> On Oct 29, 9:39 pm, Industrial One <industrial_...@hotmail.com> wrote:
>
> > I'm way too dumb to grasp his math and follow discussion.
>
> While I'm going to sidestep the obvious jokes I could make in the
> above, I will say that you are not "too dumb to grasp his math" -- his
> math is flawed like all of the other infinite compression nutjobs.
>
> Jacko's method is actually a variation on the "magic function" theory
> (this is the same as Jules, actually), where people think that they
> are able to analyze random data, find a pattern or patterns, and come
> up with a function (ie. a random number generator) that produces
> either the same or nearly the same output as the source.
>
> Most people who try to write "magic function" compressors find that
> the output is nowhere near close to the original, and then assume that
> they can still use their idea and store the differences in the output
> to reconstruct the original.  After implementing this, they find that
> (function + list of differences) > (size of original file) and give
> up.  Well... except for Jules and Jacko.

That's not what Jacko's theory consists of. Hell, that ain't even how
the magic function theory works. It's not that I can't grasp math, I
just go apeshit when trying to concentrate too long, (I fucked up on
many algebra exams 'cuz I didn't pay attention to the -/+ signs) but
if I took some time to chillax, sit down and have Jacko on an IM
keeping me on-track, I might get somewhere.

Definitely not today. Now 'scuse me while I snack on my huge stash of
Halloween candy 'till I get fuckin sick.