HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
X-Newsreader: Tin 1.1 PL4


It's interesting to hear that US viewers are seeing this 'artifact' 
problem.

Here in Australia, 80% of "live" US coverage displays these artifacts.
To my uneducated eye, it's always appeared as if I was watching a digital
picture that 'stuttered'.

Interestingly enough, as Graham Gill (sp?) pointed out, the PAL/NTSC
signal issue could be the root cause, because I'm not seeing any artifacts
on my monitor down here.  A very pleasant change.

Oh, BTW - during an interview with a local interviewer and a spanish
technician in charge of the broadcasts, he said that they were using ultra
modern techiniques, including recording the entire Olympics in HDTV.

Although his english was spanish-accented, thw 'word' HDTV was clear.
I can only guess that this will be stored off for some day in the future
when it becomes a standard and we can look back and watch it over again.

And speaking of HDTV, rec.video often has great discussions about when
HDTV will arrive in the average home in America.  The general date area
seems to be around 2000 or 2005.  I would think that by then, the whole
issue will be moot because technology will have leapfrogged again, and 
we'll have some new technology that even Bob Niland himself hasn't 
thought of. (no offence, bob).

douginoz
doug@hparc0.aus.hp.com
From: patyhh@nuscc.nus.sg (Yeow Heng Ho Peter (Mr))
Newsgroups: comp.compression
Subject: LOSSLESS Compression
Date: 27 Jul 92 03:43:27 GMT
Organization: National University of Singapore

I have completed building a DSP board for the processing of images.

For this, I have been trying to implement a Lossless Image compression.

I would like to know 

1)	What are the best methods (real time)
2)	What are the typical compression ratios acheived.

Thanks.
Xref: sparky comp.compression:2886 alt.binaries.pictures.d:3889 alt.graphics.pixutils:1849
From: dimitrov@lab.ultra.nyu.edu (Isaac Dimitrovsky)
Newsgroups: comp.compression,alt.binaries.pictures.d,alt.graphics.pixutils
Subject: about GIFBLAST 1.1 source code
Summary: will post soon
Keywords: GIF,compressor,lossless
Date: 31 Jul 92 05:25:29 GMT
Organization: New York University Ultracomputer Research Lab

[]
There has been enough interest, so I will post generic C code for GIFBLAST
in a week or so. I first have to change some PC-dependent parts, and then
I will test it on a SPARC before posting. I will post the C code to
alt.sources and alt.binaries.pictures.

Isaac Dimitrovsky (dimitrov@lab.ultra.nyu.edu)
"Sincerity is *the* most important thing in show business -
  so once you learn to fake that you've got it made."
- Joe Franklin
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)
	<3710@vidiot.UUCP>
Date: 30 Jul 92 14:34:37


> While HDTV will be at the Olympics, none of the cameras are on-line for the
> world feed.  All of that is PAL (4:3).  The HDTV stuff will be used later to
> show off the quality of HDTV.
>
> Though, there may be some sites where HDTV can be seen live.  It was done for
> the winter Olympics.  But, none of it (as far as I know) is being broadcast.

I believe that they are actually broadcasting the HDTV stuff over satellite
to several locations, at least inside Europe.

