HDTenEightyP/NetNews huggingface dataset:
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
Subject: Re: NBC Olympic coverage - reason
Date: 28 Jul 92 20:01:15 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

elball@sunee.waterloo.edu (Eric Ladd Ball) writes:
>The reason for the artifacts is quite simple.  NBC is using digtal
>full-frame camaras.  These are sequential line instead of NTSC interlaced.

>CONs:
>1> The artifacts of fast motion everyone has seen.  This is caused because
>   the interlaced lines appear on sub-sequent fields and look very wierd.

	That doesn't seem to match the artifacts I caught on my SVHS VCR.
They looked more like MPEG-type artifacts (DCT/motion-estimation artifacts),
which I've seen before.

-- 
"Rev on the redline, you're on your own; seems like a lifetime, but soon it's
 gone..."  Foreigner
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Newsgroups: comp.compression
From: melissa@csd4.csd.uwm.edu (Melissa C Merrill)
Subject: Re: PKZIP password encryption?
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Date: Thu, 23 Jul 1992 04:46:57 GMT

In article <1992Jul23.112459.618@mof.govt.nz> gordona@mof.govt.nz writes:
>   I have a registed version of PKZIP version 1.10 but the password
>   encryption option does not seem to be present.
>   In manual.doc and in the printed manual I have it states the following :
>
>          -s<password>  Scramble files with password
>          ------------------------------------------
>
>PKZIP (R)   FAST!   Create/Update Utility   Version 1.1.  03-15-90
>Copr. 1989-1990 PKWARE Inc. All Rights Reserved.  PKZIP/h for help
>PKZIP Reg. U.S. Pat. and Tm. Off.
>
>  Any suggestions much appreciated,
>  Joel Gordon.


 Yeap, you have the EXPORT version, Previously PKWARE was limited to who they
 could export encryption to, but now that has been greatly reduced. You can tell
 that it is an export version beacause your version number is 1.1., not just 1.1
 1.1. <- note last point, signafies export version.. Get version 1.1

								Melissa

Newsgroups: comp.compression,alt.binaries.pictures.d,alt.graphics.pixutils
From: dimitrov@lab.ultra.nyu.edu (Isaac Dimitrovsky)
Subject: Re: announcing GIFBLAST 1.1 - a GIF compressor (new & improved)
Keywords: GIF,compressor,lossless
Organization: New York University Ultracomputer Research Lab
Date: Fri, 31 Jul 1992 05:17:16 GMT

[]
gill@physics.ubc.ca (Arnold Gill) writes:
>dimitrov@lab.ultra.nyu.edu (Isaac Dimitrovsky) writes:
>> GIFBLAST is a compressor designed especially for GIF files.
>
> 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?

The reason for this is that the GIF standard for image encoding is
not completely fixed, i.e. the same image can produce two slightly
different GIF files depending on how the GIF encoding is done.
So, when you compress and decompress you may get a GIF file that is
not byte for byte identical to the original, but the image should be
preserved exactly. You can verify that the image does not change at
all by converting the two files to TIFF or PBM formats and comparing.

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
From: wombat@nfinit.enet.dec.com (Christopher M. Conway)
Newsgroups: comp.compression
Subject: Re: My New Compression Algorithm
Date: 30 Jul 92 17:05:04 GMT
Reply-To: wombat@nfinit.enet.dec.com
Organization: Prickly Wombat Enterprises


In article <1992Jul17.080016.24014@id.dth.dk>, ep@id.dth.dk (Erik Plesner) writes:
- ed@titipu.meta.com (Edward Reid) writes:
- 
- >                                                   [..]  MY (tm) algorithm,
- >for example, compresses every file to -1024 bits or less, and compresses most
- [..]
- >a negative megabit can hold an enormous amount of information, while saving
- >unbelievable amounts of disk space as well.
- 
- Please mail me a -200MB file of yours - now THAT would increase my disk 
- space.  (If I need more space later on, I just copy the -200MB file ).
-   :-) .
- 
Better yet, POST it. That way every news server in the world will get an
extra 200 MB. Then everybody should repost it, multiple times. Heck, who
needs disks?

