HDTenEightyP/NetNews huggingface dataset:
From: brown@vidiot.UUCP (Vidiot)
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
Subject: Re: "Artifacts" in corners of cable TV pictures
Date: 30 Jul 92 03:55:38 GMT
Reply-To: brown@vidiot.UUCP (Vidiot)
Organization: Vidiot's Hangout

In article <Bs2u6x.6v2@world.std.com> dpbsmith@world.std.com (Daniel P. B. Smith) writes:
<Most cable channels seem to have a little logo in one of the corners,
<usually the lower right but, in the case of the Olympic triplecast,
<the upper right. In most cases the logo is ALWAYS there.  
<
<I don't know who puts it there or why. I assume it's the actual
<cable signal provider, probably both as a way of discouraging
<illegal recordings and also as a handy aid for the clueless cable
<watcher who can't remember fifty channel numbers, such as yours
<truly.

The logo is put there by NBC.  During replay you will see the words

	OLYMPIC
	ENCORE

in the upper left corner.

As I have mentioned in a previous posting, I have been watching the triple-
cast channels on my cable system and I don't pay.  I used what existing
video equipment that I have to provide a viewable B&W image.

Last night one of the TC channels was on the 5" monitor, but I didn't
really watch it.  Tonight I didn't even bother to fire up the equipment to
have it on at all.

As another poster pointed out, the main stuff occurs while we are at work.
By the time you get the see the final results on one of the TC channels,
you've already seen the results on the NBC broadcast channel.  Since I can
see the results I want to see on the NBC broadcast, I'm not even going to
bother to watch the TC channels.  I'm glad that I didn't pay for any of it.

Too bad the main stuff doesn't occur during prime-time.  It won't get any
better when the Olympics come to the states.
-- 
      harvard\     att!nicmad\          spool.cs.wisc.edu!astroatc!vidiot!brown
Vidiot  ucbvax!uwvax..........!astroatc!vidiot!brown
      rutgers/            INTERNET:vidiot!brown%astroatc.UUCP@spool.cs.wisc.edu
                                   brown@wi.extrel.com
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
From: dpbsmith@world.std.com (Daniel P. B. Smith)
Subject: "Artifacts" in corners of cable TV pictures
Organization: The World Public Access UNIX, Brookline, MA
Date: Tue, 28 Jul 1992 02:13:45 GMT

Most cable channels seem to have a little logo in one of the corners,
usually the lower right but, in the case of the Olympic triplecast,
the upper right. In most cases the logo is ALWAYS there.  

I don't know who puts it there or why. I assume it's the actual
cable signal provider, probably both as a way of discouraging
illegal recordings and also as a handy aid for the clueless cable
watcher who can't remember fifty channel numbers, such as yours
truly.

The thing is, while it's an aid to channel identification, it is
also quite annoying.  After a few minutes I want to go up to the
screen with a damp rag and wipe the thing off, or peel it off,
or something.

I mention this because it seems to me to be FAR more intrusive
than the worst scan-conversion artifacts, and I wonder if I'm
the only person who is irritated by it.  What I mean to say is,
if the typical cable viewer doesn't mind a splot of colorful
dirt obscuring a chunk of the picture, it doesn't seem to me
as if people are going to get up in arms about compression
artifacts... or herringbones caused by nonlinear amplifiers...
or a wee bit o' ghosting... or a smidgen of snow.

And if that's true, I don't think I'll put my retirement funds
in HDTV stock!

--Daniel P. B. Smith
dpbsmith@world.std.com
From: tim.meade%theweb@meaddata.com (Tim Meade) 
Newsgroups: comp.compression
Subject: ANNOUNCING GIFBLAST 1.1 -
Date: 28 Jul 92 11:33:00 GMT
Distribution: world
Organization: The Web BBS 1-513-436-9011 6 Lines 1200 News groups 50,000 files!
Reply-To: tim.meade%theweb@meaddata.com (Tim Meade) 

