HDTenEightyP/NetNews huggingface dataset:
From: rasure@borris.eece.unm.edu (John Rasure)
Newsgroups: comp.soft-sys.khoros
Subject: Info for those compiling Khoros on SUN 3
Date: 14 Aug 92 18:18:00 GMT


Mike Missler spent may wasted hours fighting some compiling problems, his
report that follows may help you out.




--- Forwarded mail from missler@cse.uta.edu (James M Missler)

From: missler@cse.uta.edu (James M Missler)

John -
	It appears as though the bug has been fixed per Mark Young's
guidance.  It is not necessary to use -g in compiling the vgparm
library (-g overides any -O option) -- the "#define LibraryCDebugFlags -O1"
is the key addition to sun.cf.  With this flag we circumvent optimization
errors caused by the -O flag on the sun3 platform.  A modified bug
report follows for you to review/edit and distribute as appropriate.
Thanks for helping me fix this problem.
						- Mike Missler


                    \     /  ))
                 (( |\   / \  ))     
                ((( | \ |   \     
                 (( |  \|    | \ \
                     \  \\  /   ) )		  Khoros System 1.0 Patch 5
  ---------          __\|_\/   (* *)                Bug Report
--------          (_/       \== \ /              khoros-bugs@chama.eece.unm.edu
   ----------       \_______/    V 
		      ))))))        



Program Name:
------------
	cantata on sun3, OS 4.1.1, no gcc, no patched loader

Bug Description:
---------------
	A segmentation error results when cantata is run.  Use
	of the debugger dbx after recompiling cantata with -g
	shows the error occurs in $KHOROS_HOME/src/xvroutines/
	cantata/routines.c with the call to vlistfile(), a vgparm
	library routine.
		
Bug Fix: (by Mark Young)
--------
	The problem is that the bug is caused in the vgparm library
	not in the cantata program code.  This bug is caused by
	optimization errors using -O on sun3.  It is necessary to
	recompile both programs and libraries with -O1.  To do this
	define the following in your sun.cf file:
	
	#define HaveSunPatchedLd NO
	#define HasGcc NO
	#define DefaultCDebugFlags -O1		/* for programs */
	#define LibraryCDebugFlags -O1		/* for libraries */
	
	Note that a comment in sun.cf has a typing error.  The correct
	flag is -O1 (minus oh one) and not -01 (minus zero one).  Then
	change directory to $KHOROS_HOME/src, run "make allclean"
	and then the "installit".


--- End of forwarded message from missler@cse.uta.edu (James M Missler)
From: donohoe@jemez.eece.unm.edu
Newsgroups: comp.soft-sys.khoros
Subject: Comments: extensible header
Date: 19 Aug 92 15:28:40 GMT

From khoros-mailer Tue Aug 18 21:04:42 1992
Return-Path: <khoros-mailer>
Received: by chama.eece.unm.edu (4.1/VISION/16Oct91)
	id <9208190255.AA22654@chama.eece.unm.edu>; Tue, 18 Aug 92 20:55:40 MDT
Received: by chama.eece.unm.edu (4.1/VISION/16Oct91)
	id <9208190255.AA22641@chama.eece.unm.edu>; Tue, 18 Aug 92 20:55:15 MDT
Posted-Date: 17 Aug 92 14:56:22 GMT
Received-Date: Tue, 18 Aug 92 20:55:15 MDT
Newsgroups: comp.soft-sys.khoros
Subject: Re: Khoros 2.0 viff structure
Date: 17 Aug 92 14:56:22 GMT
From: ph@physiol.ox.ac.uk (Patrick Haggard)
Organization: Physiology Department, Oxford University, Oxford, UK.
Message-Id: <4305@inca.comlab.ox.ac.uk>
To: khoros@chama.eece.unm.edu
Status: R


ph@physiol.ox.ac.uk (Patrick Haggard)  writes:

+ I'ld like to add strong support for the concept of having the header
+ as open as possible.  The idea of separate headers for different
+ levels of a file is also interesting.  History strings in headers
+ would also be very useful.  How about having a variable length header,
+ to which the user can add new fields (history field, comment field
+ etc).  As long as the programs can keep a track of where the headers
+ are and how long they are that should be OK.
+ Patrick


