HDTenEightyP/NetNews huggingface dataset:
From: tyen@cs.utexas.edu (Anthony Yen)
Newsgroups: comp.graphics.research
Subject: Scaling Down 24-bit Pix
Date: 24 Dec 92 17:58:57 GMT
Organization: Coffee R Us
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu


I was just talking with a friend of mine today, and he asked about the
market viability for a package that scales down JPEG format 24-bit or
32-bit pictures to 16-bit or 8-bit depths.  I made some noises of
dubiousness, pointing out that there are plenty of algorithms with
nice implementations (in code frags or even complete programs) out
which do exactly that right now.  He countered that the package could
make it in the market if it used the results of some multi-million
dollar government-sponsored Los Alamos project which focused on how to
compress high-quality images with little or no data loss.

Frankly, I'm kind of doubtful about this.  Notwithstanding the
standard mathematical proof which shows the infeasibility of
outrageous compression claims, I'm not convinced that the package
would be a big hit because it is so specialized; its market would be a
subset of the already small set of high-end graphics users.

Could someone please confirm or refute the possibility of such a piece
of software?

-- 
 ____     tyen@cs.utexas.edu.....Kowabunga!...
  /ony -- Claimer: Views expressed here == mine && only mine.  Sail tough.

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
From: poynton@vector.Sun.COM (Charles A. Poynton)
Newsgroups: comp.graphics.research
Subject: Re: 35 ns, 63 us later
Summary: 35 ns and 63 us effects are negligible, but consider exposure time.
Date: 24 Dec 92 17:58:53 GMT
Organization: Sun
NNTP-Posting-Host: vector
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu


chrisg@cbmvax.cbm.commodore.com (Chris Green) writes: 

> ... 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.

forgive my being brusque: the effects of ignoring the 35 ns temporal
offset between adjacent pixels are absolutely negligible.

even the 63 us temporal offset between adjacent lines is negligible for
all practical purposes: an ever-so-slight temporal slant is introduced,
but no viewer can tell. in fact tube cameras (e.g. vidicons) have the
slant, but modern (frame-transfer) CCD cameras integrate every pixel
during the same exposure interval, and so have no V/T slant.

the effect that is NOT negligible is the exposure time with respect to the
frame time. this has to do with motion blur, but there's more to it than
that. I'm preparing a note about this, but i'll give you the teaser:

  an infinitely short exposure time is optimum to capture motion IF the
  viewer's eye, at the ultimate display device, is tracking the motion.

but if the viewer's eye is NOT tracking motion, say she's locked on the
stationary background, then you should expose for a frame time and
introduce blur, else the temporal content of the moving thing is liable to
generate spatial aliasing. 

for example, if the shot is across a street, and the viewer's eye is
dwelling on a restaurant sign, and a truck with ten-pixel-pitch black and
white stripes speeds by in front at a velocity of ten pixels per frame,
the black and white stripes will alias to become stationary if you've used
an instantaneous shutter. the viewer will judge the apparently-stationary
stripes that appeared for an instant in front of the restaurant to be an
artifact. if you integrate for a frame time, you will get the blur that
the visual system expects.

however if the viewer was eye-tracking the truck, then she will judge it
to be an artifact that the truck's stripes turned gray when it started to
move.

there is no correct solution to this problem. my belief is that the best
pragmatic solution is to integrate for a third of the frame time.

but i can't prove it.

c.

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
From: bm@shadow.cc.columbia.edu (Blair MacIntyre)
Newsgroups: comp.graphics.research
Subject: Re: comp.graphics.research
Date: 21 Dec 92 18:17:39 GMT
Reply-To: Blair MacIntyre <bm@cs.columbia.edu>
Organization: Columbia University
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.

Take a look at "Device Dependent Image Construction for Computer
Graphics", RV Klassen, Research Report CS-91-19, Department of Computer
Science, University of Waterloo, Waterloo, ON, Canada.  

Victor looks at how to minimize the discrepancies between a desired
image and the image generated by a display device, given a model of the
spatial and temporal intensity profiles of the device (my rough
paraphrase of one aspect of the thesis.  If I'm really not doing it
justice, I hope he'll correct me.)
--
Blair MacIntyre --- bm@cs.columbia.edu --- CS Department, Columbia University

"Men can get into shaving, because it reminds them of what stud hombres
they are, having to tame their manliness on a regular basis." - Dave Barry

--
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: Scalability (was Re: comp.graphics.research)
Date: 21 Dec 92 18:17:57 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 <11579@sun13.scri.fsu.edu> leech@cs.unc.edu (Jon Leech) writes:
<
<In article <11566@sun13.scri.fsu.edu>, rms@well.sf.ca.us (richard marlon stein) writes:
<|> 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).
<
<    PixelFlow should be extremely scalable. The composition network
<has fixed bandwidth no matter how many renderers are used, and latency
<due to the length of the composition network increases very slowly as
<additional rendering boards are added.
<
<    If you're referring to some other aspect, please explain in more
<detail.
<
<|> 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.
<
<    If you mean that each processor is responsible for a fixed screen
<area, this approach wastes most of the processors when looking at
<something far away. It also trades off moving pixels for moving
<primitives, and moving primitives is definitely not scalable.
<Pixel-Planes 5 uses a considerably more complex variant of this
<decomposition and partly addresses these concerns.
<--
<    Jon Leech (leech@cs.unc.edu)    __@/