to:dimitrov@lab.ultra.nyu.edu


        Could you please email the code to gifblast 1.1 to me?  Thanks.

                                        ..Tim
From: anlyyao@igc.org (An-Ly Yao)
Newsgroups: comp.compression
Subject: Re: 16-1 compression
Date: 29 Jul 92 13:07:00 GMT
Nf-ID: #R:1992Jul28.165529.18628@lugb.latr:2045838795:cdp:1345600007:000:86
Nf-From: cdp.UUCP!anlyyao    Jul 29 06:07:00 1992





                       Here we go again !


Goetz
Seoul 1992/07/29
anlyyao@igc.org
Newsgroups: comp.compression
From: 0004575791@mcimail.com (Heather Burris)
Subject: compression programs
Organization: Mail to News Gateway at Wang Labs
Date: Wed, 29 Jul 92 22:26 GMT

I am doing a survey to learn about compression programs currently available
and their comparative results. The results of this survey will be used to
determine programs we can use to exchange data files most cost-effectively
over networks that charge per character. 

I just heard about this group--perhaps you have a FAQ that deals with these
questions? 

Do you know of recent magazine articles dealing with this subject?

Also, If you are familiar with a particular product I would appreciate very 
much some of the following information:

        Name of product
        Geared to general compression or specially geared to a certain type
                of file?
        What platforms does the product support?
        How can I get the product (contact info for developers, etc...)?
        Is the product commercial, freeware, shareware...?
        Is source available?
        What kind of compression results have you experienced with the
                product (i.e. % compression for "typical" text file, word
                processing file, spreadsheet, database, executable... -- for
                some value of "typical")?
        What type of compression algorithm is used? Is the algorithm patented?

Please email your response because I do not have direct access to the
internet. I will develop a summary of all responses and have it posted. 

Thank you very much,

Heather Burris
Burris, a computer services companyo
Newsgroups: comp.compression
From: rjwalsh@maths.tcd.ie (Robert Walsh)
Subject: JBIG algorithm
Summary: Where can I get this algorithm?
Keywords: jbig
Organisation: Amalgamated Durables
Organization: Dept. of Maths, Trinity College, Dublin, Ireland.
Date: Wed, 29 Jul 1992 12:22:13 GMT

Does anyone know where I can get the JBIG compression algorithm?
-- 
rjwalsh@maths.tcd.ie    \ Information Technology Dept., Room 24, Annex 5,
Robert Walsh              \ RTE, Donnybrook,
Advanced Developement Group \  Dublin 4, Ireland.
Trinity College, Dublin.      \ Ph: +353-1-643073   FAX: +353-1-643080
From: abirenbo@rigel.cel.scg.hac.com (Aaron Birenboim)
Newsgroups: comp.compression
Subject: Re: entropy
Date: 24 Jul 92 18:49:11 GMT
Organization: Hughes Aircraft Colorado Engineering Labs

In article <1992Jul22.144104.27576@usenet.ins.cwru.edu> daf10@po.CWRU.Edu (David A. Ferrance) writes:
>
>Right now I compute the entropy of a file by summing the probability of
>each character ocurring times the log (base2) of the reciprocal of that
>probability.  This gives me the theoretical minimum number of bits
>needed to represent each character, on average (from what I understand).
>What I would like to know is, does this number only work for first order
>(1-ary?) compression techniques

2 points for david.  good intuition.  I only stumbled through my
info-theory class, but this would seem to be the case to me.
As soon as you start using some kind of memory, or markov chain,
or dictionary the rules of the game change.