The Environmental Research Institute of Michigan (ERIM),  in their
C4PL image file format,  specifies a fixed-length header, but includes
a point to a header "sequel", allowing the user to extend the header.
In "stock" applications, which have no header extension,  the pointer 
is NULL.  We have found this extensible header useful for calibration
data,  processing history,  etc.

===========================================================
Greg Donohoe, Assistant Professor
Electrical and Computer Engineering
University of New Mexico
Albuquerque, NM 87131   (505) 277-6724
donohoe@chama.eece.unm.edu
===========================================================
From: Vikram Chalana <vikcha@u.washington.edu>
Newsgroups: comp.soft-sys.khoros
Subject: Problem with form
Date: 19 Aug 92 18:07:37 GMT

I tried running cantata with the contrib.form in
$KHOROS_HOME/contrib/repos/cantata. But it gives me some error saying
that it is unable to read any file which has the variable KHOROS_CONTRIB
in its path. 
I have set the variable KHOROS_CONTRIB as KHOROS_HOME/contrib in my
.cshrc and despite that I am getting the error.

also I am getting a segementation fault while trying to run kinstall. On
using the debugger I found it to be at a line gr_read_configfile() in
kinstall.c 

Any help from the KHOROS_GURUS out there. 

******************************************************************************
Vikram Chalana			 *  The Future is Not what it used to be....
Bioengineering			 *		It never Was..		
University of Washington, Seattle*
**********************************



Newsgroups: comp.soft-sys.khoros
From: ruprecht@informatik.uni-freiburg.de (Nick Ruprecht)
Subject: Re: vpostscr - how to get multi-output ?
Organization: Institut fuer Informatik der Universitaet Freiburg, Deutschland
Date: Fri, 21 Aug 92 05:53:33 GMT

rasure@borris.eece.unm.edu (John Rasure) writes:

>In "vpostscr - how to get multi-output ?", Joachim Glaubrecht  #Alwd# writes:
>+ BUT: we now like to get 4 times the SAME image on 4 A4-papers, 
>+ WITHOUT sending the PostScript-file again to the printer.

>here is one solution ....
>vpostscr -i file ..... stuff .... > file.ps
>lpr -Pprinter_name -#4 file.ps

To produce multiple copies with the -#<n> option does not require an
intermediate file. Just put

	| lpr -Pprinter -#4

into the "Send to Printer" line of vpostscr. However, this is not what
the original poster asked for, because it will send the file to the
printer four times. A better solution is to put a line

	/#copies 4 def

before the final "showpage" in the PostScript file. (copypage works as
well, but use of #copies is the way recommended in the PostScript
reference manual.)

"Number of copies" would make a nice additional field in the vpostscr pane.

Best regards -

--

Nick Ruprecht
Institut fuer Informatik der Universitaet Freiburg
From: caseypa@elec.canterbury.ac.nz (P. A. Casey)
Newsgroups: comp.soft-sys.khoros
Subject: viff format manual WAS:<none>
Date: 15 Aug 92 03:06:59 GMT
Organization: Electrical Engineering, University of Canterbury, New Zealand

In article <1992Aug15.145233.342@csc.canterbury.ac.nz>, caseypa@elec.canterbury.ac.nz (P. A. Casey) writes:
> The current version of Khoros on the system here is 1.0  patch 3.  In the viff.h header file there is the comment to see $KHOROS_HOME/manual/viff_format for further information and examples.  This file/directory does not exist.  What we were wondering is > if anyone else has had the same problem or whether the directory was never created.
> 
> Just wondering 
> 
> Peter Casey
> caseypa@elec.canterbury.ac.nz


Sorry about not tacking a subject on the last post.  I must remind myself to get some sleep one day........
From: E59387@TRMETU.BITNET
Newsgroups: comp.soft-sys.khoros
Subject: About FAQ?
Date: 15 Aug 92 07:02:28 GMT
Organization: Middle East Technical University - Computer Center


       HI,
Where can I find FAQ aboutkhoros?