I would like to PixelPlanes hammer on a 1 Terabyte dataset.  One things for sure
though, I know when I've been beat.  Since the SCVS does not "subdivide" the
screen by assigning processors to a specific region of a single display surface,
I don't think you are in a position to judge the architecture.  Ask Molnar if
he'll sign the non-disclosure agreement, and then you can judge.
--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: olano@cs.unc.edu (T Marc Olano)
Newsgroups: comp.graphics.research
Subject: PixelFlow (was Re: comp.graphics.research)
Date: 21 Dec 92 18:17:43 GMT
Organization: The University of North Carolina at Chapel Hill
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu


In article <11566@sun13.scri.fsu.edu> rms@well.sf.ca.us (richard
marlon stein) writes:
...
>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).

Since I work on PixelFlow, I feel compelled to comment on this.  The
PixelFlow composition network is scalable precisely because it doesn't
suffer from contention problems.  Each node composites its output with
the composited output of the nodes before it and sends it on to the
nodes after it.  It's a straight chain of boards so there is no
contention; each board dealing only with two sources for a single
pixel that it has to choose between for its single pixel output.  The
network is pixel-pipelined so adding an extra board just adds another
pixel-time's worth of latency to the composition.  The scalability
limits are not with numbers of nodes, but with display size since the
composition network speed is determined by the number of pixels you
want to push through per second.

-marc (olano@cs.unc.edu)
Grad student, University of North Carolina at Chapel Hill

--
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.research:412 comp.graphics:13184
From: sillion@verveine.ens.fr (Francois Sillion)
Newsgroups: comp.graphics.research,comp.graphics
Subject: Computer Graphics and the city : any ideas ? any ongoing research ?
Date: 24 Dec 92 17:59:04 GMT
Followup-To: comp.graphics.research
Organization: Ecole Normale Superieure, PARIS, France
Originator: sillion@sesame.ens.fr
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu


This message is a call for ideas and information :

I am trying to collect information about all research and development
areas that are concerned with the use of Computer Graphics and "the city".
This information will be used to suggest/recommend relevant domains for
(french) government support, under a recent initiative establishing a
multi-disciplinary research program for "the city" (la ville).

Possible research domains are the use of CG for urban planification and
development (specialized CAD and decision-helping tools), maintaining urban 
networks of all sorts, geographical information systems, representations of 
architectural and urban phenomena, various simulations and site evaluation, etc.
However I am interested in hearing about everything that people
might be doing that has something to do with cities and urban environments
(and uses computer graphics research) even if not included in the above list.

I suspect that many interesting ideas might come from areas of the world
experiencing a sustained growth of urban ares (South-east asia ? Brazil ?
speak up !)

The goal of the study I am completing is twofold. First of all areas of
expertise in these fields must be identified, so that the new program doesn't
unnecessarily reinvent the wheel. Second, specific research programs will be
sponsored based on the recommendations, and these could and should certainly
take the form of international cooperations. Therefore it is important to
identify research groups working in interesting directions.

Right now what I would like to hear from all of you if "anything that the
juxtaposition of the words -Computer Graphics- and -city- makes you think
of", and of course also all current research directions that you know of (with
contact people). At some point there will be an international workshop organized
to talk about these issues.

Please respond via e-mail.  Thanks in advance to all who will contribute. 
I'll summarize the results for those interested


-- 
+--------------------+-----------------------------+------------------------+
| Francois SILLION   | Laboratoire d'Informatique  | Tel: (33) 1 44 32 20 42|
|     '              |  Ecole Normale Superieure   | Fax: (33) 1 44 32 20 80|
| sillion@dmi.ens.fr | 45 rue d'Ulm, F-75005 Paris | sillion@FRULM63.bitnet |

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
From: leech@cs.unc.edu (Jon Leech)
Newsgroups: comp.graphics.research
Subject: Re: Scalability
Date: 24 Dec 92 17:58:48 GMT
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu


In article <11588@sun13.scri.fsu.edu>, rms@well.sf.ca.us (richard marlon stein) writes:
|> I would like to PixelPlanes hammer on a 1 Terabyte dataset.

    It would take an awfully long time, even if we had that much