>  If it does not serve for the more complex
>techniques (and I suspect it doesn't), is there any way to determine
>entropies for different orders?

i dunno.  i'd like to hear some discussion on that though.  I'd immagine
that there are papers out covering this.  anybody care to enlighten us?

My guess as to how this works is as follows:

Lets talk about entropy as bits/SYMBOL.  If your symbols are
all characters, you have the usual case.  However, if, for
example, you go to a DICTIONARY technique, you start getting
SYMBOLS which are STRINGS of CHARACTERS.  Now...  the usual
(first order ?!?) entropy law still holds.  You can compute
a theoretical minimum number fo bits per SYMBOL, but your
symbol table is much more complex than before.  This is why
most good compression techniques can beat single-character entropy.

  Now...  i'd like to see some kind of markov chain applied
to strings of SYMBOLS...  will this be somehow analagous to
say encodeing the error from a predictor of order x.
(like in a DPCM with prediction based of the last X symbols)
This idea fits well to signals, but not so well to language
where DPCM makes less sense... (but is conceivable).

  Will the info theory gurus please stand up ! ;-)
--
Aaron Birenboim                                |I am just too tired to think
abirenbo%rigel.cel.scg.hac.com@hac2arpa.hac.com|of a good quote.
abirenbo@isis.cs.du.edu                        |    - ChickenHead
w (303) 344-6486                               |
Xref: sparky comp.compression:2841 rec.video:9673 rec.video.satellite:3823 rec.video.production:1166
From: brown@vidiot.UUCP (Vidiot)
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
Subject: Re: Compression artifacts in NBC Olympic coverage
Date: 28 Jul 92 03:38:16 GMT
Reply-To: brown@vidiot.UUCP (Vidiot)
Organization: Vidiot's Hangout

In article <1992Jul27.015954.15753@eng.umd.edu> hsu@eng.umd.edu (Dagwood splits the Atom) writes:
<
<But is it really compression?  It looks to me more like they're using
<some ridiculously high shutter speeds to kill the motion blur for their
<slow-mo replays, which have been unusually solid.