Both Telecom Finland and YLE (State TV & Radio Broadcasting company) 
are receiving the HDTV transmission from satellite at several locations
and the HDTV stuff is transferred over PTT's fiber optic networks
to other places.  You can go and see HDTV alive at several locations,
including the couple of TV station auditoriums in Helsinki and Tampere,
apartment exhibition in M{nts{l{ and shopping centre (Forum) in the centre
of Helsinki.

I walked yesterday through the Forum shopping centre and there were
Nokia and Philips HDTV television sets showing swimming from Barcelona.
When there is no transmission from Barcelona they are showing some
other HDTV material from optical discs (at least in Helsinki where the
transmission is over fiber networks).  The picture was quite nice ;-)

I'd assume that there are similar setups in other countries.

Petri
Xref: sparky comp.compression:2840 rec.video:9672 rec.video.satellite:3822 rec.video.production:1165
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:10:06 GMT
Reply-To: brown@vidiot.UUCP (Vidiot)
Organization: Vidiot's Hangout

In article <62860@cup.portal.com> Power@cup.portal.com (Ron A Uitz) writes:
<Digital "jerkiness" is apparent to me in all of NBC's coverage.  I guess
<they figure most people don't notice or don't care.  

Don't forget the stuff is shot in PAL and standards converted.

Here is the information regarding equipment used in Spain....

All of it is PAL...ALL OF IT.  NBC has purchased lots of equipment that will
be moved back to NBC in the states.  Most can be converted with software and
the rest with some cards being exchanged.

Transponder time was purchased on five transponders, using two satellites.
Standards conversion is being done before uplink.  The units include four
Thomson (three purchased one leased) and four Vistek converters, borrowed from
CBS.

So, to me this means no uplink compression and all of the problems we are
seeing are a result of the new technology being used in the converters.

Oh well.
-- 
      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: chrisk@hercules.esd.sgi.com (Chris Kotsiopoulos)
Subject: Re: Compression artifacts in NBC Olympic coverage
Organization: Silicon Graphics, Inc.
Date: Mon, 27 Jul 1992 23:12:11 GMT

In article <1992Jul27.223821.5539@wam.umd.edu>, bladin@wam.umd.edu
(Ilana J. Getz) writes:
|> In article <62860@cup.portal.com> Power@cup.portal.com (Ron A Uitz)
|> writes:
|> >Digital "jerkiness" is apparent to me in all of NBC's coverage.  I
|> guess
|> >they figure most people don't notice or don't care.  
|> 
|> I think what you are referring to may the result of the use of high
|> speed
|> shutters in some of the cameras. During some of the floor
|> excercises, I 
|> noticed that as they cut between cameras, one of them was using a
|> HSS and
|> the other was not (probably a tube camera).
|> 	Personally, I do not like the look of a HSS. It gives things a
|> segmented, unnatural motion. 
|> 
|>
======================================================================
=====
|> Dave Bittner - Authorized Steadicam JR dealer - Mac User -
|> Rollerblader  ===
|>
======================================================================
=====
|> 

I agree, HSS seems unnatural.
I hope this doesn't flare up the great tubes vs. solid-state debate again!:-)

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Kotsiopoulos - Authorized Blackjack Dealer - SGI User - Landlubber +++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Xref: sparky comp.compression:2853 rec.video:9707 rec.video.satellite:3840 rec.video.production:1185
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 17:42:47 GMT
Article-I.D.: vidiot.3714
Reply-To: brown@vidiot.UUCP (Vidiot)
Organization: Vidiot's Hangout

In article <1992Jul27.183923.19029@infonode.ingr.com> dlb@dazixco.ingr.com writes:
<And now for the technically unenlightened gymnastics observation:
<
<How did she do that!!!!!

How did who do what?

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

I don't either, since I don't know who you are talking about or what she did?
-- 
      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
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.compression
Subject: Re: more entropy
Date: 24 Jul 92 22:31:02 GMT
Organization: CWI, Amsterdam

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:
 > 
 > >for (i=0;i<256;i++) for (j=0;j<256;j++)  {
 > >    freq = count[i][j] / total;
 > >    ent += freq * log10(1/freq) / 0.30103;
 > >    }
 > 
 > 	I presume that the code also included:
 > 
 > 	ent = 0;
 > 	total = 0;
 > 	for (i=0;i<256;i++) for (j=0;j<256;j++)
 > 	  total += count[i][j];
 > 
 > >I get values > 8.
 > 	The theoretical maximum value is log2(256*256) = 16.
 > 
Right.  And indeed the entropy can very well be larger than 8.  What creates
the confusion is that you calculate the entropy of pairs of characters, and
in that case an entropy of 8 means you can compress by at most 50% by encoding
pairs of characters.  What you want is single character entropy with memory
of one previous character.  I am not an expert in information theory etc.
(and indeed never have read very much about it), but my offhand suggestion
is: add an array count1 of 256 elements where you count the occurrences of
individual characters.  Next change the statement:
        freq = count[i][j] / total;
        ent += freq * log10(1/freq) / 0.30103;
to:
	freq = (double)count[i][j] / (double)count1[i];
        ent += (double)count1[i] / total * freq * log10(1/freq) / 0.30103;
(perhaps including some of the other suggestions, like using log2, -log2(freq)
etc.).  This way you calculate for each character the entropy when it is
following a specific character and you weigh that by the relative frequency
of that preceding character.

dik
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland
dik@cwi.nl
Xref: sparky comp.compression:2813 rec.video:9591 rec.video.satellite:3776 rec.video.production:1137
From: Power@cup.portal.com (Ron A Uitz)
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
Subject: Re: Compression artifacts in NBC Olympic coverage
Date: 27 Jul 92 00:20:44 GMT
Organization: The Portal System (TM)

Digital "jerkiness" is apparent to me in all of NBC's coverage.  I guess
they figure most people don't notice or don't care.  
Newsgroups: comp.compression,alt.binaries.pictures.d,alt.graphics.pixutils
From: gill@physics.ubc.ca (Arnold Gill)
Subject: Re: announcing GIFBLAST 1.1 - a GIF compressor (new & improved)
Keywords: GIF,compressor,lossless
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Thu, 30 Jul 1992 22:17:10 GMT

dimitrov@lab.ultra.nyu.edu (Isaac Dimitrovsky) writes:

>I have posted to alt.binaries.pictures version 1.1 of GIFBLAST, a program
>that I have written for the PC.

>What is GIFBLAST?
>GIFBLAST is a compressor designed especially for GIF files. The usual file

     Just tried it out -- it compressed as promised.  However, the 
     decompression does not produce the same file as the original.  It
     had a different file length, and using fc game me about 10 non-alignments
     (on a 65k GIF).  However, there doesn't seem to be a loss in the image,
     at least not from casual viewing.

     Is the decompression different than the original file?  If so, should this
     be fixed?

--
Arnold Gill --- astrophysician trainee in exile             gill@physics.ubc.ca
Xref: sparky comp.compression:2852 rec.video:9706 rec.video.satellite:3839 rec.video.production:1184
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 18:02:55 GMT
Article-I.D.: vidiot.3717
Reply-To: brown@vidiot.UUCP (Vidiot)
Organization: Vidiot's Hangout

In article <1992Jul27.201440.7121@cs.tu-berlin.de> harry@cs.tu-berlin.de (Harald Brinkmann) writes:
<Hi There!
<
<Well, I haven't seen those artifacts that you lot in the US rave
<about. Anyway here some some thoughts of mine about that:
<
<They could be standard conversion atrifacts, but I'm surprised that
<no-one has ever noticed them elsewhere. I have heard that they use at
<least for slow motion (I'm not sure about standard conversion) a new
<system with motion estimation, which is intended to make movements
<more smooth. Fast movements on existing standard converters looks
<really messy. (For those of you who can pick up PAL signals look for
<Spacenet S2 at 69 deg 3920 MHz Vertical which is supposed to be
<ECO/Galavision for Europe already PAL transcoded. Look for for moving
<letters like scrolling subtitles or credits.)

Thanks for your input.  I greatly helps my point.  The problem has been seen
previously, during the Winter Olympics, where these new standards converters
were first brought on line.  They are the same ones, since NBC loaned them
to CBS.

While these new converters really help motion, they sure introduce other
problems.

<American TV programmers often insist on using their own cameras in
<international events. They may relay the international feed and mix it
<with their own output. Often their own cameras are in NTSC, so there
<would be no stanard conversion then. Indoors with 50 Hz lighting this
<may be impractical though, but I have seen that during the Winter
<Olympics for Outside broadcasts.

In this case, there is no NTSC cameras there.  Apparently to make life easier
for NBC, all of the equipment they are using is PAL.  See previous article
regarding this.  I agree that this has been the case most of the time in the
past.
-- 
      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
Xref: sparky comp.compression:2850 rec.video:9702 rec.video.satellite:3836 rec.video.production:1181
From: jonke@kong.gsfc.nasa.gov (Stephen Jonke)
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
Subject: Re: "Artifacts" in corners of cable TV pictures
Date: 28 Jul 92 21:01:04 GMT
Distribution: usa
Organization: NASA Goddard Space Flight Center

In article <Bs2u6x.6v2@world.std.com>, dpbsmith@world.std.com (Daniel P. B. Smith) writes:
> 
> 
> And if that's true, I don't think I'll put my retirement funds
> in HDTV stock!
> 

It all depends.  It depends on whether or not large screen HDTV sets are
in the price range of current 27" NTSC TVs.  If so, then more and
more people will be able to afford big screens and they will notice the
superiority of HDTV.  However, if the average consumer has to stick with
the equivalent of a 27" NTSC set, they probably won't see
what all the hub bub is about and HDTV will fail.

Steve
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
From: tlm1@Ra.MsState.Edu (Terry Matula)
Subject: Re: Compression artifacts in NBC Olympic coverage
Organization: Mississippi State University
Date: Sun, 26 Jul 1992 22:57:47 GMT

monta@image.mit.edu (Peter Monta) writes:

>While I was watching the US-Angola basketball game and the coverage
>of the early gymnastics compulsories, I thought I saw several image
>artifacts.
>Where in the chain from Barcelona does this occur?  Is satellite
>bandwidth so scarce that NBC must resort to compressed NTSC?  How
>might NBC be convinced to stop doing this, or at least use a better
>coder?

Idle speculation here...
  Maybe it has something to do with NBC's infamous triple-cast.  I suppose
  they are sending the main broadcast feed plus three more channels from
  Spain to the US.  Maybe they are trying to lower costs by compressing all
  four channels and using less satellite bandwidth?

>Finally, if you have a tape of the afternoon coverage, take
>a look and try to confirm that I'm not off my rocker.

I haven't taped anything, but I will keep an eye out for it next time I
watch some of the coverage.

--
Terry Matula
tlm1@ra.msstate.edu
matula@ee.msstate.edu
From: dennis+@cs.cmu.edu (Dennis Grinberg)
Newsgroups: comp.compression
Subject: computation of example Huffman tables in JPEG
Date: 24 Jul 92 19:45:06 GMT
Organization: School of Computer Science, Carnegie Mellon

I am interested to know how the example set of Huffman tables
in the informational annex of the JPEG proposal were computed:

I would presume that they are based on data collected from "typical" 
(whatever that means) sample images.  Is this data available?

Thanks in advance,

Dennis
Newsgroups: comp.compression
From: rmccoy@rock.concert.net (Ron McCoy - Yale Security)
Subject: LeadView
Organization: CONCERT-CONNECT -- Public Access UNIX
Date: Fri, 31 Jul 1992 14:49:05 GMT

Does anyone have any knowledge or experience with software and
hardware from a company called: LEAD Technologies, Inc.?

They sale a product called LeadView which, along with a
proprietary card, claims to do JPEG compression in "almost real-
time". I'd be interested in anyone's opinions on the company and
its products.

Ron McCoy
Rmccoy@rock.concert.net
From: gh1h+@andrew.cmu.edu (Gary Hooyman)
Newsgroups: comp.compression
Subject: .tiff files
Date: 23 Jul 92 06:01:25 GMT
Article-I.D.: andrew.QePfipe00iQQA4SF9r
Organization: Masters student, Civil Engineering, Carnegie Mellon, Pittsburgh, PA

hello,

I'm not sure if this is the place for this question or not.  If not, I
would appreciate a pointer to a forum in which I might get the answer to
my question: 

-------

I would like to scan some images from a number of graphs and extract
from the .tiff file ordered pairs representing the data points of the
graph.

Is there a utility available that can help me do this?  If not, is there
anything that provides nearly this functionality s.t. I could modify the
code?




Thank you

Gary Hooyman
Department of Civil Engineering
Carnegie Mellon University
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
From: tlm1@Ra.MsState.Edu (Terry Matula)
Subject: Re: Compression artifacts in NBC Olympic coverage
Organization: Mississippi State University
Date: Mon, 27 Jul 1992 00:01:10 GMT

tlm1@Ra.MsState.Edu (Terry Matula) writes:
>monta@image.mit.edu (Peter Monta) writes:

>>Finally, if you have a tape of the afternoon coverage, take
>>a look and try to confirm that I'm not off my rocker.

>I haven't taped anything, but I will keep an eye out for it next time I
>watch some of the coverage.

I just watched some of the floor exercises, and yes, there is certainly
something visible around fast moving objects that may be compression 
artifacts.  So you're not completely off your rocker. :)

--
Terry Matula
tlm1@ra.msstate.edu
matula@ee.msstate.edu
Newsgroups: comp.compression
From: escreven@latenite.us.oracle.com (Edward Screven)
Subject: Re: PERPETUAL MOTION
Organization: Oracle Corporation, Redwood Shores CA
  <7486@public.BTR.COM> <62692@cup.portal.com>
Date: Fri, 24 Jul 1992 21:43:28 GMT
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.


> From: ts@cup.portal.com (Tim W Smith)
> [ algorithm to compress some files of length M without expanding others ]

no need to present an algorithm -- you can easily show by counting it is
possible to build a compressor that compresses some bit strings of exactly
length M and doesn't expand any bit string of length M since there are
2**(M+1) - 1 bit strings of length M or less, but only 2**M bit strings of
length M.

> However, I believe that it *DOES* provide a counterexample to the usual
> counting argument.

not really.  the usual (correct) counting argument shows that a compressor
cannot compress *all* bit strings of length M.

	- edward screven
--
-------------------------------------------------------------------------------
Edward Screven                Internet: escreven@us.oracle.com
Senior Technical Staff       Telephone: (415) 506-6126   Fax: (415) 506-7200
Tools and Multimedia           US Mail: 500 Oracle Parkway, Box 659411,
Oracle Corporation                      Redwood Shores, CA 94065
-------------------------------------------------------------------------------
Newsgroups: comp.compression
From: madler@cco.caltech.edu (Mark Adler)
Subject: Re: My New Compression Algorithm
Organization: California Institute of Technology, Pasadena
Date: Thu, 30 Jul 1992 19:18:55 GMT


>> - Please mail me a -200MB file of yours - now THAT would increase my disk 

While part of this file is in my CPU do I have more registers?

mark
Xref: sparky comp.compression:2859 rec.video:9729 rec.video.satellite:3851 rec.video.production:1191
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: 29 Jul 92 01:52:43 GMT
Reply-To: brown@vidiot.UUCP (Vidiot)
Organization: Vidiot's Hangout

In article <1992Jul28.011907.18506@ee.ubc.ca> wseto@ee.ubc.ca (Wilson W. Seto) writes:
<In article <MONTA.92Jul26181344@image.mit.edu>, monta@image.mit.edu (Peter Monta) writes:
<> While I was watching the US-Angola basketball game and the coverage
<> of the early gymnastics compulsories, I thought I saw several image
<> artifacts.
<...
<> Peter Monta   monta@image.mit.edu
<> MIT Advanced Television Research Program
<
<I've noticed that too.  But here in Canada we get NBC and CTV (Canadian Television Network)
<coverage of the Olympics.  The CTV signal has no artifacts whatsoever.

I'll bet that CTV is not using motion compensation either.
-- 
      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: tope@enea.se (Tommy Petersson)
Subject: Re: "Artifacts" in corners of cable TV pictures
Organization: Enea Data AB
Date: Fri, 31 Jul 1992 13:58:45 GMT

brown@vidiot.UUCP (Vidiot) writes:
- 
- Too bad the main stuff doesn't occur during prime-time.  It won't get any
- better when the Olympics come to the states.

Then it's time to start lobbying for Olympics in Japan, perhaps?

-- 
=============================================================================
 Tommy Petersson              tope@enea.se              Enea Data AB, Sweden
=============================================================================

Newsgroups: comp.compression