HDTenEightyP/NetNews huggingface dataset:
From: cyberman@exucom.com (Stephen R. Phillips)
Newsgroups: comp.graphics
Subject: Re: REQUEST: StarTrek 3D Objects and others to avalon
Date: 12 Jan 93 01:31:42 GMT
Organization: ExuCom Multimedia Inc.
X-Newsreader: TIN [version 1.1 PL8]


Francisco X DeJesus (dejesus@pluto.nwc.navy.mil) wrote:
: It is the object format for the old CAD-3D program on Atari ST machines. This
: program was written by Tom Hudson who then went on to co-write 3D-Studio. I
: know there is a 3d2-to-DKB converter that came with the DKB raytracer. If
: anyone can find the format spec please upload it to avalon!

Where is the 3d2-to-DKB convertor?

I check the avalon archive not much in the way of specs.  I check the
DXF images YIKES they call those 3d objects? :)

Well anyhow I spent 30 minutes wonder why I couldn't get much using
dkbtrace on an SGI sigh Then I did a bit of tinkering (moving it
around)
:)

I will upload St Pauls Cathedral in DKB format.  However what archive
types are acceptable?
Zip is the smallest so far.

Cyberam
-- 
This is my sig file!
Read rec.games.programer!
Newsgroups: comp.graphics
From: eemrw@cc.newcastle.edu.au
Subject: tiff format desription
Organization: University of Newcastle, AUSTRALIA
Date: Tue, 5 Jan 1993 22:39:29 GMT

Hello,
	A friend of mine is asking about tiff file
formats and how to interpret them. If anyone could
give him and pointers on references / code / or just 
a bit of a description could you please email.

Thanks in Advance
Mark West

mwest@tesla.newcastle.edu.au
Newsgroups: comp.graphics
From: benson@dcdwest.uucp (Peter Benson)
Subject: transformation from CIELUV to RGB
Organization: ITT Aerospace/Communications Division - West
Date: Thu, 7 Jan 93 20:33:05 GMT

Can anyone provide the code to transform a color specified in
CIELUV to RGB format?  The RGB we are working with is 8-bit per
color.




-- 
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  |
Newsgroups: comp.graphics
From: morley@suncad.camosun.bc.ca (Mark Morley)
Subject: RLE Code Available
Organization: Camosun College, Victoria B.C, Canada
X-Newsreader: Tin 1.1 PL4
Date: Mon, 4 Jan 1993 20:06:21 GMT


For those few people who were interested in my run length
compression/decompression C routines, I have uploaded them to
wuarchive.wustl.edu in the /pub/MSDOS_UPLOADS/misc directory.  The file
name is rle.c  These routines are simple, but they work for my purposes. 
If anyone else can use them that's great.  They can be used for anything
you want (not just graphics).  By the way, I have no idea if my RLE
methods are compatible with others (eg: PCX, etc).

Cheers,
MARK

PS: These routines are not tied to DOS or any other platform.  Most C
    compilers should be able to compile the routines.  Also, these routines
    are hard-coded to count "bytes" of 8 bits in length, but changing it to
    support other bit lengths should be fairly simple.

====================================================================
 Mark Morley, UNIX/SUN Administrator     NET: morley@camosun.bc.ca
 Camosun College - Interurban Campus     TEL: (604) 370-4601
 4461 Interurban Road  Room 143-Tech     FAX: (604) 370-3660
 Victoria,   B.C.  Canada    V8X 3X1
Newsgroups: comp.graphics
From: paulhz@casbah.acns.nwu.edu (Paul Hertz)
Subject: Re: Your one stop GRAPHICS shop!
Followup-To: comp.graphics,alt.graphics.pixutils
Organization: Northwestern University
Date: Tue, 12 Jan 1993 15:39:39 GMT

In article <9301084434@genesis.nred.ma.us>, abh@genesis.nred.ma.us (Andrew
Hudson) wrote:

> Having worked on a project which samples at 48-bits (16-bit CCD
> * 3 planes) and then quantizes down to 24-bit I can say that
> the human eye CAN and does distinguish color information
> at higher than 24-bit/pixel.  This information is especially
> noticeable in highlights and shading, i.e. dynamic range.
> 
> When we get tired of those ugly 24-bit images we can get started
> on 36 and 48-bit images!
> 
> - Andrew Hudson
> North Coast Software