--
Boycott Kodak
--------------------------------------------------------------
Christopher M. Conway		| U*ix and C Guru
wombat@nfinit.enet.dec.com      | Legalize Freedom!
wombat@juliet.ll.mit.edu        | Marrou/Lord in '92!
nfinit::wombat (DECnet internal)| (505)761-2413 DTN 552-2413
--------------------------------------------------------------
In no way should any statement, question, or other transferral
of information in this post should be construed in any way
as being an official communication of Digital Equipment
Corporation.
Xref: sparky comp.compression:2851 rec.video:9704 rec.video.satellite:3837 rec.video.production:1182
From: brown@vidiot.UUCP (Vidiot)
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
Subject: Re: NBC Olympic coverage - reason
Date: 28 Jul 92 17:48:26 GMT
Reply-To: brown@vidiot.UUCP (Vidiot)
Organization: Vidiot's Hangout

In article <Bs2ACw.GBE@watserv1.uwaterloo.ca> elball@sunee.waterloo.edu (Eric Ladd Ball) writes:
<The reason for the artifacts is quite simple.  NBC is using digtal
<full-frame camaras.  These are sequential line instead of NTSC interlaced.

This is news to me.  The main feed is provided by RTU, the host country TV
network.  They are PAL cameras.

If they were full frame, then conversion to field PAL or NTSC would result
in two fields looking exactly the same.  Motion would only update every 30th
of a second.  I know this to be false, since I can look at each field and see
motion (using 3/4" pro gear, not VHS consumer).

Many of today's CCD pro cameras have shutter modes just like consumer cameras.
This results in nice crisp slo-mo shots.  See previous postings regarding
special slo-mo equipment that is also being used.

<PROs:
<1> Freeze-frame/super-slo-mo are artifact free.
<2> Easy capture for still-frame printing (ie magazines etc)
<3> Easy translation to different TV formats (ie PAL) in digital logic.
<   (ie throw away 1/6 of the frames for PAL, chop off lines on the top &
<   bottom for NTSC)
<
<CONs:
<1> The artifacts of fast motion everyone has seen.  This is caused because
<   the interlaced lines appear on sub-sequent fields and look very wierd.

I do not believe any of this is actually occuring.  See previous postings
regarding new technology PAL -> NTSC converters.
-- 
      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: elball@sunee.waterloo.edu (Eric Ladd Ball)
Subject: NBC Olympic coverage - reason
Organization: University of Waterloo
Date: Mon, 27 Jul 1992 19:05:20 GMT

The reason for the artifacts is quite simple.  NBC is using digtal
full-frame camaras.  These are sequential line instead of NTSC interlaced.

PROs:
1> Freeze-frame/super-slo-mo are artifact free.
2> Easy capture for still-frame printing (ie magazines etc)
3> Easy translation to different TV formats (ie PAL) in digital logic.
   (ie throw away 1/6 of the frames for PAL, chop off lines on the top &
   bottom for NTSC)

CONs:
1> The artifacts of fast motion everyone has seen.  This is caused because
   the interlaced lines appear on sub-sequent fields and look very wierd.
Newsgroups: comp.compression
From: madler@cco.caltech.edu (Mark Adler)
Subject: Re: PKZip 2.x
Organization: California Institute of Technology, Pasadena
Date: Sun, 26 Jul 1992 05:46:14 GMT


Jon W{tte asks about Info-zip's forthcoming zip:

>> Will it support Mac resource forks as file info ?
>> In a way such that the other machines can get at it/create it too ?

There is a Mac port, but I'm not sure what the status of that is.
It does handle resource forks, and they are stored as separate
files so that the resource fork can be accessed on other machines.

Mark Adler
madler@tybalt.caltech.edu
From: bho@ocf.berkeley.edu ()
Newsgroups: comp.compression
Subject: PKZip 2.x
Date: 23 Jul 1992 19:40:33 GMT
Organization: U.C. Berkeley Open Computing Facility
Distribution: world
NNTP-Posting-Host: plague-ether.berkeley.edu


I was wondering if the current ZIP file format fully machine and
platform independent; i.e., will it support extended file
attributes in OS/2, extended attributes/filenames in Unix, etc.

Along that vein, has anybody heard of any announcement for a
PKZip for OS/2?

Newsgroups: comp.compression
From: fortran@giac1.oscs.montana.edu (Lou Glassy)
Subject: Using Permutations for Data Encoding
Summary: Has this been tried?  Will it work?
Organization: Montana State University, Bozeman Montana USA
Date: Mon, 27 Jul 1992 20:16:58 GMT

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:

[1]   Read in a stream of L input symbols.  Sort the entire input
      sequence according to some lexical ordering (the natural 
      collating sequence of the alphabet would be just fine).

      Observation:  the sorted stream and the input stream
      are both elements of the same permutation group, namely,
      S(L), where L is the number of symbols in the input
      stream ('L' is for 'Length').

[Here's where I shake the beads-and-rattles :) ]

[2]   Store the permutation of the input stream wrt the sorted stream.

[3]   Run-length encode the sorted stream.  This will yield 
      a sequence of N nonnegative integers.  Let each of these
      integers be represented by a 32-bit unsigned machine word.
      (In C, a standard 'unsigned long int'.  Store this sequence
      of integers.

To decode:

[1]   Read in N 4-byte unsigned integers.  Expand this to be
      a sequence of L symbols N.  This is the sorted sequence.

[2]   Read in the permutation.  (This is magic, I don't know
      how this would be done.)

[3]   Apply the inverse of the permutation to the sorted sequence.
      This yields the original input sequence.

What motivated this whole idea, was thinking about a Rubix Cube.  How
much information is 'stored' (implicitly) in any given configuration of
a Rubix Cube?

Could some permutational coding scheme be made practical?  By
'practical', I mean, 'useful for lossless compression/decompression of
data'.  

One of the things I recall from group theory, is that the order of the
permutation set S(N) is N!.  Some formula (Stirling's Approximation? I
misremember...) gives a gage of how big S(N) is for large N.  Hence,
"storing the permutation" may eat up all the space you saved with the
RLE.  (I'm also discreetly ignoring the compute time involved!)

Lou Glassy (fortran@giac1.oscs.montana.edu)

-- 
Lou Glassy                     <> Watch the field behind the plow
Student in Earth Sciences      <> Turn to straight, dark rows..
Montana State University       <> Put another season's promise in the ground.
fortran@giac1.oscs.montana.edu <>                          --Stan Rogers
From: bho@ocf.berkeley.edu (Bing Ho)
Newsgroups: comp.compression
Subject: Re: ANNOUNCING GIFBLAST 1.1 -
Date: 30 Jul 1992 06:20:32 GMT
Organization: U. C. Berkeley Open Computing Facility
Distribution: world
NNTP-Posting-Host: monsoon.berkeley.edu

In article <1052.1021.uupcb@meaddata.com> tim.meade%theweb@meaddata.com (Tim Meade)  writes:
>to:dimitrov@lab.ultra.nyu.edu
>
>
>        Could you please email the code to gifblast 1.1 to me?  Thanks.
>

Me too!  Or, could you tell me where I could get via anonymous FTP?
Thanks in advance.

Bing Ho
bho@ocf.berkeley.edu
Organization: Penn State University
Date: Tue, 28 Jul 1992 15:26:25 EDT
From: <GNR100@psuvm.psu.edu>
Newsgroups: comp.compression
Subject: Data Storage

   Hi.  I am interseted in finding out how different formats of images are
stored and processed.  I would like to be able to start at a analog-to-digital
converter and then process and store the image.  This may be a FAQ, but I am
having trouble understanding the posted lists.  If anyone can help me out,
please Email me with any information you can.
                Thanks alot,
                   gnr100@psuvm.psu.edu

Xref: sparky comp.compression:2873 rec.video:9785 rec.video.satellite:3880 rec.video.production:1199
From: brown@vidiot.UUCP (Vidiot)
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
Subject: Re: NBC Olympic coverage - reason
Date: 30 Jul 92 04:04:17 GMT
Reply-To: brown@vidiot.UUCP (Vidiot)
Organization: Vidiot's Hangout

In article <33745@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
<elball@sunee.waterloo.edu (Eric Ladd Ball) writes:
<>The reason for the artifacts is quite simple.  NBC is using digtal
<>full-frame camaras.  These are sequential line instead of NTSC interlaced.
<
<>CONs:
<>1> The artifacts of fast motion everyone has seen.  This is caused because
<>   the interlaced lines appear on sub-sequent fields and look very wierd.
<
<	That doesn't seem to match the artifacts I caught on my SVHS VCR.
<They looked more like MPEG-type artifacts (DCT/motion-estimation artifacts),
<which I've seen before.

My money is on your guess, because of the previous postings that I have done
about the equipment that NBC is using.
-- 
      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,comp.arch,sci.electronics
From: pss1@kepler.unh.edu (Paul S Secinaro)
Subject: Need help with LSI JPEG chipset
Organization: University of New Hampshire  -  Durham, NH
Date: Thu, 23 Jul 1992 11:36:02 GMT

Hi folks.

   I'm part of a team working on a design that uses the LSI Logic
L64745 JPEG Coder.  This device takes a stream of data from the DCT
processor chip (L64735) and performs the quantization and entropy
coding steps.  It then outputs the coded data in 32-bit words.  From
that point, our design takes the coded data, divides it down to 8-bit
bytes, and performs byte-stuffing and other code insertions as
specified by the JPEG/JFIF spec.

   That's all fine, but there's just one thing I can't seem to figure
out - what byte ordering should we use when breaking up the 32-bit
code words into an 8-bit data stream?  Right now we're using
big-endian, but we aren't sure if that's right.  The documentation
isn't too helpful on this point either.  Anyone have suggestions?
Also, if anyone here has experience with some other JPEG chipsets
(such as C-Cube), maybe they could tell me how they approached this
problem?  Thanks.

Paul

-- 
Niven's Law #14:   There exist minds that think as well as you do, but
                   differently.
Niven's Corollary: The gene-tampered turkey you're talking to isn't
                   necessarily one of them.
Newsgroups: comp.compression
From: bbobak@math.waterloo.edu (Brad Bobak)
Subject: Re: sizing huffman trees
Organization: University of Waterloo
Date: Wed, 22 Jul 1992 14:27:05 GMT

In article <1992Jul22.003239.15971@s1.gov>, lip@s1.gov (Loren I. Petrich) writes:
> In article <1992Jul21.220205.18507@math.waterloo.edu> bbobak@math.waterloo.edu (Brad Bobak) writes:
> >  I was wondering if anyone has come up with an algorithm for determining
> > the size of an encoded huffman tree from just the frequencies of the
> > letters (sorted or unsorted, it doesn't matter).
> >  Right now, to size a tree, I'm basically building it, and this is time
> > consuming if I'm using alot of trees.
> >  Any pointers, suggestions, etc. would be appreciated.
> 
> 	There are several algorithms for building Huffman trees.
> Perhaps the simplest is the original Huffman one.
> 
> Repeat to build all the nodes:
> 
> 	Look through all the unconnected nodes and symbols to find
> the two with the two smallest frequencies.
> 
> 	Connect these to the new node and make the node's frequency
> the sum of the two branches' frequencies.
> 
> 
> 	I'm sure that this will be fairly efficient unless one has a
> terribly skewed distribution.

  Yes, I'm aware of this, and have an efficient algorithm for building
 trees. What I want to be able to do, tho, is to find out how big an
 output code a huffman tree will generate from just the frequencies.
  Since I'm expecting to calculate the size alot (> 500 times), I can't
 afford to psuedo-build the tree each time, just to find the output size.

Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
From: bladin@wam.umd.edu (Ilana J. Getz)
Subject: Re: Compression artifacts in NBC Olympic coverage
Organization: University of Maryland, College Park
Date: Mon, 27 Jul 1992 22:38:21 GMT

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  ===
==========================================================================
From: madler@cco.caltech.edu (Mark Adler)
Newsgroups: comp.compression
Subject: Re: PKZip 2.x
Date: 24 Jul 92 20:46:20 GMT
Organization: California Institute of Technology, Pasadena


>I was wondering if the current ZIP file format fully machine and
>platform independent; i.e., will it support extended file
>attributes in OS/2, extended attributes/filenames in Unix, etc.

To elaborate on a previous response, Info-zip's next version will
support full OS/2 and VMS attributes.  Whether this is part of the
"ZIP file format" depends on what you mean.

PKZIP's definition of the zip file format includes what are called
"extra" fields that allow you to put whatever you want there, and
if an unzipper doesn't recognize the stuff in the extra field, it
can ignore it.  Info-zip has taken advantage of this for OS/2 and
VMS.  We have sent the specifications of those extra fields to
PKWare, and they may or may not choose to make those an "official"
part of the PKZIP definition.

As for Unix, our current version of zip and unzip already handle
long Unix filenames and Unix attributes, with the exception of
symbolic and hard links.  (Actually our current zip handles symbolic
links, but unzip doesn't.)  Our new versions of zip and unzip will
fully handle symbolic links, but will still not recognize hard links.
It also does not handle owners and groups.  My recommendation is that
if you need that level of fiel system fidelity, that you use tar to
archive and only use zip to compress.  Our new zip can be used as
a filter, just like the Unix compress command.

To answer the inevitable question, "so when do we see this new zip
and unzip?", I'd guess about the middle of August.  They are both
actually ready now, but two of the major contributors are on vacation
until then, so we are waiting for them to put together the final
packages.

Mark Adler
madler@tybalt.caltech.edu
Xref: sparky comp.compression:2814 rec.video:9594 rec.video.satellite:3778 rec.video.production:1138
From: hsu@eng.umd.edu (Dagwood splits the Atom)
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
Subject: Re: Compression artifacts in NBC Olympic coverage
Date: 27 Jul 92 01:59:54 GMT
Organization: University of Maryland, College Park, College of Engineering

In article <tlm1.712195270@Ra.MsState.Edu> 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 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. :)

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.

-dave

-- 
David Hsu    hsu@eng.umd.edu      "There you stand like a duck in a
U of Md Systems Research Ctr       thunderstorm again - aren't you ever
College Park, Md  20742-3311       going to understand?"
+1 301 405 3689                                        - W. A. Mozart
Xref: sparky comp.compression:2843 rec.video:9681 rec.video.satellite:3829 rec.video.production:1172
From: msiskin@css.itd.umich.edu (Marc Siskin)
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
Subject: Re: Compression artifacts in NBC Olympic coverage
Date: 28 Jul 92 13:46:59 GMT
Organization: University of Michigan Language Resource Center Video Services

I checked the picture from the French Canadian service, NBC and one other
service which I forgot the name and what everyone is seeing is an artifact
of the new conversion machines.  I saw similar artifacts at a demo of one
of the new High End converters earlier this year.  What is happening is the
addition of an extra frame that is the interpreted difference between the
frame before and the frame after and the motion blur is not handled well 
when there is a big difference between the two frames.  So we get what is
in essence a sharp still image interspersed in normal motion video. 

Marc Siskin, Senior Media Designer, Video JOAT and Satellite engineer
The University of Michigan Language Resource Center
msiskin@css.itd.umich.edu
marc_siskin@umich.edu
userlf9k@umichum.bitnet
Newsgroups: comp.compression,rec.video,rec.video.satellite,rec.video.production
From: roberts@triton.unm.edu (Robert Smathers)
Subject: Re: "Artifacts" in corners of cable TV pictures
Date: Tue, 28 Jul 92 23:41:58 GMT
Organization: University of New Mexico, Albuquerque

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 believe those logos are meant to keep other TV stations from recording
and using pictures (especially exclusive stories) on their own newscasts.
Not only do the ABC, NBC, and CBS use those logos for their nationa
(national) news, but the three local news channels here use their
own logos in the lower corner of the screen.  

Robert


Newsgroups: comp.compression