memory :-) I'm kinda hoping to play with large terrain datasets on
Pixel-Flow, since they're a ready source of interesting, complex
geometry. I don't think even the Magellan Venus global topography map
approaches 1 TB, however.

    I'm also not sure what your point is. You originally made a claim
that Pixel-Flow was not "truly scalable", which I and Marc Olano, who
are both members of the Pixel-Flow team, have refuted. Pixel-Planes 5
is an older and different architecture. Part of the purpose of PxFl is
to build a machine that does not suffer from the constraints and
problems we learned about from Pxpl5.

    Switching gears (maybe this should be a different thread):

|> One things for sure though, I know when I've been beat. Since the SCVS
|> does not "subdivide" the screen by assigning processors to a specific
|> region of a single display surface, I don't think you are in a
|> position to judge the architecture. Ask Molnar if he'll sign the
|> non-disclosure agreement, and then you can judge.

    I started with your one-sentence description:

	"I advocate a tessellated display approach myself, where each
	tessellation element owns a processor, framebuffer, and
	display."

    and made some comments about inherent problems with the
screen-space decomposition this *appears* (that's why I said "If you
mean that...") to refer to. We have a lot of experience with these
problems, since Pxpl5 suffers from them.

    I'd be interested in hearing what SCVS actually is, but if you
won't or can't provide any more detail, there's no basis for further
discussion. Good luck building your machine. I look forward to
discussing it whenever you can describe it in public.

    Jon (leech@cs.unc.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: jd@superior.cs.unh.edu (Jubin P Dave)
Newsgroups: comp.graphics.research
Subject: radiosity references
Keywords: looking for papers
Date: 24 Dec 92 17:59:00 GMT
Organization: University of New Hampshire  -  Durham, NH
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu

hello,

i am planning to do my thesis on a parallel implementation of radiosity
algorithms. i haven't been able to locate a few papers. could anyone of you
please help me out. any pointers (library holdings, authors' email, publishers,
etc) would be most helpful

the papers are:

1 Bouville,  Christian,   Kadi Bouatouch,  Pierre  Tellier,
Xavier Pueyo, ``A  Theoreti- cal   Analysis   of   Global
Illumination Models'', Proceedings     Eurographics
Workshop on Photosimulation, Realism  and Physics in Com-
puter   Graphics,    Rennes, France,  June  1990, pp. 53-
66, energy  transport  equa- tions

2 Chalmers, Alan G., Derek  J.  Paddon,  ``Parallel Process-
ing of  Progressive  Refine- ment   Radiosity  Methods'',
Second Eurographics Workshop on   Rendering,   Barcelona,
Spain, May 1991,  {parallel- ism},

3 Feda,  Martin,  Werner  Pur- gathofer,``Progressive
Refinement  Radiosity  on  a Transputer Network'', Second
Eurographics   Workshop   on Rendering, Barcelona, Spain,
May 1991, {parallelism},

4 Gifford,   Stephen,   ``Data Parallel  Two  Pass  Render-
ing'',    Naval     Research Laboratory  Technical Report
#?,   Aug.   1991,   {global illumination,   parallelism,
ray tracing},

5 Guitton,   P.,   J.   Roman, Christophe   Schlick,  ``Two
Parallel  Approaches  for  a Progressive     Radiosity'',
Second Eurographics Workshop on   Rendering,   Barcelona,
Spain, May 1991,  {parallel- ism},

6 Liere, R. van, ``Divide  and Conquer  Radiosity'', Second
Eurographics   Workshop   on Rendering, Barcelona, Spain,
May 1991,

7 Purgathofer, Werner, Michael Zeiller, ``Fast Radiosity by
Parallelization'',  Proceed- ings  Eurographics  Workshop
on Photosimulation,  Realism and   Physics   in  Computer
Graphics,  Rennes,   France, June   1990,   pp.   173-83,
{parallelism},

8 Rushmeier, Holly E.,  Daniel R.   Baum,  David  E.  Hall,
``Accelerating the Hemi-Cube Algorithm   for  Calculating
Radiation  Form   Factors'', 5th  AIAA/ASME Thermophysics
and  Heat  Transfer  Confer- ence,  Seattle,  Washington,
June 1990,

9 Tampieri, Filippo,  ``Global Illumination  Algorithms for
Parallel Computer  Architec- tures'',   Master's  Thesis,
Program of  Computer  Graph- ics,   Cornell  Univ.,  Jan.
1990, {parallelism},

if there is enough interest then i will summarize for the net

thanks in advance

jubin

jd@kepler.unh.edu

__
i plan to live forever or die in the attempt

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
Newsgroups: comp.graphics
From: benson@dcdwest.uucp (Peter Benson)
Subject: Request: Computing Equally Spaced Colors
Organization: ITT Aerospace/Communications Division - West
Date: Mon, 21 Dec 92 22:25:32 GMT

I would like to be able to generate a set of N equally spaced colors of
constant brightness.  By equally spaced, I mean in a perceptual sense so
that each color is maximally distinct for that set of N.

I would also like to be able to generate sets of N equally spaced colors
for the two most common classes of color-blind people, red-green and
yellow-blue.  I am assuming that  this will be a similar algorithm to the
early set but with one dimension excluded.

The goal is to specifiy the colors in RGB.  I suspect the correct way to
do this is to sample a line in CIELUV space at N points and then transform
the co-ordinates to RGB.

Is this possible?  Does the code exist to do this?  What incorrect
assumptions am I making?  Is there a book somewhere that describes this
process in explicit detail?

I don't read this group often so e-mail answers would be appreciated.

Thanks in advance.


-- 
Peter Benson, Ph.D.             | ITT Aerospace/Communications Division
phone: (619)578-3080            | 10060 Carroll Canyon Road
fax:   (619)578-5371            | San Diego, CA 92131
email: dcdwest!benson@UCSD.EDU  |
From: sdk@reef.cis.ufl.edu (Steven "Scrib" Kuck)
Newsgroups: comp.graphics
Subject: Ordered triplets->homogenized vectors
Date: 21 Dec 92 22:51:25 GMT
Organization: Univ. of Florida CIS Dept.

I have having some problems doing 3d clipping to a canonical view volume.
My points are represented in camera relative points with +Z into the
screen.  The problem stems that I need to convert these points from
x,y,z ordered triplets to homogenized vertices.  The equation I'm using
is from the Texas Instruments 3D Graphics Library documention, and
looks like this:

given an ordered triplet of ( x, y, z, 1 ), convert to a homogenized
vector of ( x, y, z, w ).

x = D * x / Sx
y = D * y / Sy
z = a * z + b
w = z

D = distance to the viewport
Sx = viewport half-width
Sy = viewport half-height
a  = z-input scaling constant
b  = z-input translating constant

 a = 1 + ( N/F ) 
     -----------
     1 - ( N/F )

 b = -2 * N
     -------
     1 - ( N/F )

where N is near-clipping plane distance and F is the far clipping plane dist.

Okay, now that that is out of the way, the problem becomes rather apparent.
In order to convert back to an ordered triplet, where the fourth element
is 1, you divide by "w", i.e.

[ x, y, z, w ] == [ x /w , y/w, z/w, 1 ]

Now, when I convert TO homogenous vectors and I have an initial Z value of
0, then W becomes zero, and when I try to divide out by W, I get a divide
by zero....I know this has been tackled somewhere else, so if someone can
tell me how to accomplish I would appreciate it.

Brian

Newsgroups: comp.graphics,comp.misc,sci.engr,sci.misc
From: noring@netcom.com (Jon Noring)
Subject: Cutting Intricate and Precise Patterns in Paper-thin materials
Summary: Need ideas
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Tue, 22 Dec 1992 22:07:33 GMT

Hello,

I've posted this request over a year ago, so I thought I'd repost it in
case there are new readers out there in Usenetia who could be of help.

I'd like to develop a fairly low-cost way of rapidly cutting out intricate
and precise patterns in paper-thin material (either paper, plastic or even
metal).  It will be controlled by a computer using input from a data file.
Of course, the term "cutting" is used loosely.  The action could be done
mechanically with something sharp, lasers, or chemical etching, etc, and I do
have latitude in the choice of paper-thin material to use (that is, it doesn't
have to be paper as long as it has "paper-like" properties when handled).

Any clever ideas out there as to how you would go about doing it?  Low-cost
would *ideally* be <$20,000 for the equipment, including computer drivers.
Some speed and throughput is also important.  Doing a thousand in a working
day or less is my minimum requirement, and substantial human interaction is
acceptable (such as installing and removing each sheet).  BTW, the pattern for
each cut sheet will be unique, so multiple cutting at the same time is not a
consideration.

Thanks for your ideas.  Let the creative juices flow.

Jon Noring


(p.s., are there any other newsgroups where I should post this request?)


-- 

Charter Member of the INFJ Club.

Now, if you're just dying to know what INFJ stands for, be brave, e-mail me,
and I'll send you some information.  It WILL be worth the inquiry, I think.

=============================================================================
| Jon Noring          | noring@netcom.com        | I VOTED FOR PEROT IN '92 |
| JKN International   | IP    : 192.100.81.100   | Support UNITED WE STAND! |
| 1312 Carlton Place  | Phone : (510) 294-8153   | "The dogs bark, but the  |
| Livermore, CA 94550 | V-Mail: (510) 417-4101   |  caravan moves on."      |
=============================================================================
Who are you?  Read alt.psychology.personality!  That's where the action is.