HDTenEightyP/NetNews huggingface dataset:
From: jp@taligent.com (John Peterson)
Newsgroups: comp.graphics.research
Subject: Re: comp.graphics.research
Date: 18 Dec 92 22:17:41 GMT
Organization: Taligent, Inc.
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu

In article <11561@sun13.scri.fsu.edu> Chris Green,
chrisg@cbmvax.cbm.commodore.com writes:
>	Has anyone ever attempted to take advantage of the 
>"infinite-frame-rate" of raster scan devices, particularly video?
>What I mean by this to render your animation with the knowledge
>that each pixel is (for instance) 35ns later than the preceeding
>pixel, and that each scan-line is ~63uS later than the preceeding
>one. 

I can't think of anything directly related, but here are a couple 
indirectly related items:

- Many video games and other tightly coded interactive programs
use a technique called "beam chasing" to schedule screen updates
and interaction.  The idea is to be aware of the position of the
CRT beam in order to avoid writing a graphic to the screen while
the beam passes through it, producing a "tearing" effect.

- In a talk given by Pacific Data Images several years ago, one of
the developers there discussed how they produced interlaced animation
for video.  Since they knew that when the work was reproduced the odd
scanlines would appear 1/60th of a second after the even ones (or 
vice-versa, I'm not a video expert) they updated the positions of
moving objects between interlace scans.  I've also heard people say
that being aware of the interlacing is important for getting motion
blur to look correct on video.  The PDI talk was written up in a
SIGGRAPH course notes ages ago ('82 or '84; something like that).

Cheers,
jp

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
From: David.Beasley@cm.cf.ac.uk (David Beasley)
Newsgroups: comp.graphics.research
Subject: Multiplication of quaternion numbers
Date: 14 Dec 92 22:17:08 GMT
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu

Quaternion numbers can be quite handy for representing points in 3-D
space. The multiplication of one quaternion by another performs the 
job of 3-D rotation. But since quaternions are 4-component numbers,
a trivial algorithm requires 16 real-number multiplications to be done.

However, I have devised an algorithm which achieves quaternion
multiplication with only 10 real-number multiplications. Does anyone
know if an algorithm such as this has been published before, or have
I discovered something new here?

I'd be interested to hear from anyone using quaternions for 3-D
manipulations.


David Beasley                          (David.Beasley@cm.cf.ac.uk)    
Department of Computing Mathematics 
University of Wales College of Cardiff                          __o
PO Box 916                                                      \<,   
CARDIFF    CF2 4YN                         ___________________()/ ()___  

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
From: rms@well.sf.ca.us (richard marlon stein)
Newsgroups: comp.graphics.research
Subject: Re: comp.graphics.research
Summary: Analog I/O ain't the problem.
Date: 17 Dec 92 17:17:23 GMT
Organization: Whole Earth 'Lectronic Link
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu

In article <11561@sun13.scri.fsu.edu> chrisg@cbmvax.cbm.commodore.com (Chris Green) writes:
>
>	Has anyone ever attempted to take advantage of the 
>"infinite-frame-rate" of raster scan devices, particularly video?
>What I mean by this to render your animation with the knowledge
>that each pixel is (for instance) 35ns later than the preceeding
>pixel, and that each scan-line is ~63uS later than the preceeding
>one. Given appropriate temporal filtering, and a general enough
>4-d ray-tracer, shouldn't this provide a potential for improved
>quality? Is anyone familiar with any research or applications
>of this? I'm familiar with Don Mitchell's paper on interlace
>and chroma filtering for video.
>
>
>--
>Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
>Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu

Try muxing the outputs from 1000 framebuffers into a single analog stream.
I would rather pass on this approach.  The PixelFlow box captures the output 
from a composition network rated at 4 Gbytes/s into a single frambeubffer.

I don't believe this approach is truly scalable either, since its still
an example of the N to 1 mux problem.  So it is, in my opinion, contention
limited (the laws of physics won't cooperate and provide infinite digital
bus or network bandwidth).

I advocate a tessellated display approach myself, where each tessellation
element owns a processor, framebuffer, and display.  The trick is to coordinate
the system temporally.  The scalable concurrent visualization system trades
contention for asynchronous execution.
--rick
-- 
Richard Marlon Stein, Internet: rms@well.sf.ca.us
To those who know what is not known;  The Chronicles of Microwave Jim!

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
From: CDO@ib.rl.ac.uk (C D Osland)
Newsgroups: comp.graphics.research
Subject: Re: looking for current research in GUI-aspects of color
Date: 18 Dec 92 22:17:26 GMT
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu


On 16 Dec 92 19:47:49 GMT <evelyn@EDU.TAMU.KESTREL> said:
>
>I am about to embark on my graduate research experiment.  The experiment
>is a comparison of color spaces (RGB, HLS, etc.) and color specification
>techniques (sliders, 2-D displays, etc.), a continuation of the research
>conducted by Schwarz at the University of Waterloo ~1985.  There has not
>been much written in this area since then, so I would like to put a call
>out for any others who are actively researching in this area to please
>contact me, so that I can make sure my project is not duplicating existing
>work.  Thanks very much.

I have been doing some work - development rather than research - to enable
decent colour scales to be chosen on-screen.  The target for this is the
production of better videos that are using either smooth or stepped
false-colour mapping of functions.  The work is being done on SGI Iris 3130
and also our video system (Primagraphics system - own graphics library).

Chris Osland
Atlas Video Facility
Rutherford Appleton Laboratory

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
From: twegner@mwunix.mitre.org (Timothy Wegner)
Newsgroups: comp.graphics.research
Subject: Re: Multiplication of quaternion numbers
Date: 16 Dec 92 19:49:05 GMT
Organization: The MITRE Corporation
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu

David.Beasley@cm.cf.ac.uk (David Beasley) writes:

>However, I have devised an algorithm which achieves quaternion
>multiplication with only 10 real-number multiplications. Does anyone
>know if an algorithm such as this has been published before, or have
>I discovered something new here?

I was sent a similar "optimization" by a Fractint user for complex 
multiplication, and easily generalized it to quaternions. However much to my 
surprise the resulting code ran *slower* on my 66 Mhz 486 machine! (My
code also reduced 16 multipies to 10 at the expense of more assignment 
statements and temporary variables.

Needless to say I returned the quaternion fractal type in Fractint back to
Ken Shirriff's original code. I expect however that on a 386/387 combination
the result might have been different.

As far as this idea being new, I think not. 

--
Tim Wegner     Fractint co-author
Internet: twegner@mwunix.mitre.org  Compuserve: 71320.675@compuserve.com

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
From: david@kbssun1.tamu.edu (David Browne)
Newsgroups: comp.graphics.research
Subject: Re: misc jobs  SOLIDS  CAD 3-D  GEOMETRY, FEATURES
Date: 11 Dec 92 21:16:53 GMT
Organization: Texas A&M University, College Station, TX
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu

lakerb@rcwusr.bp.com writes:
: In article <11487@sun13.scri.fsu.edu>, curts@tmpcu.mdc.com (Curt Schroeder) writes:
: < 
: <  >>      EMPLOYMENT POSITIONS, PLEASE POST:
: <  >>      MECHANICAL ENG. & COMPUTER SCIENCE:
: <  >> 
: <  >> MIKE  RUND,  RESEARCH EMPLOYMENT, P.O. BOX 553, RIVERTON, UT  84065
: <  >> mr3847
: < 
: < I would prefer to see the location(s) for the jobs listed, as well.  There are
: < some parts of the country that I have no interest in moving to, and I would
: < like to be able to filter such places out of my job search as quickly and
: < easily as possible.
: < 
: < My $0.02.
: < 
: < Curt
: < 
: < Curt Schroeder | McDonnell Douglas, St. Louis | curts@tmpcu.mdc.com   |
: 
: I have just called information, but there is no phone listing for "Research
: Employment" in Riverton, UT.  Nor is there a listing for "Rund" in Riverton.
: 
: I suggest you be most cautious in dealing here!
: 
: Rob Lake
: BP Research
: lake@rcwcl1.dnet.bp.com
: 
: [ MODERATOR'S NOTE: Verrrry Innteresting... I think we can count this as a
: forgery. Too bad I didn't notice the posting login name before approving
: the original article.. "jklkjlk@utah.edu" is, shall we say, a tad suspicious.
: Sorry, folks. I'll issue a cancel for the original article. -- JRM ]
: --
: Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
: Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu


This guy posted a similar message about a month and a half ago on
misc.jobs.offered.  He gave as his phone number (801) 254-9330.


David Browne
david@kbssun1.tamu.edu


--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
From: rms@well.sf.ca.us (richard marlon stein)
Newsgroups: comp.graphics.research
Subject: Re: comp.graphics.research
Summary: Analog I/O ain't the problem.
Date: 18 Dec 92 22:17:36 GMT
Organization: Whole Earth 'Lectronic Link
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu

In article <11561@sun13.scri.fsu.edu> chrisg@cbmvax.cbm.commodore.com (Chris Green) writes:
>
>	Has anyone ever attempted to take advantage of the 
>"infinite-frame-rate" of raster scan devices, particularly video?
>What I mean by this to render your animation with the knowledge
>that each pixel is (for instance) 35ns later than the preceeding
>pixel, and that each scan-line is ~63uS later than the preceeding
>one. Given appropriate temporal filtering, and a general enough
>4-d ray-tracer, shouldn't this provide a potential for improved
>quality? Is anyone familiar with any research or applications
>of this? I'm familiar with Don Mitchell's paper on interlace
>and chroma filtering for video.
>
>
>--
>Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
>Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu

Try muxing the outputs from 1000 framebuffers into a single analog stream.
I would rather pass on this approach.  The PixelFlow box captures the output 
from a composition network rated at 4 Gbytes/s into a single frambeubffer.

I don't believe this approach is truly scalable either, since its still
an example of the N to 1 mux problem.  So it is, in my opinion, contention
limited (the laws of physics won't cooperate and provide infinite digital
bus or network bandwidth).

I advocate a tessellated display approach myself, where each tessellation
element owns a processor, framebuffer, and display.  The trick is to coordinate
the system temporally.  The scalable concurrent visualization system trades
contention for asynchronous execution.
--rick
-- 
Richard Marlon Stein, Internet: rms@well.sf.ca.us
To those who know what is not known;  The Chronicles of Microwave Jim!

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
From: CDO@ib.rl.ac.uk (C D Osland)
Newsgroups: comp.graphics.research
Subject: Re: looking for current research in GUI-aspects of color
Date: 17 Dec 92 17:17:20 GMT
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu


On 16 Dec 92 19:47:49 GMT <evelyn@EDU.TAMU.KESTREL> said:
>
>I am about to embark on my graduate research experiment.  The experiment
>is a comparison of color spaces (RGB, HLS, etc.) and color specification
>techniques (sliders, 2-D displays, etc.), a continuation of the research
>conducted by Schwarz at the University of Waterloo ~1985.  There has not
>been much written in this area since then, so I would like to put a call
>out for any others who are actively researching in this area to please
>contact me, so that I can make sure my project is not duplicating existing
>work.  Thanks very much.

I have been doing some work - development rather than research - to enable
decent colour scales to be chosen on-screen.  The target for this is the
production of better videos that are using either smooth or stepped
false-colour mapping of functions.  The work is being done on SGI Iris 3130
and also our video system (Primagraphics system - own graphics library).

Chris Osland
Atlas Video Facility
Rutherford Appleton Laboratory

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
Xref: sparky comp.graphics:13056 comp.lang.postscript:6041 alt.graphics.pixutils:2746
From: pharris@ucscm.ucsc.edu (Peter Harris)
Newsgroups: comp.graphics,comp.lang.postscript,alt.graphics.pixutils
Subject: Re: EPSF or MacIntosh Pict  ->  fig Converter
Date: 18 Dec 92 22:36:59 GMT
Organization: University of California Santa Cruz
NNTP-Posting-Host: twilight-mac07.ucsc.edu
X-UserAgent: Nuntius v1.1.1d13
X-XXMessage-ID: <A75793BB09010257@twilight-mac07.ucsc.edu>
X-XXDate: Fri, 18 Dec 92 23:42:03 GMT

Well, since EPSF is (supposed to be) just a
PostScript file with an accompanying PICT for
viewing, it would seem that if you could find a
way to strip the PICT data and turn the file
into a straight PS file youd have something you
could use.


Am I right, and does anyone out there know how
to do this?
Peter Harris
University of California Santa Cruz
Newsgroups: comp.graphics
From: ranger@titan.ucc.umass.edu (Net Ranger)
Subject: Need gif to tek converter, please :)
Organization: University of Massachusetts, Amherst
Date: Sat, 19 Dec 1992 03:26:41 GMT

I need a gif ==> tek converter (tek as in MS-Kermits rendition of the beautiful
tektronic monitors) .... thanks for any info, please email me because as usuall
i have been killing a lot of things randomly on net news and may slip and kill
any posted replies thanx....

--me
.-----------------------------------------------------------------------.
| All that is gold does not glitter,  | John C. Tennyson                |
|  Not all those who wander are lost. | Ranger@TITAN.ucc.umass.edu      |
| -- JRR Tolkien, "Lord of the Rings" |                                 |
`-----------------------------------------------------------------------'

Newsgroups: comp.graphics
From: Mark_Morrill@itc.educ.ualberta.ca (Mark Morrill)
Subject: Need OS/2 Simple Graphics App
Followup-To: comp.graphics
Organization: Instructional Technology Centre, UofA
Date: Wed, 16 Dec 1992 18:10:12 GMT

I need a simple OS/2 graphics application that can read
  a) full screen os2 bmp's (why the @#$ neither os2 nor IBM's development
kit  come with something like PaintBrush I'll never know.)
  b) Macintosh PICT, TIFF, or TGA files
  c) Windows bmp's

All it needs to write is os2 bmp's.

Mark.
Newsgroups: comp.graphics
From: jmunkki@vipunen.hut.fi (Juri Munkki)
Subject: Re: video grabber recomendations for MAC II
Reply-To: jmunkki@vipunen.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology
Date: Thu, 17 Dec 1992 21:41:31 GMT

In article <1992Dec16.181217.20683@wdl.loral.com> hgs@wdl1.wdl.loral.com (Harry Salvini) writes:
>I've just been tasked with finding what's on the market for the Mac II
>for video grabbing.  The source ranges from NTSC, to RGB, to you name it.
>
>What's out there?  If there is a FAQ with this already , or if this is the
>wrong group, would you mind pointing me in the right direction?

Comp.sys.mac.hardware might be a more appropriate group. Better yet,
macintosh magazines regularly review frame grabber boards. There are
dozens of different cards, all for different purposes.

The trick is to find the right price/speed/resolution/quality combination.
Many cards offer video output as well as input. Some are better for grabbing
sequences of pictures for QuickTime, some excel at still frames.

I have a Mass Microsystem QuickImage 24. It takes S-video and composite in
NTSC and PAL, grabs single frames and it should work pretty well with
QuickTime (the software I have doesn't support QuickTime and the QI/QT
component on the Apple developer CD causes crashes with most programs).
The color resolution isn't very good and I get minor moire patterns from
the interference between my video camera's CCD and the grabber's resolution.
(PAL resolution is full 768x576) I paid $259 for the card when it was on
special at the MacZone. I'm happy with the card, but it's not professional
quality.

-- 
  Juri Munkki					       Windsurf: fast sailing
 jmunkki@hut.fi					      Macintosh: fast software
Newsgroups: comp.graphics
From: a722756@roper.mc.ti.com (W. Donald Rolph)
Subject: Re: Simple 3D wireframe rendering method?
Originator: a722756@roper.mc.ti.com
Organization: Texas Instruments / Attleboro Mass / USA
Date: Thu, 17 Dec 1992 21:28:56 GMT


If you simple establsih the rotation matrix between model coordinates and screen
coordinates (with say x being horizontal, y being veritical,  and z being out of
the screen) and neglec the out of screen term you get what you need.
-- 

Regards.
 
Don Rolph  a722756@pan.mc.ti.com WD3 MS10-13 (508)-699-1263
From: schiano@vega.acs.uci.edu (Allen V. Schiano)
Subject: read image Endian questions
Newsgroups: comp.graphics.avs
Reply-To: schiano@vega.acs.uci.edu (Allen V. Schiano)
Organization: University of California, Irvine
Keywords: read image module, Endians
Date: 16 Dec 92 00:59:26 GMT

	Given that we have been having a lot of fun with this recently,
I thought it would be a good time to ask the AVS community and AVS designers
about how AVS reads images, i.e., *.x files.

	We've noticed that on our DEC 5200s running AVS, that the
form of the various .x files in /usr/avs/data/image are often different.
In particular, the digital.x and the avs.x, seem to have their
bytes flipped in terms of the width (or nx) and height (ny) of
the picture.  Since these are the only pieces of information
in the images that specify the image size (no XDR type stuff in the file
like with a field), we're guessing that when the read image module
or the image viewer reads this file it tries to make some
sense of these numbers.  If they are wierd (like negative or large) it
tries to flip the Endian of ALL the values in the dataset (including
the data that defines the alpha, R, G, B of the image).

Is this true?  We found this out when we tried to write X apps
that read in AVS image files.  Some seem to work fine but others died
because they were not flipping the Endian.  We assumed that all the .x files
were the same type.  Forgive us!

You can see this quite easily by using the 'od' command on a couple of
these files (like digital.x and avs.x).

Allen V. R. Schiano
Advanced Scientific Computing
Office of Academic Computing
University of California, Irvine
Irvine, Ca 92727
schiano@uci.edu



Newsgroups: comp.graphics.avs
From: bdickens@elara.mitre.org (Brian Dickens)
Subject:  LANSAT data in AVS
Keywords:  GIS, LANSAT, AVS
Organization: Research Computer Facility, MITRE Corporation, Bedford, MA
Date: Sat, 12 Dec 1992 16:32:58 GMT

I'm attempting to load a LANSAT image into AVS.

I was wondering if anyone had done this, or had information about the image format.

Thanks...

-bdickens
From: lakerb@rcwusr.bp.com
Newsgroups: comp.graphics.avs
Subject: Looking for Phil McDonald
Date: 13 Dec 92 07:32:01 -0600
Organization: BP Research, Cleveland, OH (USA)

I would like to contact:
 Phil McDonald, NOAA/ERL/Forecast Systems Laboratory 

Rob Lake
BP Research
lake@rcwcl1.dnet.bp.com
216-581-5976

Newsgroups: comp.graphics.avs
From: blshyu@nctu.edu.tw ()
Subject: Help with Synchronization
Organization: National Chiao Tung University
X-Newsreader: TIN [version 1.1 PL6]
Date: Sun, 20 Dec 1992 05:47:05 GMT


Dear Netter:

  I met a problem in using AVS to generate a series of images and I am 
looking for your help. What I want to do is to read in a series of fields,
calculate their isosurfaces, render the isosurfaces, write them to a 
series of image files. My network is as below:

                                 boolean
                                    |
			 ----------------------
			|                      |
			|                animate_file
	                |                      |
			|                 read_field
			|                      |
	           animate_file           iso_surface
			|                      |
			|               render_geometry
			|                      |
			 ---------    --------- 
			          |  |
                               write_image

  The "write_image" module needs two inputs from the two branches of
the network indevudually.  Since the right branche of the network
needs more time to complete the calculation than the left branch, I
need a method to do the synchronization of the two branch or I can have
many images saved with different names but with the same content.
Do you know how to synchronize them? Please help me.

-------------------------------------------------------------------------
Bor-Lin Shyu                         <blshyu@cc.nctu.edu.tw>
National Chiao Tung University

Newsgroups: comp.graphics.avs
From: avs@ncsc.org (International AVS Center)
Subject: New module at IAC - ColorToBW
Organization: North Carolina Supercomputing Center
Date: Tue, 15 Dec 1992 20:23:04 GMT

Name        : ColorToBW       Version      : 1.000     Mod Number : 1563 
Author      : Steve Thorpe, International AVS Center
Submitted   : 12/15/92        Last Updated : 12/15/92  Language   : C        
Ported to   : DEC Kubota Convex HP IBM
Description : Converts an image from color to black and white, keeping the
              alpha channel the same in the resulting image.
-- 
International AVS Center
North Carolina Supercomputing Center
avs@ncsc.org