Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #89274 > unrolled thread

[sOT] compression 1 GB downto 100 MB

Back to article view | Back to comp.lang.c

Contents

  [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-16 07:25 -0700
    Re: [sOT] compression 1 GB downto 100 MB mark.bluemel@gmail.com - 2016-06-16 08:08 -0700
      Re: [sOT] compression 1 GB downto 100 MB Lynn McGuire <lmc@winsim.com> - 2016-06-17 12:04 -0500
        Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 10:16 -0700
          Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-17 23:08 -0700
    Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 08:09 -0700
      Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-16 08:15 -0700
        Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-16 08:18 -0700
          Re: [sOT] compression 1 GB downto 100 MB mark.bluemel@gmail.com - 2016-06-17 01:28 -0700
            Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 02:03 -0700
              Re: [sOT] compression 1 GB downto 100 MB Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 10:34 +0100
                Re: [sOT] compression 1 GB downto 100 MB BartC <bc@freeuk.com> - 2016-06-17 10:44 +0100
                  Re: [sOT] compression 1 GB downto 100 MB Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 11:03 +0100
                    Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 03:51 -0700
                      Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-18 02:16 -0700
                        Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-18 02:29 -0700
                    Re: [sOT] compression 1 GB downto 100 MB "Osmium" <r124c4u102@comcast.net> - 2016-06-17 08:19 -0500
                  Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-18 03:17 -0700
                Re: [sOT] compression 1 GB downto 100 MB Gareth Owen <gwowen@gmail.com> - 2016-06-17 18:32 +0100
        Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 08:43 -0700
          Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-16 08:48 -0700
        Re: [sOT] compression 1 GB downto 100 MB "Osmium" <r124c4u102@comcast.net> - 2016-06-16 10:49 -0500
          Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-16 09:10 -0700
            Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 09:36 -0700
              Re: [sOT] compression 1 GB downto 100 MB Keith Thompson <kst-u@mib.org> - 2016-06-16 11:18 -0700
            Re: [sOT] compression 1 GB downto 100 MB "Osmium" <r124c4u102@comcast.net> - 2016-06-16 13:13 -0500
              Re: [sOT] compression 1 GB downto 100 MB Gareth Owen <gwowen@gmail.com> - 2016-06-16 20:18 +0100
                Re: [sOT] compression 1 GB downto 100 MB Richard Heathfield <rjh@cpax.org.uk> - 2016-06-16 22:07 +0100
                  Re: [sOT] compression 1 GB downto 100 MB Gareth Owen <gwowen@gmail.com> - 2016-06-17 06:04 +0100
                Re: [sOT] compression 1 GB downto 100 MB Robert Wessel <robertwessel2@yahoo.com> - 2016-06-16 23:21 -0500
                  Re: [sOT] compression 1 GB downto 100 MB "Osmium" <r124c4u102@comcast.net> - 2016-06-17 07:49 -0500
                    Re: [sOT] compression 1 GB downto 100 MB Robert Wessel <robertwessel2@yahoo.com> - 2016-06-17 12:47 -0500
                      Re: [sOT] compression 1 GB downto 100 MB "Osmium" <r124c4u102@comcast.net> - 2016-06-17 14:47 -0500
                        Re: [sOT] compression 1 GB downto 100 MB Robert Wessel <robertwessel2@yahoo.com> - 2016-06-17 23:32 -0500
                          Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-18 01:33 -0700
              Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-17 14:51 -0700
        Re: [sOT] compression 1 GB downto 100 MB BartC <bc@freeuk.com> - 2016-06-16 16:50 +0100
          Re: [sOT] compression 1 GB downto 100 MB BartC <bc@freeuk.com> - 2016-06-17 16:20 +0100
      Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-16 08:34 -0700
    Re: [sOT] compression 1 GB downto 100 MB Les Cargill <lcargill99@comcast.com> - 2016-06-16 12:55 -0500
    Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-16 11:53 -0700
      Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-16 12:14 -0700
      Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-17 12:33 -0700
        Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-17 12:46 -0700
      Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-17 15:04 -0700
        Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-17 22:55 -0700
          Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-18 01:38 -0700
            Re: [sOT] compression 1 GB downto 100 MB BartC <bc@freeuk.com> - 2016-06-18 10:41 +0100
              Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-18 02:55 -0700
              Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 05:08 -0700
                Re: [sOT] compression 1 GB downto 100 MB "Bill Cunningham" <nospam@nspam.invalid> - 2016-06-18 15:11 -0400
                  Re: [sOT] compression 1 GB downto 100 MB "Bill Cunningham" <nospam@nspam.invalid> - 2016-06-18 15:13 -0400
                  Re: [sOT] compression 1 GB downto 100 MB luser droog <luser.droog@gmail.com> - 2016-06-18 12:43 -0700
                  Re: [sOT] compression 1 GB downto 100 MB Richard Heathfield <rjh@cpax.org.uk> - 2016-06-18 20:43 +0100
                    Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-18 12:53 -0700
                      Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-20 20:32 -0700
                    Re: [sOT] compression 1 GB downto 100 MB Keith Thompson <kst-u@mib.org> - 2016-06-18 13:22 -0700
                      Re: [sOT] compression 1 GB downto 100 MB Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-18 16:35 -0400
                        Re: [sOT] compression 1 GB downto 100 MB Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-18 21:37 -0400
                      Re: [sOT] compression 1 GB downto 100 MB "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-18 16:59 -0400
                        Re: [sOT] compression 1 GB downto 100 MB crisdunbar@gmail.com - 2016-06-20 09:55 -0700
                          Re: [sOT] compression 1 GB downto 100 MB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 21:22 +0100
                            Re: [sOT] compression 1 GB downto 100 MB cris <crisdunbar@gmail.com> - 2016-06-20 17:13 -0700
                            Re: [sOT] compression 1 GB downto 100 MB Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-21 10:42 -0700
                              Re: [sOT] compression 1 GB downto 100 MB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-21 20:09 +0100
                                Re: [sOT] compression 1 GB downto 100 MB crisdunbar@gmail.com - 2016-06-21 13:39 -0700
                                Re: [sOT] compression 1 GB downto 100 MB Keith Thompson <kst-u@mib.org> - 2016-06-22 08:34 -0700
                                  Re: [sOT] compression 1 GB downto 100 MB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-22 19:48 +0100
                    Re: [sOT] compression 1 GB downto 100 MB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 01:37 +0100
                      Re: [sOT] compression 1 GB downto 100 MB Richard Heathfield <rjh@cpax.org.uk> - 2016-06-19 02:22 +0100
                        Re: [sOT] compression 1 GB downto 100 MB Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-18 21:30 -0400
                          Re: [sOT] compression 1 GB downto 100 MB Richard Heathfield <rjh@cpax.org.uk> - 2016-06-19 02:41 +0100
                            Re: [sOT] compression 1 GB downto 100 MB Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-18 21:55 -0400
                        Re: [sOT] compression 1 GB downto 100 MB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 03:20 +0100
                          Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-19 02:53 -0700
                  Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 16:05 -0700
                    Re: [sOT] compression 1 GB downto 100 MB "J. Clarke" <j.clarke.873638@gmail.com> - 2016-06-19 06:59 -0400
                      Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-19 05:55 -0700
                      Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 06:13 -0700
                        Re: [sOT] compression 1 GB downto 100 MB "J. Clarke" <j.clarke.873638@gmail.com> - 2016-06-26 12:26 -0400
                          Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-26 09:53 -0700
                Re: [sOT] compression 1 GB downto 100 MB Richard Heathfield <rjh@cpax.org.uk> - 2016-06-18 20:41 +0100
                Re: [sOT] compression 1 GB downto 100 MB "J. Clarke" <j.clarke.873638@gmail.com> - 2016-06-19 06:45 -0400
              Re: [sOT] compression 1 GB downto 100 MB Robert Wessel <robertwessel2@yahoo.com> - 2016-06-18 14:42 -0500
              Re: [sOT] compression 1 GB downto 100 MB gordonb.vnsk1@burditt.org (Gordon Burditt) - 2016-06-20 01:13 -0500
                Re: [sOT] compression 1 GB downto 100 MB Keith Thompson <kst-u@mib.org> - 2016-06-20 12:16 -0700
                  Re: [sOT] compression 1 GB downto 100 MB David Brown <david.brown@hesbynett.no> - 2016-06-20 21:27 +0200
                    Re: [sOT] compression 1 GB downto 100 MB Xaltonon <xaltonon@gmail.com> - 2016-06-20 21:25 -0700

Page 1 of 5  [1] 2 3 4 5  Next page →

#89274 — [sOT] compression 1 GB downto 100 MB

GOD how great it would be have an algorith that would compress totays data which rae not much compressibl;e (like game ISo files, movies, zip archives) like many times, say ten times

wouldnt it be great? do you think that it is 
possible? (im sure it is not really obtainable but other thing if this is not impossible 'in fact') 

Imagine how great it would be :U

[toc] | [next] | [standalone]

#89279

On Thursday, 16 June 2016 15:25:42 UTC+1, fir  wrote:
> GOD how great it would be have an algorith that would compress totays data which rae not much compressibl;e (like game ISo files, movies, zip archives) like many times, say ten times
> 
> wouldnt it be great? do you think that it is 
> possible? (im sure it is not really obtainable but other thing if this is not impossible 'in fact') 
> 
> Imagine how great it would be :U

Do you want the compression to be reversible?

[toc] | [prev] | [next] | [standalone]

#89433

On 6/16/2016 10:08 AM, mark.bluemel@gmail.com wrote:
> On Thursday, 16 June 2016 15:25:42 UTC+1, fir  wrote:
>> GOD how great it would be have an algorith that would compress totays data which rae not much compressibl;e (like game ISo files, movies, zip archives) like many times, say ten times
>>
>> wouldnt it be great? do you think that it is
>> possible? (im sure it is not really obtainable but other thing if this is not impossible 'in fact')
>>
>> Imagine how great it would be :U
>
> Do you want the compression to be reversible?

Are you talking about lossless or lossy compression algorithms?  Lossy algorithms do compress way more than lossless.

Lynn

[toc] | [prev] | [next] | [standalone]

#89434

On Friday, June 17, 2016 at 6:04:10 PM UTC+1, Lynn McGuire wrote:
> 
> Are you talking about lossless or lossy compression algorithms?  Lossy algorithms do 
> compress way more than lossless.
> 
There's also no theoretical limit.

You can get nice compression by faking up details with fractals, for example.
So the result looks visually complex and are acceptable. But you're just inventing
information, you're not actually reproducing the original.

[toc] | [prev] | [next] | [standalone]

#89504

On 6/17/2016 10:16 AM, Malcolm McLean wrote:
> On Friday, June 17, 2016 at 6:04:10 PM UTC+1, Lynn McGuire wrote:
>>
>> Are you talking about lossless or lossy compression algorithms?  Lossy algorithms do
>> compress way more than lossless.
>>
> There's also no theoretical limit.
>
> You can get nice compression by faking up details with fractals, for example.
> So the result looks visually complex and are acceptable. But you're just inventing
> information, you're not actually reproducing the original.
>
>


Yup. I have always found fractal image compression to be quite 
fascinating. I like the way it can turn a scene of nature into 
probability ranges and create IFS formulas that use them. The neat part 
is that decoding is just iterating these formulas, or codes, and 
plotting the results to the screen resulting in a fractal representation 
of the original image.

[toc] | [prev] | [next] | [standalone]

#89280

On Thursday, June 16, 2016 at 3:25:42 PM UTC+1, fir wrote:
> GOD how great it would be have an algorith that would compress totays data which rae not much 
> compressibl;e (like game ISo files, movies, zip archives) like many times, say ten times
> 
> wouldnt it be great? do you think that it is 
> possible? (im sure it is not really obtainable but other thing if this is not impossible 'in fact') 
> 
> Imagine how great it would be :U
>
Unfortunately there are theoretical limits on how far you can compress data without prior
information about what that data represents.
Movies, for example, are almost certainly already MPEG compressed. That strips out
essentially all of the redundancy. The only way of getting better compression is to have
a database of all movie clips ever produced (that's not necessarily impractical) and
to replace the movies with a reference to that database.
You can't just feed the MPEG stream to a general purpose compressor and expect it
to compress it. If it were that easy the general purpose compressor would have already
been included in the MPEG standard, and in fact it is - MPEG creates a Huffman-friendly
output stream then uses a fairly standard Huffman compressor to achieve the final bit 
reduction. 

[toc] | [prev] | [next] | [standalone]

#89282

W dniu czwartek, 16 czerwca 2016 17:09:24 UTC+2 użytkownik Malcolm McLean napisał:
> On Thursday, June 16, 2016 at 3:25:42 PM UTC+1, fir wrote:
> > GOD how great it would be have an algorith that would compress totays data which rae not much 
> > compressibl;e (like game ISo files, movies, zip archives) like many times, say ten times
> > 
> > wouldnt it be great? do you think that it is 
> > possible? (im sure it is not really obtainable but other thing if this is not impossible 'in fact') 
> > 
> > Imagine how great it would be :U
> >
> Unfortunately there are theoretical limits on how far you can compress data without prior
> information about what that data represents.
> Movies, for example, are almost certainly already MPEG compressed. That strips out
> essentially all of the redundancy. The only way of getting better compression is to have
> a database of all movie clips ever produced (that's not necessarily impractical) and
> to replace the movies with a reference to that database.
> You can't just feed the MPEG stream to a general purpose compressor and expect it
> to compress it. If it were that easy the general purpose compressor would have already
> been included in the MPEG standard, and in fact it is - MPEG creates a Huffman-friendly
> output stream then uses a fairly standard Huffman compressor to achieve the final bit 
> reduction.

I dont think "The only way" is proven - this is probably just false and I wouldnt be maybe surprised if there is a way to compres .mpg's 10 times yet
(but i dont know the details on compression never worked in it) If someonne knows maybe what is a source of this impossibility (of compressing .mpgs or .iso 10 times) it would be good to discuss it maybe

[toc] | [prev] | [next] | [standalone]

#89283

W dniu czwartek, 16 czerwca 2016 17:15:42 UTC+2 użytkownik fir napisał:
> W dniu czwartek, 16 czerwca 2016 17:09:24 UTC+2 użytkownik Malcolm McLean napisał:
> > On Thursday, June 16, 2016 at 3:25:42 PM UTC+1, fir wrote:
> > > GOD how great it would be have an algorith that would compress totays data which rae not much 
> > > compressibl;e (like game ISo files, movies, zip archives) like many times, say ten times
> > > 
> > > wouldnt it be great? do you think that it is 
> > > possible? (im sure it is not really obtainable but other thing if this is not impossible 'in fact') 
> > > 
> > > Imagine how great it would be :U
> > >
> > Unfortunately there are theoretical limits on how far you can compress data without prior
> > information about what that data represents.
> > Movies, for example, are almost certainly already MPEG compressed. That strips out
> > essentially all of the redundancy. The only way of getting better compression is to have
> > a database of all movie clips ever produced (that's not necessarily impractical) and
> > to replace the movies with a reference to that database.
> > You can't just feed the MPEG stream to a general purpose compressor and expect it
> > to compress it. If it were that easy the general purpose compressor would have already
> > been included in the MPEG standard, and in fact it is - MPEG creates a Huffman-friendly
> > output stream then uses a fairly standard Huffman compressor to achieve the final bit 
> > reduction.
> 
> I dont think "The only way" is proven - this is probably just false and I wouldnt be maybe surprised if there is a way to compres .mpg's 10 times yet
> (but i dont know the details on compression never worked in it) If someonne knows maybe what is a source of this impossibility (of compressing .mpgs or .iso 10 times) it would be good to discuss it maybe

right now the compression race seems to me like the 100m or 1000 m olympic run and world records - but i could think people are rather on the begining than on the end in the list of this world records 

[toc] | [prev] | [next] | [standalone]

#89372

On Thursday, 16 June 2016 16:18:35 UTC+1, fir  wrote:

> right now the compression race seems to me like the 100m or 1000 m olympic
> run and world records - but i could think people are rather on the begining 
> than on the end in the list of this world records

You could think that, but you'd be wrong, a situation which is all to familiar.

[toc] | [prev] | [next] | [standalone]

#89376

On Friday, June 17, 2016 at 9:29:09 AM UTC+1, mark.b...@gmail.com wrote:
> On Thursday, 16 June 2016 16:18:35 UTC+1, fir  wrote:
> 
> > right now the compression race seems to me like the 100m or 1000 m olympic
> > run and world records - but i could think people are rather on the begining 
> > than on the end in the list of this world records
> 
> You could think that, but you'd be wrong, a situation which is all to familiar.
>
Depends what you mean.
I remember as a child talking about how much TV you could fit on a computer
hard drive. I think we came up with a  figure of 4 seconds. MPEG hadn't come
out and we were totally ignorant of the redundancies that could be exposed
by putting the image into the frequency domain.
But there are other redundancies MPEG fails to exploit. If you have a model for
how people move, and the image consists of humans moving about a largely
static background, for example, you could potentially compress the scene
massively by describing the characters in vector space.

[toc] | [prev] | [next] | [standalone]

#89378

On 17/06/16 10:03, Malcolm McLean wrote:
> On Friday, June 17, 2016 at 9:29:09 AM UTC+1, mark.b...@gmail.com wrote:
>> On Thursday, 16 June 2016 16:18:35 UTC+1, fir  wrote:
>>
>>> right now the compression race seems to me like the 100m or 1000 m olympic
>>> run and world records - but i could think people are rather on the begining
>>> than on the end in the list of this world records
>>
>> You could think that, but you'd be wrong, a situation which is all to familiar.
>>
> Depends what you mean.

No, it doesn't.

> I remember as a child talking about how much TV you could fit on a computer
> hard drive. I think we came up with a  figure of 4 seconds.

It hardly matters, and you're missing the point. If there were a way to 
guarantee the compression of arbitrary data, /all/ data could be reduced 
to a single bit.

Good luck decompressing that.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#89380

On 17/06/2016 10:34, Richard Heathfield wrote:
> On 17/06/16 10:03, Malcolm McLean wrote:

>> I remember as a child talking about how much TV you could fit on a
>> computer
>> hard drive. I think we came up with a  figure of 4 seconds.
>
> It hardly matters, and you're missing the point. If there were a way to
> guarantee the compression of arbitrary data, /all/ data could be reduced
> to a single bit.

fir wasn't talking about a single bit, but a further reduction of one 
magnitude in compression rates.

Several magnitudes have already been achieved with things such as video. 
Plus hard drive capacities have increased too...

And, if you consider video generated via computer animation, possibly 
that /could/ be reduced to a series of formulae so that it could 
effectively be compressed by at least a magnitude compared with video 
captured from real life.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#89384

On 17/06/16 10:44, BartC wrote:
> On 17/06/2016 10:34, Richard Heathfield wrote:
>> On 17/06/16 10:03, Malcolm McLean wrote:
>
>>> I remember as a child talking about how much TV you could fit on a
>>> computer
>>> hard drive. I think we came up with a  figure of 4 seconds.
>>
>> It hardly matters, and you're missing the point. If there were a way to
>> guarantee the compression of arbitrary data, /all/ data could be reduced
>> to a single bit.
>
> fir wasn't talking about a single bit, but a further reduction of one
> magnitude in compression rates.

I was not replying to fir's article, which I have not read (his articles 
are filtered out by my newsreader), but to Malcolm's.

> Several magnitudes have already been achieved with things such as video.

That's why it's rather unlikely that another order of magnitude will be 
achieved. A vast amount of work has been put into data compression, and 
huge lumps have been knocked off the data (quite recently, too), but 
we're running out of huge lumps. We've almost hit the asymptote, and any 
gains we see in future are likely to be small improvements.

> Plus hard drive capacities have increased too...

That has nothing whatsoever to do with data compression.

> And, if you consider video generated via computer animation, possibly
> that /could/ be reduced to a series of formulae  so that it could
> effectively be compressed by at least a magnitude compared with video
> captured from real life.

You're too late - reducing the data to a series of formulae is already 
one of the ways in which /real life/ video is compressed. See, for 
example, HEVC.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#89389

On Friday, June 17, 2016 at 11:03:30 AM UTC+1, Richard Heathfield wrote:
> 
> > Several magnitudes have already been achieved with things such as video.
> 
> That's why it's rather unlikely that another order of magnitude will be 
> achieved. A vast amount of work has been put into data compression, and 
> huge lumps have been knocked off the data (quite recently, too), but 
> we're running out of huge lumps. We've almost hit the asymptote, and any 
> gains we see in future are likely to be small improvements.
> 
No, because one video image predicts the following image in myriads of ways
not captured by MPEG. MPEG exploits spatial auto-correlation and the very
short term correlation between up to about five consecutive frames. But
few real video sequences consist of unrelated clips of a few frames.
Also, MPEG will compress almost any natural camera shot equally well, but 
videos made by humans are largely restricted to a subset of scenes, usually
one which show people.

There is a lot of potential redundancy there, but we don't have the techniques 
to exploit it at present.

[toc] | [prev] | [next] | [standalone]

#89508

W dniu piątek, 17 czerwca 2016 12:51:52 UTC+2 użytkownik Malcolm McLean napisał:
> On Friday, June 17, 2016 at 11:03:30 AM UTC+1, Richard Heathfield wrote:
> > 
> > > Several magnitudes have already been achieved with things such as video.
> > 
> > That's why it's rather unlikely that another order of magnitude will be 
> > achieved. A vast amount of work has been put into data compression, and 
> > huge lumps have been knocked off the data (quite recently, too), but 
> > we're running out of huge lumps. We've almost hit the asymptote, and any 
> > gains we see in future are likely to be small improvements.
> > 
> No, because one video image predicts the following image in myriads of ways
> not captured by MPEG. MPEG exploits spatial auto-correlation and the very
> short term correlation between up to about five consecutive frames. But
> few real video sequences consist of unrelated clips of a few frames.
> Also, MPEG will compress almost any natural camera shot equally well, but 
> videos made by humans are largely restricted to a subset of scenes, usually
> one which show people.
> 
> There is a lot of potential redundancy there, but we don't have the techniques 
> to exploit it at present.

im not sure if mpeg or other video compression, compresses in 3d i mean not only separate images or immediate differences between two frames but 'more'
in 3d - probably yes though - but i got no time to read into it -  discussion on it though could be imaginable

[toc] | [prev] | [next] | [standalone]

#89510

W dniu sobota, 18 czerwca 2016 11:16:33 UTC+2 użytkownik fir napisał:
> W dniu piątek, 17 czerwca 2016 12:51:52 UTC+2 użytkownik Malcolm McLean napisał:
> > On Friday, June 17, 2016 at 11:03:30 AM UTC+1, Richard Heathfield wrote:
> > > 
> > > > Several magnitudes have already been achieved with things such as video.
> > > 
> > > That's why it's rather unlikely that another order of magnitude will be 
> > > achieved. A vast amount of work has been put into data compression, and 
> > > huge lumps have been knocked off the data (quite recently, too), but 
> > > we're running out of huge lumps. We've almost hit the asymptote, and any 
> > > gains we see in future are likely to be small improvements.
> > > 
> > No, because one video image predicts the following image in myriads of ways
> > not captured by MPEG. MPEG exploits spatial auto-correlation and the very
> > short term correlation between up to about five consecutive frames. But
> > few real video sequences consist of unrelated clips of a few frames.
> > Also, MPEG will compress almost any natural camera shot equally well, but 
> > videos made by humans are largely restricted to a subset of scenes, usually
> > one which show people.
> > 
> > There is a lot of potential redundancy there, but we don't have the techniques 
> > to exploit it at present.
> 
> im not sure if mpeg or other video compression, compresses in 3d i mean not only separate images or immediate differences between two frames but 'more'
> in 3d - probably yes though - but i got no time to read into it -  discussion on it though could be imaginable

i recently think if compressed data shouldnt be meybe considered as a programs (to execute/interpret) whose effect of execution would be created uncompressed file - i think it could maybe bring more area of 'stunt' 
becouse you could craft algorithms on each
case separately - not uniform hardcoded set

- and it is known that some even complex images you could present in a form of simple code

[toc] | [prev] | [next] | [standalone]

#89411

"Richard Heathfield" wrote:

<rjh@cpax.org.uk> wrote:
>> And, if you consider video generated via computer animation, possibly
>> that /could/ be reduced to a series of formulae  so that it could
>> effectively be compressed by at least a magnitude compared with video
>> captured from real life.
>
> You're too late - reducing the data to a series of formulae is already one 
> of the ways in which /real life/ video is compressed. See, for example, 
> HEVC.

I don't know what the state of the art is WRT movies.  But an area that 
interests me is something I would call "de-panning'.  Many dramatic movies 
show moving actors against a basically static background. But the camera is 
constantly panning at a very slow rate. With high resolution, the edge bits 
are changing rapidly with very little value added to the image.  Two 
solutions come to mind:

· Perhaps the edges could be "fuzzed" to a lower resolution
· The edges could be updated at a lower rate, say five times a second 
instead of 24 times a second.

Are either of those (or other) techniques currently used?

I think the people sho wrote the colorizing programs of a few years ago 
could make a big contribution here, I suspect they were able to distinguish 
between active and passive area in the image. 

[toc] | [prev] | [next] | [standalone]

#89516

W dniu piątek, 17 czerwca 2016 11:44:45 UTC+2 użytkownik Bart napisał:
> On 17/06/2016 10:34, Richard Heathfield wrote:
> > On 17/06/16 10:03, Malcolm McLean wrote:
> 
> >> I remember as a child talking about how much TV you could fit on a
> >> computer
> >> hard drive. I think we came up with a  figure of 4 seconds.
> >
> > It hardly matters, and you're missing the point. If there were a way to
> > guarantee the compression of arbitrary data, /all/ data could be reduced
> > to a single bit.
> 
> fir wasn't talking about a single bit, but a further reduction of one 
> magnitude in compression rates.
> 

ye in short i meant somethink like '10 times better than zip'

this is nor a 'plan' or something (as being very ambitious) but im interested it this is 'defacto' possible or if is not (also note how practically usable it would be)



> Several magnitudes have already been achieved with things such as video. 
> Plus hard drive capacities have increased too...
> 
> And, if you consider video generated via computer animation, possibly 
> that /could/ be reduced to a series of formulae so that it could 
> effectively be compressed by at least a magnitude compared with video 
> captured from real life.
> 
> -- 
> Bartc

[toc] | [prev] | [next] | [standalone]

#89436

Richard Heathfield <rjh@cpax.org.uk> writes:

> It hardly matters, and you're missing the point. If there were a way
> to guarantee the compression of arbitrary data, /all/ data could be
> reduced to a single bit.
>
> Good luck decompressing that.

Oh its easy.  We invent a compression scheme that treats a data
containing n bits file as an n-bit number, N.  

Our algorithm is : Odd N compress to N-1. 
                   Even N compress to N/2.

We compress our file an arbitrary number of times until all that's left
is a single zero bit.  Then we send that single zero bit - near perfect
compression!

(All we need to tell the decompressor how many times we need to
 decompress the data, but thats trivial.)

[toc] | [prev] | [next] | [standalone]

#89287

On Thursday, June 16, 2016 at 4:15:42 PM UTC+1, fir wrote:
>
> I dont think "The only way" is proven - this is probably just false and I wouldnt be maybe
>  surprised if there is a way to compres .mpg's 10 times yet
> (but i dont know the details on compression never worked in it) If someonne knows maybe 
> what is a source of this impossibility (of compressing .mpgs or .iso 10 times) it would be good 
> to discuss it maybe
>
To compress, you have to be able to identify some redundancy. Some way of predicting
what the next byte will be from the previous bytes.  English text has plenty of such
redundancy, and so have movies - if an image shows grass, the next pixel is also highly
likely to be green, and the same place in the next frame is also highly likely to also
be grass. But MPEG identifies all that redundancy, and strips it out until quality is only
just noticeably affected.
Your options are a) identify some redundancy which everyone else has failed to spot,
b) reduce quality, or c) uses some sort of look-up system.

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web