No, they (NBC and the host country's RTU) are using special slow motion
equipment for basketball, swimming, diving, track & field and gymnastics.
One system is made by Sony (used at the winter Olympics) and a new one by
Panasonic.  Panasonic is using an AQ-1000E camera, which operates at three
times normal speed, and a modified AU-1000 M-II VTR to record the video.
The camera uses digital signal processing and the tape can be played in any
M-II VTR.  NBC will have two of these systems, which will be moved to
various venues.

The Sony system uses the BVP-9000 CCD camera and the BVW-9000 Betacam SP
VTR.  Again, three times normal frame rate is used.

Hope this helps.
-- 
      harvard\     att!nicmad\          spool.cs.wisc.edu!astroatc!vidiot!brown
Vidiot  ucbvax!uwvax..........!astroatc!vidiot!brown
      rutgers/            INTERNET:vidiot!brown%astroatc.UUCP@spool.cs.wisc.edu
                                   brown@wi.extrel.com
Newsgroups: comp.compression
From: daf10@po.CWRU.Edu (David A. Ferrance)
Subject: more entropy
Reply-To: daf10@po.CWRU.Edu (David A. Ferrance)
Organization: Case Western Reserve University, Cleveland, OH (USA)
Date: Thu, 23 Jul 92 17:47:40 GMT


If I have an unsigned int count[256][256], what is wrong with
calculating entropy like this:

for (i=0;i<256;i++) for (j=0;j<256;j++)  {
    freq = count[i][j] / total;
    ent += freq * log10(1/freq) / 0.30103;
    }
Where total and ent are doubles, total is the # of bytes total, ent
starts off as 0, and the values of the array are the # of occurances of
each 2 letter combination?

I get values > 8.

			Any help appreciated,
			  Dave
-- 
David Ferrance       Sigma Nu Delta Alpha 1061     daf10@po.cwru.edu

         And on the seventh day, He exited from append mode.
Newsgroups: comp.compression
From: graef@rs5.hrz.th-darmstadt.de (Ulrich Graef)
Subject: Re: Using Permutations for Data Encoding
Date: Wed, 29 Jul 1992 18:05:50 GMT
Organization: TU Darmstadt

In article <1992Jul27.201658.6088@coe.montana.edu>, fortran@giac1.oscs.montana.edu (Lou Glassy) writes:
> When reading the recent spate of articles on impossible compression
> methods, I began to think about an alternative mousetrap (maybe better,
> maybe not) for data encoding.
> 
> Here is my idea:
> 
> Suppose your input stream is a sequence of symbols.  Let the symbols be
> taken from an alphabet of N symbols, with B bits being required to
> encode each symbol.  
> 
> "Rubix Coding"
> 
> To encode:
> 
> [Here's where I shake the beads-and-rattles :) ]

I too!
 
> [2]   Store the permutation of the input stream wrt the sorted stream.

A permutation can be expressed by a number of transpositions (a exchange)
of 2 symbols in the sequence.

You must find a minimum transposition, which is easy with your scheme.

But you need 2 numbers for every transposition. And with a transposition
you get mostly 1 sometimes 2 symbols in the right place. This would be
an expansion and no compression! 
 
You can use a clever code (I try arithmetic coding) and the size of your
code becomes nearly the size of the source.

Uli


-- 
Ulrich Graef        |  analog (phone) :  +49 6155 62493           
Lichtenbergweg 11   |  digital (Email): graef@hrz.th-darmstadt.de 
D-W-6103 Griesheim  +--------------------------------------------
Germany             |  Nothing is real, look into your mirror!
From: darweesh@acsu.buffalo.edu (michael j darweesh)
Newsgroups: comp.compression
Subject: Re: PERPETUAL MOTION
Date: 21 Jul 92 19:55:36 GMT
Organization: UB

In article <7486@public.BTR.COM> rem@public.BTR.COM (Robert E. Maas  rem@btr.com) writes:
>...
>violating the premise in some way. The garbage about subtract-one is an
>example of such a non-counterexample. If you have what you think is a
>different method which might be a counterexample, you're mistaken, in
>my expert opinion.

Mr Maas, 
please do not complain about the "subtract-one" algorithm.
It was posted as a joke. The original post as well as my follow-up were
posted with humorous intent and were marked accordingly. Pick on
somebody else or send me e-mail about my posts. Don't waste everyone's
time. We already know these claims are impossible.

For everyone else,
I'm sorry that we have to waste your time with these posts. Mr. Maas
has been trying to convince me that my humorsly intended posts are
impossible claims of compression through personal e-mail. 
I have repeatedly tried to show him that they were humorous.
It seems that his "expert opinion" can't even regonize humor even after
I told him outright that my post was a joke. I encourage you to
ignore him and force him to use personal e-mail (with me) to continue
his tirade.

-Mike
Newsgroups: comp.compression
From: kym@bingsuns.cc.binghamton.edu (R. Kym Horsell)
Subject: Re: more entropy
Organization: State University of New York at Binghamton
Date: Fri, 24 Jul 1992 19:57:33 GMT

In article <1992Jul24.003709.21603@s1.gov> lip@s1.gov (Loren I. Petrich) writes:
>In article <1992Jul23.174740.14559@usenet.ins.cwru.edu> daf10@po.CWRU.Edu (David A. Ferrance) writes:
>
>>If I have an unsigned int count[256][256], what is wrong with
>>calculating entropy like this:
>
>>for (i=0;i<256;i++) for (j=0;j<256;j++)  {
>>    freq = count[i][j] / total;
>>    ent += freq * log10(1/freq) / 0.30103;
>>    }
>	Yes, some versions of C do have a "log2" function (logarithm
>to base two).

But the choice of log10 is somewhat ``unusual'' given M_LN2 is
typically in math.h.

-kym
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
From: ojala@funet.fi (Petri Ojala)
Subject: Re: Compression artifacts in NBC Olympic coverage
Organization: Finnish University and Research Network (FUNET)
	<OJALA.92Jul30143437@dolphin.hut.fi>
	<1992Jul30.215948.4245@msc.cornell.edu>
Date: 31 Jul 92 13:07:48


> Which HDTV standard is this- Japanese version? I would imagine that is
> designed to augment an NTSC signal, so how does it relate to PAL? While I
> can see HDTV 
> worlwide as having the same aspect ratio and number of lines, is there a
> worldwide standard for frame rate? And will the only difference in US
> digital HDTV be in the brodcast mechanism, not in the actual frames.

(Has there been any HDTV broadcasts from Barcelona to Japan or US ?)

I have a very short paper about the Barcelona HDTV setup (in Finland) and
if I understand it correctly, the transmission from Barcelona is
European HDTV, HD-MAC.  These transmissions are done by European
Vision 1250 production project and the transmissions are sent as
European-wide satellite transmission.

Accordingly to this paper there is 1250 lines, 50 frames/sec and the
broadcasting technology is HD-MAC in the European HDTV while in the
Japan they have 1125 lines, 60 frames/sec and MUSE broadcasting.

Petri
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
From: dlb@dazixco.ingr.com (Dave Buehmann)
Subject: Re: Compression artifacts in NBC Olympic coverage
Reply-To: dlb@dazixco.ingr.com
Organization: Dazix-Intergraph
Date: Mon, 27 Jul 1992 18:39:23 GMT

And now for the technically unenlightened gymnastics observation:

How did she do that!!!!!

I didn't think a body could move like that!  10! 10!  :) :) :)

-- 

Dave Buehmann               Voice:    (303) 581-2318
Dazix - Intergraph          Fax:      (303) 581-9972
5101 Spine Road             Internet: dlb@dazixco.ingr.com
Boulder, CO  80301          UUCP:     ...uunet!ingr!dazixco!dlb

Newsgroups: comp.compression
From: pdh@netcom.com (Phil Howard )
Subject: Here we go again (NOT!)
Date: Thu, 30 Jul 92 19:01:00 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Followups-To: poster

It seems the subject won't die.  Even I am guilty of following up on it
when it shows up again.  Sorry.

You know what the subject is, so I won't mention it.  If you don't know,
then please read the group for the next 60 days before posting anything
but substantiated facts.  Better yet, read the FAQ.  Unfortunately, the
explanation of how to find the FAQ if it is not currently among your
set of articles in this group would be a long and complex set of instructions
if it is to be precise.  If you have FTP access, you can connect to host
"rtfm.mit.edu", cd to directory "pub/usenet/comp.compression" and grab
the funny named files there.

The heads are knocking on this between the theory that it is impossible
vs. the rumored claims that it has been done.  According to the FAQ, it
is not yet possible to apply an appropriate evaluation of the product.
The FAQ tells all that is now known so it should be read first.

I hope someone will keep being aggressive with the source of information
and post a summary when real facts change.  Until then, nothing is new
and idle questioners should be directed to the FAQ.
-- 
/***********************************************************************\
| Phil Howard  ---  KA9WGN  ---  pdh@netcom.com   |   "The problem with |
| depending on government is that you cannot depend on it" - Tony Brown |
\***********************************************************************/
From: pdh@netcom.com (Phil Howard )
Newsgroups: comp.compression
Subject: Re: 16-1 compression
Date: 29 Jul 92 20:00:57 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

lip@s1.gov (Loren I. Petrich) writes:

>	It is easy to show that _lossless_ compression (where one can
>recover the original file without corruption) of any possible file is
>an impossibility. This comes from counting the number of possible
>files of a given length and pointing out that the number of compressed
>files is less than the number of original files. Thus, there will be
>at least one compressed file which will map onto more than one of the
>original files.

On the other hand it is possible to make sure that no "bad case" files
will get larger by more than 1 bit, but this also adds 1 bit to all the
other files, too.
-- 
/***********************************************************************\
| Phil Howard  ---  KA9WGN  ---  pdh@netcom.com   |   "The problem with |
| depending on government is that you cannot depend on it" - Tony Brown |
\***********************************************************************/
Newsgroups: comp.compression
From: garys@pictel.com (Gary Sullivan)
Subject: Re: more entropy
Organization: PictureTel Corporation
Date: Fri, 24 Jul 1992 22:56:03 GMT

In article <1992Jul23.174740.14559@usenet.ins.cwru.edu> daf10@po.CWRU.Edu (David A. Ferrance) writes:
>
>If I have an unsigned int count[256][256], what is wrong with
>calculating entropy like this:
>
>for (i=0;i<256;i++) for (j=0;j<256;j++)  {
>    freq = count[i][j] / total;
>    ent += freq * log10(1/freq) / 0.30103;
>    }
>Where total and ent are doubles, total is the # of bytes total, ent
>starts off as 0, and the values of the array are the # of occurances of
>each 2 letter combination?
>
>I get values > 8.

"total" shouldn't be the total number of "bytes", it should be the total
of the counts.  I assume that's what you meant.
The only other thing I can see that is wrong is that it's inefficient.
I'd do:

for(i=0, tmp=0.0; i<256; i++)
  for(j=0; j<256; j++) {
    freq = (double)count[i][j];
    tmp += freq * log10(freq);
  }
entropy = (log10((double)total) - tmp / total) / 0.30103;

As someone else replied, you'd need to worry if this came out above 16,
but 8 or so is OK.

---------------------------------
Gary Sullivan  (garys@pictel.com)
Newsgroups: comp.compression,news.software.b
From: dhd@exnet.co.uk (Damon)
Subject: COLLATED ANSWERS---Preloading `compress' for better NEWS batching.
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Wed, 22 Jul 1992 21:36:53 GMT

I asked about an idea for tuning compress for news batches...  Here is my
original question and a selection of the answers received.  Thanks to all those
who replied.

Take the trouble to read this and maybe followup on (bit of!) it; there's a lot
of good info here.  I may start a second summary.

I may well have missed posted rather than e-mailed replies.  Sorry if any of
you tried to mail and it bounced.

Replies quoted are from:
    Nigel Metheringham <nigelm@ohm.york.ac.uk>
    Alfred Kayser <Alfred.Kayser@dnpap.et.tudelft.nl>
    Matthew Farwell <dylan@ibmpcug.co.uk>
    Don Taylor <dont@klic.rain.com>
    Rob Stampfli <res@colnet.cmhnet.org>

Thanks again...

Damon

-------------------------------------------------------------------------------
Newsgroups: comp.compression,news.software.b
From: dhd@exnet.co.uk (Damon)
Subject: Preloading compress for news...
Keywords: compress, LZ, preloading, news, batch, n-graphs
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Tue, 14 Jul 1992 19:37:03 GMT

I'm sure this one has been discussed before... but I can't remember...

Suppose, for a particular application (in this case batch compression
for news) we record the frequency of occurrence of the most common 2,
3,
... 6 character sequences in real batches.

(I have the tools to do this; I may even do something about it this
evening...)

Then pick the 255 sequences that if shrunk to 9 bits would save the
most space (ie bits saved * freq of occurrence).  Preload these into a
version of compress (and also uncompress, being the same program).  If
we want we could then do the same with the next most `useful' sequences
for the 10-bit codes.

Call this something new like `newscomp' and supply it with (say) new C
News software for participating pairs of sites to use to
compress/uncompress batches.

The idea is that this `tuned' compress/uncompress may be much more
effective than a normal compress, and although incompatible with the
normal compress because of this preloaded info, it might save
significant bandwidth between cooperating pairs of sites, starting
better than compress by itself, but still adapting well for different
traffic.

If you e-mail I'll gather responses together and post as one article.
I don't promise to catch all articles in the news spool, since my
machine is about to overflow!

If someone knows how to modify compress with this preloaded info, I'll
collect character frequencies in real batches for initially a day or
two and then for a few months, or supply them with the automatic tools
to do so.  This could be a very worthwhile saving in
net.telecomms.costs.

Damon


===============================================================================
RESPONSES
-------------------------------------------------------------------------------
Newsgroups: comp.compression,news.software.b