Part of the apparent ability to distinguish color differences at that pixel
depth may come from the non-linear response of the eye to specific
wavelengths and intensities of light. I.e., we see many more shades in
certain wavelengths and intensities that in others, so there may indeed be
colors displayed which differ only in least significant bits (as far as
their internal represeatation is concerned), but which appear clearly
different to the eye. In any case, color in this sense is a psychological
phenomenon, rather than a technological or scientific. While gamma settings
on monitors attempt to approximate the response of the human eye, they are
*only* an approximation.

Also, re, JPEG compression:

In my experience JPEG does an excellent job with scanned images, where
there is an overall graininess to the image. JPEG works, so I'm informed,
by transforming spatial domain information to frequency domain information,
and then removing or smoothing frequencies which are considered only
marginally perceptible. This makes the image easier to compress--which is
subsequently done using *I think--correct me if I've remembered this wrong*
LZW compression. Differencing an image before and after compression reveals
that pixel values have been slightly shifted.

However, for images with single pixel lines, flat shaded areas, or geomtric
patterns, JPEG does not work so well. An RLE compression method (such as
Apple's PICT), or LZW-TIFF will usually squeeze such files apprecialby,
without generating the "fringe" artifacts JPEG seems to create.


And the thread goes on...



  /\\ | Paul Hertz 
/ \\  | Advanced Technology Group, Northwestern University
/ \/ \| 627 Dartmouth Place
\ /\//| Evanston, IL 60208
  /   | 
 \\// | Internet: paulhz@casbah.acns.nwu.edu
Newsgroups: comp.graphics,alt.graphics
From: stirling@ozrout.uucp (Stirling Westrup)
Subject: Need OAK Tecnologies VESA driver for OTI077
Organization: Andre P. Ozrout
Date: Tue, 12 Jan 1993 21:23:10 GMT

I've recently tried to install the VESA driver that came with my VGA card.
The card appears to be a taiwan clone of an OAK Technologies card, and
contains all OTI chips.  The driver that came with the card is 67VESA.COM
which is for the OTI067 VGA chip, which isn't what's on my board.  I appear
to have a later chip, called the OTI077, which I can't find a driver for.
The only driver other driver I can find on the internet is 37VESA.COM which
doesn't work either.  If anyone could tell me where to get a copy of 
77VESA.COM or the equivalent, or just knows how I can contact OAK
Technologies so that I could ask them, I would appreciate it.

Please e-mail replies, since I don't think many folks on this conference
will be terribly interested in the answers.  Thanks.

-- 
||    BUNGEE SIDEWAYS!                              o   )))
||                                                 /-- ///
|P~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\_  \\\      __ -_
||    stirling@ozrout.uucp                                 ((( (_)T(_)
Newsgroups: comp.graphics
From: niko@iastate.edu (Nikolaus E Schuessler)
Subject: Re: REQUEST: StarTrek 3D Objects and others to avalon
Organization: Iowa State University, Ames, IA
Date: Wed, 6 Jan 1993 15:14:52 GMT


>I have all the Star Wars ships as well as most of the Star Trek ships in
>.3D2 format.  I will convert them all to TTDDD (Imagine) and see what I
>can do about uploading them.  I don't currently have FTP access so
>alternatives are welcomed.

>
>These objects will be available on my BBS, "The Graphics BBS" via email
>file server.
>
>Send mail to file-server@graphics.rent.com with the word "HELP" in the
>body of the text and a help file telling you how to use the server will
>be sent to your mailbox.

 I'm looking into this and if I can manage to down load them I will post
them to china.lake

p.s. what is the .3D2 format? what program? specs.. anyone anyone?




-- 
Niko Schuessler               
Project Vincent Systems Manager              email: niko@iastate.edu
Iowa State University Computation Center     voice: (515) 294-1672
Ames IA 50011                                snail: 272 Durham
From: sundar@fiber-one.ai.mit.edu (Sundar Narasimhan)
Newsgroups: comp.graphics
Subject: Re: Polygon-polygon intersection
Date: 4 Jan 93 22:29:34 GMT
Reply-To: sundar@ai.mit.edu
Organization: MIT Artificial Intelligence Laboratory
NNTP-Posting-Host: fiber-one.ai.mit.edu

|> In article <7418@tivoli.UUCP> twb@tivoli.com (Tom Bereiter) writes:
|> >I'm looking for an efficient test for whether two 2D polygons intersect.
|> >The brute force approach seems to be: do a point-in-polygon test for each
|> >point of polyA in polyB, but if that says false you still have to check for
|> >line intersections.  This feels like the sort of problem, like area of
|> >a polygon, which has a non-obvious trivial answer.
This seems to come up repeatedly, and it DOES have a simple answer,
(simple, oh no, there's that word again :-) -- maybe this should be in the
FAQ. 

Polygon intersection can be reduced to point in polygon in linear time. 
Basically convolve A & B, reducing A to a point and growing B by the
corresponding amount. Now test if the reference point of A is within the
grown B. In 2-D the convolution of two polygons is still a polygon, and in
3-D two polyhedra convolved will give another polyhedron and the problem
reduces to point in polyhedron. 

Note that in 2-D a polygon has 3 degrees of freedom. Thus, if only one
of your polygons is moving, you can construct a convolution in 2+1D
and test for intersection extremely fast just given the moving polygon's
configuration.

I have code to do this which I am presently using for my thesis, but I
can strip out the convolvers if you are desparate. (In 2-D my algorithm
is essentially that of Guibas et al. the reference to whose paper, I've
included below). 

%Y Conference
%A Guibas, L., Ramshaw, L., and Stolfi, J.
%T A Kinetic Framework for Computational Geometry
%J Proc. of the 24'th Annual IEEE Conference on the Foundations of Computer Science
%C Tucson
%P 100-111
%D 1983
Newsgroups: comp.graphics
From: stgprao@st.unocal.COM (Richard Ottolini)
Subject: Re: Has anyone written a hologram-generating program?
Organization: Unocal Corporation
Date: Mon, 28 Dec 1992 15:57:55 GMT

Something in Computers in Physics magazine in 1989 or 1990.
Use mathematics of geometric optics to compute diffraction patterns
and photo reduce the printouts.
Newsgroups: comp.graphics
From: m0ali001@ulkyvx.louisville.edu
Subject: 3d file of brain needed
Date: Sun, 10 Jan 1993 06:47:49 GMT
Organization: University of Louisville

Im in need of a 3d data file of the human brain, preferebly in DXF or 3DS
format, but anything will suffice. Does anyone know of a FTP site containing
this? Thanks in advance


Xref: sparky comp.graphics:13581 alt.graphics.pixutils:2872 alt.binaries.pictures.utilities:2399 alt.binaries.pictures.d:6089
From: raytrace@cs.curtin.edu.au (RayTrace project)
Subject: Re: SIGGRAPH to do online electronic publication
Keywords: SIGGRAPH, electronic publication, online, experimental
Organization: Curtin University of Technology
Date: Sun, 10 Jan 1993 13:56:36 GMT

rsc@altair.csustan.edu (Steve Cunningham) writes:



>   Following the successful pattern of the SIGGRAPH '91 panels transcripts, 
>we plan to make the contents available in several formats.  Articles may 
>include text, monochrome or color figures, or additional material if it can 
>be used on a wide range of platforms).  In the ftp area, text will be 
>provided in plain ASCII, rtf (rich text format), and PostScript formats, 
>and images will be provided in tiff format and possibly other formats.  

One of the things you are forgetting is that non-paper implies temporal
data - what format for videos?, what for sound?, what language for
programs? Don't limit the content to what goes onto a piece of paper!

>-- Steve Cunningham
>   SIGGRAPH director for publications
--

	Andrew Marriott.

--------------------------------------------+----------------------------------
* Internet: raytrace@cs.curtin.edu.au                                         *
*                                                                             *
* Mail   : School of Computer Science         | Tel: +619 351 7680            *
*          Curtin University of Technology    | Fax: +619 351 2819            *
*          Kent Street, Bentley                                               *
*          Western Australia, 6102                                            *
--------------------------------------------+----------------------------------
Newsgroups: comp.graphics
From: hallch@CS.ColoState.EDU (christopher hall)
Subject: Re: Comments on Cirrus Logic
Date: Sun, 10 Jan 1993 22:12:44 GMT
Organization: Colorado State University, Computer Science Department

In article <1993Jan9.172537.3534@nuscc.nus.sg> eng10205@nusunix1.nus.sg (LING SIEW WEE) writes:
>A friend of mine has many trouble with a display card called:
>
>	Cirrus Logic 5422(AVGA3)
>
>Apparently the problems were the inability to configure to Windows even
>with its own manufacture supplied drivers and conflicts with other
>cards.
>
>I just like for any comments on this card  ie. whether is it good and
>its compatibility with softwares.
>
>
Hi,

     I know that Magnavox builds their computers using a Cirrus Logic card.
I don't know if the card you mentioned is the same one included in my
friend's computer but I will tell you what I know.  I DO NOT LIKE THIS CARD.
The only documentation that came with the card was on the hard-drive.  If I
remember correctly I had to call Magnavox a couple of times also to find out
what the brand on the card was.  As to compatibility problems, I could not
get the card to switch into same of the supposed video modes it supported.
Maybe the documentation was incorrect but from what I can tell this is not
really a SVGA card that my friend thought he was getting with the computer.
I know that my friend is very unhappy with his computer and so he wrote a
letter to Magnavox telling them that.  It took them 3-4 months to reply and
the response basically told me that I was an idiot (not in so many words but
all I had to do was read between the lines)  I must say that I was not
impressed with the card nor Magnavox and I know that I would not buy one if
I was presented with the choice.

							Regards,
							Chris Hall

/--------------------------------------------------------------------------\
|    The world cannot end today because it is tomorrow in Australia...     |
|                                                                          |
|       |________          Chris Hall                                      |
| ||OOO||________>         hallch@handel.colostate.edu                     |
|       |                                                                  |
\__________________________________________________________________________/

Newsgroups: comp.graphics,comp.sys.sgi
From: lroy@jetson.asd.sgi.com (Linda Ann Roy)
Subject: Re: Controlling Lighting
Reply-To: lroy@jetson.asd.sgi.com (Linda Ann Roy)
Organization: Silicon Graphics, Inc., Mountain View, CA, USA
Distribution: comp
Date: Mon, 11 Jan 1993 18:22:54 GMT

In article <p5CTrA0BBh107h@eosvcr.wimsey.bc.ca>, aew@eosvcr.wimsey.bc.ca
(Alan Walford) writes:
|> In <C0DABM.16F.1@cs.cmu.edu> gleicher@CS.CMU.EDU (Michael Gleicher) writes:
|> >I'm looking for good ways to interactively control lighting. There's
|> >remarkably little in the literature - about all I know about is Poulin and
|> >Fournier's paper in last year's interactive 3D symposium. 
|> 
|> I saw a demo of a new Silcon Graphics modelling program that I felt had
|> a very nice way of adjusting, moving, and rotating light sources. I'm afraid
|> I do not remember the name of the program. Anybody know which one I am
|> refering to?  When you clicked on a light source in their view (which showed
|> the main object and the cameras and the light source) a set of 3 axes
came up
|> and one manipulated the object (light or camera) along these axes. It is
|> too difficult to explain in words. You would have to see it for
yourself. Very
|> slick!
|> 
|> Al
|> 
|> -- 
|> Alan Walford     Eos Systems Inc., Vancouver,B.C., Canada  Tel: 604-734-8655
|> aew@eosvcr.wimsey.bc.ca           OR       
...uunet!wimsey.bc.ca!eosvcr!aew  



Sounds like Inventor.
Newsgroups: comp.graphics,comp.compression,alt.binaries.pictures.misc,sci.image.processing
From: hee@cs.columbia.edu (Edward Hee)
Subject: dcview21.zip -- ColorView for DOS JPEG Viewer
Keywords: JPEG JFIF GIF BMP Viewer Converter
Organization: Columbia University Department of Computer Science
Date: Tue, 12 Jan 1993 02:47:51 GMT



The latest version of ColorView for DOS, version 2.1, a fast JPEG/JFIF,
GIF, Windows BMP viewer/converter/editor has been posted as dcview21.zip
on alt.binaries.pictures.utilities.  VESA graphics drivers for
ColorView for DOS have also been posted as vesadrv2.zip on the same
group.

The .zip files are also available at wuarchive.wustl.edu in the
/pub/MSDOS_UPLOADS directory.

			   ColorView for DOS
	  Copyright (c) 1992 Millennium Technologies Corporation
			   All Rights Reserved

			      Version 2.1


ColorView is a color image viewer/converter/editor for the DOS environment.

Changes in version 2.1:
	o  Improved support for all Windows BMP image formats
	o  Support for monochrome JPEG images
	o  Text-mode batch image conversion and scaling from the command
	   line.

In this version, ColorView supports reading and writing the following
graphics file formats:

	o  JPEG (JFIF subset)  JPEG is a highly compressed 24 bit "true 
	   color" picture file format which has more colors and a smaller 
	   file size than GIF files.
	o  GIF'87, GIF'89 including animations
	o  Windows BMP files (4, 8 and 24 bit, including 8 bit RLE)


ColorView provides: 
	o  Floyd-Steinberg dithering
	o  Heckbert color reduction
	o  Gamma correction, Hue, Saturation, and Brightness controls
	o  Sharpening, Smoothing, Embossing, Edge Tracing and other 
	   image filters
	o  Copy and Paste operations between all supported image formats
	o  New Image creation and text drawing functions
	o  Adjustable Image Transparency Effects
	o  "Blue Screen" effects
	o  Image Rotation and Mirroring functions
	o  Intuitive graphical user interface, with or without a mouse
	o  Slideshow mode for uninterrupted image viewing
	o  Fast and extremely accurate Image Scaling for reducing and
	   enlarging pictures
	o  GIF Animation support
	o  Ability to switch graphics modes while viewing an image
	o  And much more!


ColorView will work with:
	o  Any Text mode display (Batch File Conversion)
	o  Standard VGA 320x200 video mode
	o  8 bit, 256 color display boards with a VESA driver 
	o  15 bit, 32768 color display boards with a VESA driver
	o  16 bit, 65356 color display boards with a VESA driver
	o  24 bit color display boards with a VESA driver
	o  DOS 2.x, 3.x, 4.x, 5.x
	o  640 K or more of physical memory
		(expanded and extended memory will automatically be used)
	o  a hard disk
		(automatically used if not enough physical memory)
	o  80286, 80386-SX, 80386, 80486, Pentium processors
	o  Microsoft-compatible mouse

ColorView for DOS (CVIEW.EXE) will run on '286 processors and will
automatically take advantage of a '386 or better processor if one
is available.

Enjoy!
Newsgroups: comp.graphics
From: doni@netcom.com (Donald R. Ingenito)
Subject: Re: Commercial Vivid?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
X-Newsreader: Tin 1.1 PL5
Date: Sat, 9 Jan 1993 06:18:34 GMT

Stephen B Coy (coy@plato.ds.boeing.com) wrote:
: In article <1ievf7INNmv@usenet.INS.CWRU.Edu> af774@cleveland.Freenet.Edu (Chad Cipiti) writes:
: >
: >I've heard rumors that there is a commericla version of Vivid
: > coming out soon this year.  Anyone know anything about this?
: 
: No, what have you heard?
: 
: Stephen Coy
: coy@plato.ds.boeing.com
: 
: :-)
: 

    Yeah it's out in cartridge form for the Gameboy. I understand
it'll do distributed processing across a head-to-head network. What'll
Newsgroups: comp.graphics,alt.graphics.pixutils
From: pfk@rz.uni-jena.de (Frank Klemm)
Subject: Re: Your one stop GRAPHICS shop!
Reply-To: pfk@rz.uni-jena.de (Frank Klemm)
Organization: University Jena, Germany
Date: Tue, 12 Jan 1993 16:44:06 GMT


In article <9301084434@genesis.nred.ma.us>, abh@genesis.nred.ma.us (Andrew Hudson) writes:
|> In article <1ij6taINN8rf@gvgspd.gvg.tek.com> markg@gvgdsd.GVG.TEK.COM (Mark Gydesen) writes:
|> >In article <1ifdfaINNim7@hpscit.sc.hp.com> klui@corp.hp.com (Kenneth K.F. Lui) writes:
|> >>if full-color display hardware is available.  People won't have
|> >>8-bit video forever, and I see the trend going towards 24-/32-bit
|> >>video in the near future.  The trend is JPEG; GIF will die soon
|> >
|> >There is no need to go beyond 24 bit color, unless you want to store IR
|> >or UV data as well as visible light. The human eye can only distinguish
|> >up to 24 bits of color information.
|> >
|> >But then again, one never knows... for 3D images, or heat sensitive
|> >images etc... beyond 24 might become practical, ... sorry for the
|> >interruption.
|> >
|> >/------------- Mark Gydesen ---------------+--- Grass Valley Group ---\
|> 
|> Having worked on a project which samples at 48-bits (16-bit CCD
|> * 3 planes) and then quantizes down to 24-bit I can say that
|> the human eye CAN and does distinguish color information
|> at higher than 24-bit/pixel.  This information is especially
|> noticeable in highlights and shading, i.e. dynamic range.
|> 
|> When we get tired of those ugly 24-bit images we can get started
|> on 36 and 48-bit images!
|> 
|> - Andrew Hudson
|> North Coast Software
|>
Yes you are right. I use the simple dither algorithm to reduce raytraced 
pictures  (double) down to 8 bit per plane. The border of the human eye
is between 9 and 10 bit depending on the quality of the display. Note that
the RGB color room can't display all visible colors. I have written an article
about this problem and problem of color conversation (loseless). But in German.

Frank
Newsgroups: comp.graphics,comp.compression,alt.comp.compression
From: alanf@cs.monash.edu.au (Alan Grant Finlay)
Subject: Re: CCITT Group3&4
Keywords: Image Processing
Organization: Computer Science, Monash University, Australia
Date: Mon, 11 Jan 1993 05:33:08 GMT

bartb@ogicse.cse.ogi.edu (Bart Butell) writes:

>I am looking for public domain software for reading and writing
>CCITT Group 3 and 4 images.  Does any know where I can find such software.

>BarT

I have seen a number of requests of this sort so we have decided to make
our conversion routines available via anonymous ftp.  They use Sam's public
domain tifflib from SGI and our own private image processing library.  The hard
stuff is all done by Sam, these files are provided to show to read and write
a CCITT group3/4 tiff format.  The calls to our private image processing
library should all be quite simple to understand and replaced by your own
library calls.  They are:

i_error(status,message)		reports error message to stderr and aborts
				if status I_FATAL.
i_malloc			macro to call malloc, defined below.
uchar i_getuchar(image,row,col)	return pixel value at row and column for image.
i_putuchar(dest,row,col,pix)	set pixel value at row and column for image.
IMAGE *i_mktemp(nrows,ncols,8)	make a temporary image of given dimensions and
				8 bits per pixel.
i_dump(image, name, fmt)	dump image as file <name> with format <fmt>.

The IMAGE data structure contains the following fields (amongst others):
        long    rows;           /* number of scan lines */
        long    cols;           /* pixels per scan line */
        uchar   **rowbuf;       /* pointer->array of pointers->row buffers */
        long    bitsperpixel;   /* pixel size */

#define i_malloc(var,TYPE,n) (var=(TYPE*)malloc((n)*sizeof(TYPE)),(var)==NULL ? i_error(I_FATAL,"out of heap"),(var) : (var))

The files are available by anonymous ftp from internet: merry.cs.monash.edu.au
[130.194.67.101] in directory pub/alanf/TIFF_FAX.

,-------Alan Finlay, email: alanf@bruce.cs.monash.edu.au, phone: (03)565-5225.
|	Victorian Centre for Image Processing and Graphics,
|	Monash University, CLAYTON 3168, Australia.
Newsgroups: comp.graphics