Thanks in Advance.
From: patrick@marl.panasonic.com (Patrick Devaney)
Newsgroups: comp.soft-sys.khoros
Subject: Change of email address
Date: 18 Aug 92 17:20:33 GMT

Can you please transfer my space on your mailing list to another member of
my laboratory?

	Current email address:	patrick@marl.panasonic.com

	New     email address:	 daniel@marl.panasonic.com

Thanks

Patrick Devaney
From: sauer@chama.eece.unm.edu (Tom Sauer)
Newsgroups: comp.soft-sys.khoros
Subject: Re: Khoros, C++ and next version of Khoros...
Date: 18 Aug 92 14:43:18 GMT

Hi,

On Aug 17,  8:22, Steve Berczuk wrote:
} Subject: Khoros, C++ and next version of Khoros...
>> Does anyone have any prediction as to when V2 of khoros will be
>> available?

Khoros 2.0 alpha will go out to Consortium Members in November followed
by beta and finally a public release about April of next year.

>> 
>> will V2 have any hooks in it such that it works more cleanly with C++?

Yes. the Imake/Make will support C++.

>> 
>> is there a list of features that will be in V2? 

The khoros group can send you a folder of information on Khoros 2.0.
please mail to khoros-request@chama.eece.unm.edu requesting such information.
	
>> thanks
>> 
>> -- 
>> berczuk@space.mit.edu	| Phone: (617) 253-3840;  Fax: (617) 253-0861
}-- End of excerpt from Steve Berczuk

Thanks,

Tom


-- 
============================================================================
Tom Sauer                 |  Email: sauer@chama.eece.unm.edu
The Khoros Group          |
Dept. of EECE             |  
University of New Mexico  |  Phone: (505) 277-6563
Albuquerque, NM 87131     |    Fax: (505) 277-1439
============================================================================
Newsgroups: comp.soft-sys.khoros
From: marshall@ll.mit.edu (Hunter Marshall)
Subject: reading bands into xprism2(3)
Organization: MIT Lincoln Laboratory
Distribution: comp
Date: Wed, 12 Aug 92 12:04:35 -0400

I have looked at getting xprism2 to read in only the bands chosen for
display. This way I can look at pieces of BIG files.

I am looking for help, hints, warnings.

The relevant file is run_opts.c in the xprism directory. It contains
many functions.

The data is read in inside the function run_plot_data() via readimage().
I believe that this could be replaced with a call to readheader().
Thus the call to assign_band() could remain unchanged except for
the need of a file name or descriptor.

Inside assign_band(), the following snippet of code effects the transfer
from image to whatever plotting routines like. This is the code for
location data, the imagedata case is similar.


@@@@@@@@@@@@@@@@@
	   /*
	    *  User choose location data for a dimension.
	    */
	   imagesize(image,&dsize, &dcount, &msize, &mcount,&lsize, &lcount);
	   index = which_band - num_bands;
	   size = lsize/image->location_dim;
      	   data = (char *) &image->location[index * size];
      	   assign_data(plot->points, data, plot->size, axis, VFF_TYP_FLOAT);
@@@@@@@@@@@@@@@@@

If I'm correct, imagesize() is a real boon since it gives an overview of the
viff file structure in BYTES. Given that we have decided on a clean way to
pass in a file descriptor, we can kfseek to right location (I have no idea
where that file descriptor is pointing), and kfread the desired info.

@@@@@@@@@@@@@@@@@@
	   /*
	    *  User choose location data for a dimension.
	    */
	   imagesize(image,&dsize, &dcount, &msize, &mcount,&lsize, &lcount);
	   index = which_band - num_bands;
	   size = lsize/image->location_dim;

/* fid is the propitious file descriptor, skip over map data */
	kfseek(fid, 1024+msize+index*size, FROM_BEGINNING_OF_FILE);
	kfread(data, size, 1, fid);
/* END my code */

      	   assign_data(plot->points, data, plot->size, axis, VFF_TYP_FLOAT);
@@@@@@@@@@@@@@@@@

	hunter

	

Newsgroups: comp.soft-sys.khoros
From: ruprecht@informatik.uni-freiburg.de (Nick Ruprecht)
Subject: Re: vpostscr - how to get multi-output ?
Organization: Institut fuer Informatik der Universitaet Freiburg, Deutschland
Date: Thu, 20 Aug 92 07:39:47 GMT

jogl@merry.imsd.rwth-aachen.de (Joachim Glaubrecht  #Alwd#) writes:

>if we try print a *.xv-image via vpostscr we get ONE A4-paper with 
>the image on it.

>BUT: we now like to get 4 times the SAME image on 4 A4-papers, 
>WITHOUT sending the PostScript-file again to the printer.
>(Sending lasts about 100 min.: 3 MegaByte via 9600 bit/s V24.)

>vpostscr does NOT have a "number of copies" var.

PostScript has a special variable "#copies" to specify the number of
copies to print with "showpage". So,

	/#copies 4 def
	showpage

prints 4 copies of the current page.

From vpostscr, save the output to a file (by setting the "Send to
printer" field to " > file.ps"), add the "/#copies ..." line and print.

IMHO, a "number of copies" field using this variable would be a useful
addition to vpostscr.

Best regards -

--

Nick Ruprecht
Institut fuer Informatik der Universitaet Freiburg
From: uejiowh@dssv01.crd.ge.com
Newsgroups: comp.soft-sys.khoros
Subject: News group
Date: 13 Aug 92 11:53:54 GMT

In the release notes, there is a mention of a news group.  I could not
seem to find it.  Does one exist and should I talk to the system
manager in charge of the news server?

thanks,
Wayne Uejio             General Electric CRD   Disclaimer: opinions 
uejiowh@crd.ge.com      KWC-275                expressed are my own 
Office: 518-387-6441    P.O. Box 8             and not the company's
Fax:    518-387-7080    Schenectady NY 12301   opinion.
From: rasure@sherman.eece.unm.edu (John Rasure)
Newsgroups: comp.soft-sys.khoros
Subject: Re: vencode
Date: 15 Aug 92 03:24:45 GMT


In "vencode", Timothy Williams writes:
+ Just a quick question about vencode ...
+ Part of man page -
+ #################################################################
+ vencode(1)          University of New Mexico           vencode(1)
+      ported by Khoros.
+ #################################################################
+ 
+ Are there any plans on supporting the other encoding schemes?

Well, the "encoding" schemes for Khoros 2.0 are going to be about
the same as 1.0.  Which means none ....  we are hoping that someone
will install a "compression" toolbox on contrib on pprg.

I know of at least one set of compression routines that have been
implemented, but not contributed.  Any one willing to admit that
they have such code?

+ 
+ Just wondering.  
+ -- 
+ Tim Williams                                   COM: (703) 704-1685
+ Night Vision & Electro-Optics Directorate      DSN: 654-1685
+ AMSEL-RD-NV-ISP (Williams)                     FAX: (703) 704-1705
+ Ft. Belvoir, VA 22060-5677                  E-MAIL: williams@nvl.army.mil
End of message from Timothy Williams
Newsgroups: comp.soft-sys.khoros
From: martin@vis.toronto.edu ("Martin C. Martin")
Subject: vclose
Organization: Department of Computer Science, University of Toronto
Date: 13 Aug 92 16:43:54 GMT


A little while ago I asked for an explation of the algorithm for vclose;
I should have explained that this isn't the morphological close operation,
but, according to the man page:

     vclose uses a boundary image and a gradient image as input.
     Then it tries to close the boundaries by following the max-
     imum gradient between two end points of two contours.

It further says:

     This Algorithm has been writen by:

          Professor SERGE CASTAN, Prof CHEN and Dr ZHAO

          IRIT, CNRS, URA 1399

          118, route de Narbonne  31062 Toulouse  FRANCE

If anyone knows how I can contact these people (i.e. their email address),
or any papers written on vclose, I'd like to know.

Thanks again,
Martin.
From: donohoe@jemez.eece.unm.edu
Newsgroups: comp.soft-sys.khoros
Subject: RA Position
Date: 18 Aug 92 14:36:34 GMT


                           RESEARCH ASSISTANT WANTED

Wanted:  Graduate Student,  MS or PhD.

Salary:  $900/mo (half time);  Tuition Paid

Period:  9 months per year,  up to 3 years,  starting Fall  92.

PROJECT DESCRIPTION

Joint project:  Dept. of Electrical and Computer Engineering and Dept.
of Anatomy,  School of Medicine.  Multidisciplinary research to analyse
the vision processes of Musca domestica,  the common housefly.  Study
the physical structure of the eye and brain of the fly.  Stimulate
individual elements of the compound eye,  measure response of
individual neurons.  Construct a mathematical and computer model of the
neural pathways of vision.

JOB DESCRIPTION

Serve as part of the interdisciplinary team studying the vision
mechanism.  Assist in collecting and analyzing electron microscopy
images.  Develop a 3D reconstruction of portions of the nervous
system.

QUALIFICATIONS

Interest in image processing and vision.  Good programming skills.
Some imaging or physics background helpful.  We seek someone who will
be available for two or three years.

CONTACT

Prof.  Greg Donohoe,  EECE Dept.  EECE Bldg,  Rm. 230B Tel:  505-277-6724
email:  donohoe@chama.eece.unm.edu
From: andy@cyclone.jpl.nasa.gov (Andy Pursch)
Newsgroups: comp.soft-sys.khoros
Subject: Re: Self-describing files
Date: 20 Aug 92 22:35:23 GMT


We also have worked with self-describing files, however we have chosen the
Hierarchical Data format (HDF) developed by the National Center for Super-
computing Applications (NCSA) at the University of Illinois as a 'standard'
for our research. (see Frank Hayes, "The Data Problem", Supplement to 
UNIXworld: Special Report on Connectivity 1990, pp 49-53, 1990). HDF and 
netCDF provide much more than just the 'self-describing' feature of the data
sets. I think it would be worth the effort to pursue the development of both
HDFtoviff as well as netCDFtoviff conversion routines. For anyone involved
in weather and climate research pertaining to NASA's Earth Observing System 
(EOS) or hoping to be involved in it in the future, you may want to encourage
this type of development. HDF has been recommended as the 'standard' file 
format to distribute the atmospheric data sets being produced by EOS. There
is also work being done by NCSA to provide a netCDF to HDF interface. NCSA
has always been very helpful so if you want more info, contact them through
anonymous ftp at 141.142.20.50.


Andy Pursch
Weather and Climate Group
Atmospheric and Oceanographic Sciences Section
Jet Propulsion Lab
MS 183-901
4800 Oak Grove Drive
Pasadena, Ca. 91109

andy@cyclone.jpl.nasa.gov
From: rasure@borris.eece.unm.edu (John Rasure)
Newsgroups: comp.soft-sys.khoros
Subject: Re: converting floats on i386 to Sparc
Date: 14 Aug 92 16:24:03 GMT


In "converting floats on i386 to Sparc", Robert M. Cothren writes:
+ I am trying to convert a binary data file created on an Intel 386
+ running DOS to a VIFF file for use on a Sparc.  The internal
+ representation of the data when written is float (4-byte).  I am sure
+ that the proper conversion routines exist, but I know nothing about
+ internal float representation, and therefore am confused.
+ 
+ It would appear that Sparc is VFF_DEP_IEEEORDER.  I know that for
+ shorts and longs, i386 is the same as VAX, which would appear to be
+ VFF_DEP_DECORDER.  dectoieees() and dectoieeel() work for items in the
+ header of the data file.  However, I have no idea what VFF_DEP_NSORDER
+ is, and have been unsuccessful converting anything but short and long
+ ints.

I am curious why you can't just use raw2viff to figure it all out?

+ 
+ Any help?
+ 
+ ----Robert M. Cothren, PhD--------------------------rim@bme.ri.ccf.org----
+     Biomed. Engineering and Applied Therapeutics   
+     The Cleveland Clinic Foundation                voice: 216 445-9305
+ ----Cleveland, Ohio----------------------------------fax: 216 444-9198----
End of message from Robert M. Cothren
From: sjreeves@eng.auburn.edu (Stan Reeves)
Newsgroups: comp.soft-sys.khoros
Subject: Re: Khoros 2.0 viff structure
Date: 14 Aug 92 14:44:39 GMT
Organization: Auburn University Engineering

In article <39706@pprg.eece.unm.edu.pprg.unm.edu> storhaug@ndre.no (Geir Atle Storhaug) writes:
>The main items on my wishlist are:
>
>[Interesting suggestions deleted]
>
> - An (optional) automatic history recording in the viff headers. The idea
>   is that an image should remember its origin and all operations which has
>   been performed on the image.

I'm not sure if a comment field is envisioned here, but I would like to put
in my two-cents' worth for that.  One of the main drawbacks for me to switch
over to Khoros right now is the fact that viff (apparently) does not have a
variable-length comment field.  Two fields -- a length specifier and a string
of characters -- is all that's required to do this.  This capability is 
indispensable for those of us doing research in image processing.  It's just
too much of a pain to keep up with all the details of what's been done to
an image.  A comment field can be edited by hand or updated automatically 
by a program.  It definitely makes life easier in terms of documentation.


--
Stan Reeves
Auburn University, Department of Electrical Engineering, Auburn, AL  36849
INTERNET: sjreeves@eng.auburn.edu
From: Peter.Averkamp@e20.physik.tu-muenchen.de (Peter Averkamp)
Newsgroups: comp.soft-sys.khoros
Subject: Re: xwdtoviff
Date: 18 Aug 92 12:49:12 GMT


James M Missler (missler@cse.uta.edu) writes:

> Does anyone have a program to convert xwd image files to
> VIFF image files? I know from FAQ 21 explains using getimage --
> I'd like a program that does this with xwd input and VIFF output.
>                                         - Mike Missler

Get the pbmplus toolkit from your favourite archive server,
e.g. ftp.uu.net and use:

   'xwdtopnm <yourfile.xwd> | pbm2viff -i - -o <yourfile.viff>'

viff2pbm and pnmtoxwd get you in the opposite direction.


Peter Averkamp,                      | email:
Physics Department E20               | petav@radon.e20.physik.tu-muenchen.de
Techn. Univ. of Munich               | Phone: ++49 (89) 3209-2408
D-8046 Garching, Germany             | Fax:   ++49 (89) 3209-2338
From: rasure@sherman.eece.unm.edu (John Rasure)
Newsgroups: comp.soft-sys.khoros
Subject: A reminder on re-posting.
Date: 15 Aug 92 03:28:53 GMT

If you have a question that has been posted, but did not get an answer to,
please put "REPOST" in the subject line, and mail or post it again.

Thanks.

p.s.  There is a news group called sci.image.processing that you might want
to watch to get advice on image processing.
From: rouilj@dl5000.bc.edu (John P. Rouillard)
Newsgroups: comp.soft-sys.khoros
Subject: Re: Source Code Modification -- FOLLOW UP
Date: 21 Aug 92 00:22:34 GMT
Article-I.D.: dl5000.ROUILJ.92Aug20192234
Organization: Institute for Space Research, Boston College


Well, I checked KHOROS into cvs as soon as I got it. Any changes that
I make will be stored in the cvs repository. If any patches are given
out by the KHOROS maintainers, I just have to check out a copy of
khoros at version 1.5, apply my patches, and then use cvs to help
perform the merge between their patches and my patches. Then I
reconcile them, and check a new version of the source back into cvs.

I have used this method with other software packages of similar size
to khoros (X11R5) and it has worked well.

-- John
From: jadkins@iceberg..mps.ohio-state.edu (Jeff Adkins)
Newsgroups: comp.soft-sys.khoros
Subject: rawtoviff really big files.
Date: 20 Aug 1992 21:00:44 GMT
Organization: Byrd Polar Research Center
Distribution: world
NNTP-Posting-Host: iceberg.mps.ohio-state.edu


We are trying to convert large files (approx. 132M  8000x8192 pixels) from a raw format to viff.  The problem that we are experencing is that is seems that rawtoviff trys to malloc 14M.  For some reason it is unsucessfull.  We have tried increaseing the swap space to 132M, but to no avail.  

  Any help or suggestions would be appresiated.


Jeff Adkins, Byrd Polar Research Center
jadkins@iceberg.mps.ohio-state.edu