IDL Local Documentation

This page was created by the IDL library routine mk_html_help. For more information on this routine, refer to the IDL Online Help Navigator or type:

     ? mk_html_help

at the IDL command line prompt.

Last modified: Wed Jan 05 11:45:42 2000.


List of Routines


Routine Descriptions

ANALYZE[1]

[Next Routine] [List of Routines]
 NAME: 
       ANALYZE 
 
 PURPOSE: 
       This is the main procedure for analyzing optical imaging data. 
       It performs the analysis as described in the scriptfile  
		(usually called 'analyze.run_number')

	This program has now been modified so that it works on BOTH
	the old-style OPTREC files and the new-style ORA/OI files.
	The output files are ALWAYS in the old OPTREC-style format,
	and are therefore suitable for our normal Unix OIPP, OIDP and
	other analysis programs.  We will get PC versions of the OIPP 
	OIDP programs that accept the old header styles running soon.

	In the unlikely event that you need to convert the output files 
	to the new ORA/OI format, use ORA2OI

 CATEGORY: 
       Optical imaging analysis 
 
 CALLING SEQUENCE: 
 
       ANALYZE,Script_file_name 
 
 INPUTS: 
       Script_file_name:       This string contains the name of the 
                               script-file that describes which kind of  
                               processing is to be done. An example for 
                               script-file can be found at the end of  
                               this help 
 
 KEYWORD PARAMETERS: 
       NOVERBOSE:              Determines whether the analysis is done 
                               quietly or whether progress is reported. 
                               Default is VERBOSE. 
       REMAIN:                 Causes the program not to exit but to 
                               remain within the environment, giving 
                               access to all the variables. 
                               Default is NOREMAIN 
       NOCALC:                 If this keyword is set all operations  
                               except for the calculations proper are 
                               performed. This is sometimes useful 
                               for script testing. 
                               Default is CALC. 
       NO_DLL:                 If this keyword is set the Windows DLL  
                               will not be called. This is useful if 
                               the DLL is not installed in the Windows directory. 
                               Default is DLL. 
 
       PLUS==>                 Many of the paramters which are accepted in the input 
                               file can also be supplied as commandline keywords. 
                               In this case the commandline option superseeds the 
                               choice in the input file. All paramters which can be  
                               as a commandline option are marked with and <== below 
; 
 OUTPUTS: 
       None, really. 
       But running this procedure with the keyword /REMAIN will cause the program to remain 
       within the environment. This gives access to all the variables in the main program. 
       Notably a float-array called Main_data. Which contains the data of the inputfile(s),  
       summated over frames and blocks. 
 
 COMMON BLOCKS: 
       GLOBAL_ANA_VARS:        which contains lots of variables which are  
                               necessary for the data-analysis 
       GLOBAL_SWITCH:          contains the two values for verbose and calc 
 
 SIDE EFFECTS: 
       Produces the files (described in the scripts file) in the directories 
       (described in the script-file). 
       An elaborate header is generated which provides all kinds of information 
       about who recorded the data, who processed them, when, what kind of 
       processing was applied to the data etc. 
 
 PROCEDURE: 
       This is a longer story. Who uses the program will know, hopefully... 
 
 EXAMPLE:     
       By issuing the command: 
 
       ANALYZE,'d:\or\inp\analyze.inp',file_prefix='sum.3' 
        
       one causes the calculations described in 'd:\or\inp\analyze.inp' to be 
       performed on the input-file 'sum.3'. 
       Furthermore the files speicfied in 'd:\or\inp\analyze.inp'  
       are produced in the appropriate directory. 
 
 OTHER GENERAL CONSIDERATIONS 
 
       - Although the sum-files have a structure which is 
       main_data=intarr(nconds,nframes,y_size,x_size) 
       this is turned around in the image-files. 
       The format of the image files is fltarr(x_size,y_size) 
       This seems the more natural way to save things and 
       one should hardly loose time by saving things like that 
 
       - The division by zero problem is handled by adding 0.000000000001 
       to the main_data array before doing anything. This is slightly ugly 
       since it means that blank and cocktail_blank are different in this 
       respect. But it really doesn't matter 
 
 KNOWN BUGS  
 
 The formatting of the verbose output is not very nice yet.  
 TB 
 
 MODIFICATION HISTORY: 
       Written by:     Tobias Bonhoeffer, February 1993 
       August, 1994    Added the possiblity to define other variables 
                       in addition to blank and cocktail_blank 
       March, 1995     Tobias Bonhoeffer: 
                       - Added call to Windows-DLL to speed up conversion 
                         from unsigned int to float. This works only for MSWindows 
                         and for frames that are smaller than 32K. This condition 
                         is automatically detected. 
                       - Added KEYWORD /NO_DLL. Forces DLL not to be called. 
                       - Added possiblity to give most options as command-line values                   
                       - Added possibility to clip only on part of the picture 
       August, 1995    Tobias Bonhoeffer:
			Minor modifications to confomr with new Windows NT filename conventions 
 
SAMPLE INPUT FILE: 
_____________________________________________________________________________ 
 
 
#COMMENTARY 
 
INPUT_DIRECTORY:       d:\data\or\data\072390\         ;<== (can be given as command line option) 
OUTPUT_DIRECTORY:      d:\data\or\tmp\                 ;<== 
 
FILE_PREFIX:           s_082390.3                      ;<== 
 
FILE_SUFFIXES:         a b c d e f g h                 ;<== 
FRAMES:                1 4 5                           ;<== 
 
#CLIPPING VALUES IN PERCENT 
LO_CLIP:               1.5                             ;<==     
HI_CLIP:               1.5                             ;<== 

#WINDOW ON WHICH THE CLIPPING IS TO BE DONE, IF NO WINDOW IS SPECIFIED THE WHOLE IMAGE IS TAKEN 
CLIP_WINDOW_X0:        0 
CLIP_WINDOW_Y0:        0 
CLIP_WINDOW_XSIZE:     191 
CLIP_WINDOW_YSIZE:     143 

# M stands for MAIN_DATA pure number is a scalar value 
BLANK:                 M16                             ;<== 
COCKTAIL_BLANK:        (M0+M1+M2+M3+M8+M9+M10+M11)/8   ;<== 
REFERENCE_FRAME:       0                               ;<== 
 
#DIVIDE ALL CONDITIONS BY BLANK, COCKTAIL_BLANK OR REFERENCE_FRAME 
 
MODE:                  COCKTAIL_BLANK BLANK REFERENCE_FRAME    ;<== 
 
#CALCULATE THE SINGLE CONDITIONS OR SKIP THESE CALCULATIONS 
 
SINGLE_CONDITIONS:     YES                                     ;<== 
 
#SPECIAL DEFINITIONS    
 
DEFINITION:            LEFT_BLANK=(M0+M1+M2+M3+M8+M9+M10+M11)/8 
 
#SPECIAL CALCULATIONS  ALGORITHM                       NAME (6chars the rest will be filled in by 
#                                                            the program) 
#cocktail_blank and blank are special expressions, defined above 
 
CALC_SPECIAL:          (M0+M1+M2+M3)/(4*COCKTAIL_BLANK)        L_____ 
CALC_SPECIAL:          (M4+M5+M6+M7)/(4*BLANK)                 R_____ 
 
__________________________________________________________________________ 

(See c:\idl_loc\lib\or_pros\analyze\analyze.pro)


ANALYZE[2]

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	ANALYZE

 PURPOSE:
	This is the main procedure for analyzing optical imaging data.
	It performs the analysis as described in the scriptfile 

 CATEGORY:
	Optical imaging analysis

 CALLING SEQUENCE:

	ANALYZE,Sum_file_prefix,Script_file_name

 INPUTS:
	Sum_file_prefix:	This string describes the Sum_files on
			        which the analysis should be performed
			        NOTE: The filename is given without
			        the directory which is specified in 
			        the script-file
	Script_file_name:	This string contains the name of the
			        script-file that describes which kind of 
			        processing is to be done. An example for
			        script-file can be found at the end of 
			        this help

 KEYWORD PARAMETERS:
	NOVERBOSE:		Determines whether the analysis is done
				quietly or whether progress is reported.
				Default is VERBOSE.
	REMAIN:			Causes the program not to exit but to
				remain within the environment, giving
				access to all the variables.
				Default is NOREMAIN
	NOCALC:			If this keyword is set all operations 
				except for the calculations proper are
				performed. This is sometimes useful
				for script testing.
				Default is CALC.

 OUTPUTS:
	None, really.
	But running this procedure with the keyword /REMAIN will cause the program to remain
	within the environment. This gives access to all the variables in the main program.
	Notably a float-array called Main_data. Which contains the data of the inputfile(s), 
	summated over frames and blocks.

 COMMON BLOCKS:
	GLOBAL_ANA_VARS:	which contains lots of variables which are 
				necessary for the data-analysis
	GLOBAL_SWITCH:		contains the values from the different external inputs

 SIDE EFFECTS:
	Produces the files (described in the scripts file) in the directories
	(described in the script-file).
	An elaborate header is generated which provides all kinds of information
	about who recorded the data, who processed them, when, what kind of
	processing was applied to the data etc.

 PROCEDURE:
	This is a longer story. Who uses the program will know, hopefully...

 EXAMPLE:    
       By issuing the command:

	ANALYZE,'sum.3','d:\or\inp\analyze.inp'
	
	one causes the calculations described in 'd:\or\inp\analyze.inp' to be
	performed on the input-file 'sum.3'.
	Furthermore the files speicfied in 'd:\or\inp\analyze.inp' 
	are produced in the appropriate directory.

 OTHER GENERAL CONSIDERATIONS

       - Although the sum-files have a structure which is
	main_data=intarr(nconds,nframes,y_size,x_size)
	this is turned around in the image-files.
	The format of the image files is fltarr(x_size,y_size)
	This seems the more natural way to save things and
	one should hardly loose time by saving things like that

       - The division by zero problem is handled by adding 0.000000000001
	to the main_data array before doing anything. This is slightly ugly
	since it means that blank and cocktail_blank are different in this
	respect. But it really doesn't matter

 KNOWN BUGS 

 The formatting of the verbose output is not very nice yet. 
 TB

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, February 1993
	August, 1994    Added the possiblity to define other variables
			in addition to blank and cocktail_blank
			

SAMPLE INPUT FILE:
_____________________________________________________________________________


#COMMENTARY

INPUT_DIRECTORY:	d:\data\or\data\072390\
OUTPUT_DIRECTORY:	d:\data\or\tmp\

FILE_SUFFIXES:		a b c d e f g h
FRAMES:		1 4 5

#CLIPPING VALUES IN PERCENT
LO_CLIP:		1.5		
HI_CLIP:		1.5		

# M stands for MAIN_DATA pure number is a scalar value
BLANK:			M16				
COCKTAIL_BLANK:	(M0+M1+M2+M3+M8+M9+M10+M11)/8
REFERENCE_FRAME:	0

#DIVIDE ALL CONDITIONS BY BLANK, COCKTAIL_BLANK OR REFERENCE_FRAME

MODE:			COCKTAIL_BLANK BLANK REFERENCE_FRAME

#CALCULATE THE SINGLE CONDITIONS OR SKIP THESE CALCULATIONS

SINGLE_CONDITIONS:	YES

#SPECIAL DEFINITIONS	

DEFINITION:		LEFT_BLANK=(M0+M1+M2+M3+M8+M9+M10+M11)/8

#SPECIAL CALCULATIONS	ALGORITHM			NAME (6chars the rest will be filled in by
#							      the program)
#cocktail_blank and blank are special expressions, defined above

CALC_SPECIAL:		(M0+M1+M2+M3)/(4*COCKTAIL_BLANK)	L_____
CALC_SPECIAL:		(M4+M5+M6+M7)/(4*BLANK)			R_____

__________________________________________________________________________

(See c:\idl_loc\lib\or_pros\analyze\oldanalyze.pro)


ASCII_RD

[Previous Routine] [Next Routine] [List of Routines]
 NAME:   
       ASCII_RD   
   
 PURPOSE:   
       This function reads a table of numbers from the given ASCII-file   
       into a float array with dimension N*M.   
       N is the number of columns and M the number of rows.   
       The number of elements in a row (N) is computed by analyzing the   
       first line in the table file !   
       Then all rows are read and the numbers converted to floats until   
       EOF is reached. The function returns the table as a 2 dim. float array.   
   
 CATEGORY:   
       Muc_pros, Read, ASCII   
   
 CALLING SEQUENCE:   
    
       Result = Ascii_rd(Filename, ROWS=r, COLS=c)   
   
 INPUTS:   
       Filename:       String, giving full path for the ASCII file to read   
          
 OUTPUTS:   
       Returns a float array, containing the values from the ASCII file   
          
       With the optional keywords ROWS and COLS you can receive the dimensions   
       of the returned float array.   
   
 RESTRICTIONS:   
       All rows from the first to the last must have the same count of numbers !   
   
 EXAMPLE:   
       table= Ascii_rd('c:\temp\table.txt', ROWS=r, COLS=c)   
  
       or more tricky:  
  
       table= Ascii_rd(Pickfile())   
   
 MODIFICATION HISTORY:   
       Written by:     Gerhard Braendle, Jan 1994   
       27.01.94        Added comment to header and better IO-error handling. GB  

(See c:\idl_loc\lib\or_pros\ascii_rd.pro)


BINSUMFILE

[Previous Routine] [Next Routine] [List of Routines]
NAME:
  binsumfile

PURPOSE:
  This procedure bins an optrec or ORA/OI sumfile spatially and temporally.  
  That is, it replaces the value of each pixel in each frame with the
  average of binspace*binspace surrounding pixels , and it can replace
  each frame with the average of bintime frames.  

  The reason for this program is to save disk space by allowing us to
  collect much more real data and then to average to reduce noise.  It
  also allows us to compare data from different experiments that was taken
  or saved with different spatial and temporal resolution.

  It works with reasonable defaults if the keyword parameters are missing

CATEGORY:
  image compression

CALLING SEQUENCE:
  binsumfile, [filename=filename,] [BINSPACE=binspace,] [BINTIME=bintime,] $
    [OUTFILE_NAME=outfile_name,] [/REPLACE]

INPUTS:
  none

KEYWORD PARAMETERS:
  FILENAME=filename -- name of the input sumfile.  If absent, invokes pickfile
  BINSPACE=binspace -- spatial binning (always equal in x and y), default 2
  BINTIME=bintime -- temporal binning, default 2
  OUTFILE_NAME=outfile_name -- allows you to specify a name for the output file
    defaults to the name of the input file + 'b'
  /REPLACE -- allows you to have the output file overwrite the input file.
    defaults to no replacement.

OUTPUTS:
  a shorter sumfile

RESTRICTIONS:
  This only works for values of spatial and temporal binning that EXACTLY
  divide the dimensions of the input sumfile.

EXAMPLES:
  binsumfile, filename = 's_121797.6b', bintime=4 

 MODIFICATION HISTORY:
 	Written by:	  Michael Stryker, 28 Dec 97

(See c:\idl_loc\lib\sfo_pros\binsumfile.pro)


BIT_CODE

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	BIT_CODE

 PURPOSE:
	This function receives an array with numbers and returns a long integer which
       contains the bit coded pattern

 CATEGORY:
	Muc_pros

 CALLING SEQUENCE:
 
	Result = FUNCTION_NAME(In_array)

 INPUTS:
	In_array:	Array containing the positions of the bits that should be set
	
 OUTPUTS:
	This function returns a long integer in which the bits specified in the 
	in_array are set.

 RESTRICTIONS:
	No numbers ge 31 will be bit_coded in order to avoid mess with unsigned or 
	signed longs

 EXAMPLE:
	Result=bit_code([1,3,5])
	
	2^1+2^3+2^5=42 is returned.


 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, May 1993
	July 1994	

(See c:\idl_loc\lib\or_pros\bit_code.pro)


BOXCAR_SMOOTH

[Previous Routine] [Next Routine] [List of Routines]
 boxcar_smooth
 works, but does not yet do proper input

(See c:\idl_loc\lib\anal_tools\boxcar_smooth.pro)


CBI

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	CBI

 PURPOSE:
	Computes the optical contralateral bias index (CBI)
      of an analyzed orientation map.
   Can handle 4 or 8 orientations; old or new filenaming conventions.

 CATEGORY:
	Analysis routine.

 CALLING SEQUENCE:
	CBI, Local_smoothing_width, High_pass_width, Number_of_orients

 INPUTS:
	Local_smoothing_width: This is the (half) width of the smoothing filter in pixels.
           An odd integer number should be used, if not 1 will be added to the number.
			A typical value is 3. Note this variable is called hp_width!
	High_pass_width: This is the (half) width of high pass filter in pixels.
			A typical value is around 70. Note this variable is called lp_width!
	Number_of_orients: Number of orientations, should be 4 or 8.

 KEYWORD PARAMETERS:
	NAME: Name of a file to use for the calculation. This can be any one of the orientations
         for either eye. This will be used for drawing the template too.
	TEMPLATE_FILENAME:Name of a template file to use for this calcualtion.
	PS_TITLE: Name of file to put postscript output in. Should include entire path.
				If not specified, then a default title caled 'CBI.PS' will be assumed,
				with the path the same as that of the data. It is assumed that no '.PS'
               is part of PS_TITLE.

 OUTPUTS:
	This program has lots of outputs, they include two postscript files with the histogram
		They are called 'PS_TITLE_CB.PS' for the cocktail blank data and
		'PS_TITLE_BB.PS' for the blank-blank data. The default value of
		'PS_TITLE' is 'CBI'.

 SIDE EFFECTS:
	Might be many. Not sure.
	Updates analysis_config.user.

 RESTRICTIONS:
	There should be a file called 'analysis_config.user' in the idl directory.
		This program uses that file to keep a record of the latest directory used
       for analysis, and possibly other configuration information.
	Calls a number of other home-built functions, including:
				get_ofiles
				old_or_new
				get_template
				path_from_name
				notemplate_smooth
		and maybe others too.

 This code works fine if there is a well-tuned response in either (or both) eyes.
 It fails to do the right thing in cases in which both eyes give a significant repsonse
 above the blank but neither eye is tuned for the parameter that is varied (usually orientation).
 What we should do about this problem is to use the usually-4 blank stimuli in the computation
 of the scalefactor_forthispixel [now = .01/(peak-min)], so that the min under consideration
 becomes the min of the Stimulus-parameter X 2 Eyes analyze files PLUS usually-4 additional analyze
 files computed in the same way from the individual blank conditions.  This will, of course, be impossible
 if there are only cocktail-blanks and no actual blank stimulus conditions.

 If you have actual blank stimulus conditions, you can estimate "noise" from the variation among
 the blanks.  Then it would be wise to clip scalefactor_forthispixel to .01/noise, so that in cases
 where the is no response in any stimulus condition, the huge scalefactor does not artifactually inflate
 the CBIs and MIs.

 PROCEDURE:
	This is the foobar superfloatation method.

 EXAMPLE:

 	To run, input '@XCBI' at the idl prompt and follow instructions.

   The prefix and suffix will be taken from the file chosen
		 	to define the region of iterest.

 MODIFICATION HISTORY:
 	Written by:	MC Crair, 05/96.
	Jan 98  Modify to work in IDL 5.0, on the PC and Unix workstations.
			Works with new and old filename conventions.
           Uses widget to define directory and file to use for defining region
           	of interes.
		    Should now be insensitive to image size, but this is not tested.
           Output of files should be to the same directory as where input came from.
			Uses a SAVE and RESTORE routine from a file called analysis_config.user
				to save last file name and directory used.

(See c:\idl_loc\lib\anal_tools\new_but_untested\cbi.pro)


CBI_DIST

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	CBI_DIST

 PURPOSE:
	Computes the optical contralateral bias index (CBI) as a function of distance
		from a user defined point (like a cannulae).
   Can handle 4 or 8 orientations; old or new filenaming conventions.

 CATEGORY:
	Analysis routine.

 CALLING SEQUENCE:
	CBI_DIST, Local_smoothing_width, High_pass_width, Number_of_orients

 INPUTS:
	Local_smoothing_width: This is the (half) width of the smoothing filter in pixels.
           An odd integer number should be used, if not 1 will be added to the number.
			A typical value is 3. Note this variable is called hp_width!
	High_pass_width: This is the (half) width of high pass filter in pixels.
			A typical value is around 70. Note this variable is called lp_width!
	Number_of_orients: Number of orientations, should be 4 or 8.

 KEYWORD PARAMETERS:
	NAME: Name of a file to use for the calculation. This can be any one of the orientations
         for either eye. This will be used for drawing the template too.
	TEMPLATE_FILENAME:Name of a template file to use for this calcualtion.
	PS_TITLE: Name of file to put postscript output in. Should include entire path.
				If not specified, then a default title caled 'CBI.PS' will be assumed,
				with the path the same as that of the data. It is assumed that no '.PS'
               is part of PS_TITLE.
	BIN_SIZE: Number of pixels used to calculate CBI for a given distance from cannula.
				Default value is 30. If you specify a larger number, then you will get
				fewer points in your CBI vs. DISTANCE plot.
	OUTPUT:  If set true, then output will be made to txt and PS files without prompting.

 OUTPUTS:
	This program has lots of outputs, they include two postscript files with the histogram
		They are called 'PS_TITLE_CB.PS' for the cocktail blank data and
		'PS_TITLE_BB.PS' for the blank-blank data. The default value of
		'PS_TITLE' is 'CBI'.

 SIDE EFFECTS:
	Might be many. Not sure.
	Updates analysis_config.user.

 RESTRICTIONS:
	There should be a file called 'analysis_config.user' in the idl directory.
		This program uses that file to keep a record of the latest directory used
       for analysis, and possibly other configuration information.
	Calls a number of other home-built functions, including:
				get_ofiles
				old_or_new
				get_template
				path_from_name
				notemplate_smooth
		and maybe others too.

 PROCEDURE:
	This is the foobar superfloatation method.

 EXAMPLE:

 	To run, input '@XCBI_DIST' at the idl prompt and follow instructions.

   The prefix and suffix will be taken from the file chosen
		 	to define the region of iterest.

 MODIFICATION HISTORY:
 	Written by:	MC Crair, 05/96.
	Jan 98  Modify to work in IDL 5.0, on the PC and Unix workstations.
			Works with new and old filename conventions.
           Uses widget to define directory and file to use for defining region
           	of interes.
		    Should now be insensitive to image size, but this is not tested.
           Output of files should be to the same directory as where input came from.
			Uses a SAVE and RESTORE routine from a file called analysis_config.user
				to save last file name and directory used.
			This program is very similar to OTI, but has added calculation of CBI
               as a function of distance from the user defined point.

(See c:\idl_loc\lib\anal_tools\new_but_untested\cbi_dist.pro)


CBI_DIST_NZR

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	CBI_DIST_NZR

 PURPOSE:
	Computes the optical contralateral bias index (CBI) as a function of distance
		from a user defined point (like a cannulae).
   Can handle 4 or 8 orientations; old or new filenaming conventions.

 CATEGORY:
	Analysis routine.

 CALLING SEQUENCE:
	CBI_DIST_NZR, Local_smoothing_width, High_pass_width, Number_of_orients

 INPUTS:
	Local_smoothing_width: This is the (half) width of the smoothing filter in pixels.
           An odd integer number should be used, if not 1 will be added to the number.
			A typical value is 3. Note this variable is called hp_width!
	High_pass_width: This is the (half) width of high pass filter in pixels.
			A typical value is around 70. Note this variable is called lp_width!
	Number_of_orients: Number of orientations, should be 4 or 8.

 KEYWORD PARAMETERS:
	NAME: Name of a file to use for the calculation. This can be any one of the orientations
         for either eye. This will be used for drawing the template too.
	TEMPLATE_FILENAME:Name of a template file to use for this calcualtion.
	PS_TITLE: Name of file to put postscript output in. Should include entire path.
				If not specified, then a default title caled 'CBI.PS' will be assumed,
				with the path the same as that of the data. It is assumed that no '.PS'
               is part of PS_TITLE.
	BIN_SIZE: Number of pixels used to calculate CBI for a given distance from cannula.
				Default value is 30. If you specify a larger number, then you will get
				fewer points in your CBI vs. DISTANCE plot.
	OUTPUT:  If set true, then output will be made to txt and PS files without prompting.

 OUTPUTS:
	This program has lots of outputs, they include two postscript files with the histogram
		They are called 'PS_TITLE_CB.PS' for the cocktail blank data and
		'PS_TITLE_BB.PS' for the blank-blank data. The default value of
		'PS_TITLE' is 'CBI'.

 SIDE EFFECTS:
	Might be many. Not sure.
	Updates analysis_config.user.

 RESTRICTIONS:
	There should be a file called 'analysis_config.user' in the idl directory.
		This program uses that file to keep a record of the latest directory used
       for analysis, and possibly other configuration information.
	Calls a number of other home-built functions, including:
				get_ofiles
				old_or_new
				get_template
				path_from_name
				notemplate_smooth
		and maybe others too.

 PROCEDURE:
	This is the foobar superfloatation method.

 EXAMPLE:

 	To run, input '@CBI_DIST_NZR' at the idl prompt and follow instructions.

   The prefix and suffix will be taken from the file chosen
		 	to define the region of iterest.

 MODIFICATION HISTORY:
 	Written by:	MC Crair, 05/96.
	Jan 98  Modify to work in IDL 5.0, on the PC and Unix workstations.
			Works with new and old filename conventions.
           Uses widget to define directory and file to use for defining region
           	of interes.
		    Should now be insensitive to image size, but this is not tested.
           Output of files should be to the same directory as where input came from.
			Uses a SAVE and RESTORE routine from a file called analysis_config.user
				to save last file name and directory used.
			This program is very similar to OTI, but has added calculation of CBI
               as a function of distance from the user defined point.

(See c:\idl_loc\lib\anal_tools\new_but_untested\cbi_dist_nzr.pro)


CC_OIHDR

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	CC_OIHDR

 PURPOSE:
	This function checks by scanning the headers whether two files are
	compatible for summing them. It produces a message which describes the incompatibility.
	The following header entries are tested for identity:
	lFileSize, lLenHeader, lVersionID, lFileType, lFileSubtype,lDataType,lFrameWidth, lFrameHeight, lNFramesPerStim, lNStimuli

 CATEGORY:
	OI header functions

 CALLING SEQUENCE:

	ok = CC_OIHDR(header1, header2)

 INPUTS:
	header1:	A OI data file header
	header2:	Another OI data file header


 OUTPUTS:
	Nothing. A 0 is returned if the headers are compatibel, else 1.

 EXAMPLE:

	Issuing the command 

	ok = cc_oihdr(h1, h2)

	sets variable 'ok' to 0 if both headers (h1 and h2) are compatibel.
	If the headers are incompatibel, an error message is printed and a 
	1 is returned.
	
 MODIFICATION HISTORY:
 	Written by:	Gerhard Braendle, August 1996.

(See c:\idl_loc\lib\oi_general\cc_oihdr.pro)


CHECKDIR

[Previous Routine] [Next Routine] [List of Routines]
 NAME:   
       CHECKDIR  
  
 PURPOSE:  
       This function returns the validated directory name if existing, (trailing \ and / are 
       removed) else an empty string is returned.  
       Useful with PICKFILE, that crashes with invalid dirs.  
       PICKFILE will use the current directory, if the keyword PATH='' !  
  
 CATEGORY:  
       DOS, FILE-SYSTEM  
  
 CALLING SEQUENCE:  
       Dirname_valid = CHECKDIR(Dirname)  
  
 INPUTS:  
       Dirname:        String (e.g. 'c:\temp')  
  
 OUTPUTS:  
       This function returns the original Dirname if existing, else '' is returned !  
  
 RESTRICTIONS:  
       May works with DOS filing sytem only (tricky: Checking 'NUL' file in dir) !  
  
 EXAMPLE:  
  
       dir = 'c:\temp'  
       dir = CHECKDIR(dir)  
  
       The string dir contains 'c:\temp' if the directory existed, else dir='' !  
  
  
 MODIFICATION HISTORY:  
       Written by:     Gerhard Brändle, 25.02.94  
       July 26, 94     Strips / or \ at the end of dir2check before testing directory.  GB
  

(See c:\idl_loc\lib\or_pros\checkdir.pro)


CHK_HEAD

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
       CHK_HEAD

 PURPOSE:
       This procedure checks by scanning the headers whether two files are
       compatible for summing them. It produces a Message (used for error
       checking in IDL) which describes the incompatibility

 CATEGORY:
       Header functions

 CALLING SEQUENCE:

       CHK_HEAD, Header1, Header2

 INPUTS:
       Header1:        A structure which contains the header information for file1
       Header2:        A structure which contains the header information for file1
                       NOTE: These structures must have the correct format

 OUTPUTS:
       None

 SIDE EFFECTS:
       MESSAGES are generated which report the errors

 RESTRICTIONS:
       No checking of the correct format of the structures Header1 and Header2 is done

 EXAMPLE:

       The headers of two files are checked for compatibility by issuing the command

       CHK_HEAD, Header1, Header2

 MODIFICATION HISTORY:
       Written by:     Tobias Bonhoeffer, April 1993.
       July, 1994      Any additional modifictaions are get described here.

(See c:\idl_loc\lib\or_pros\chk_head.pro)


COMPUTE_CC

[Previous Routine] [Next Routine] [List of Routines]
NAME:    compute_cc

PURPOSE: Compute the cross-correlation between two angle maps in tif format
         This code was used for 'similarity index' between orientation maps
             made through the two eyes in Crair et al 1998 Science paper.  
             It is derived from the code written by Stryker and Bonhoeffer 
             for the Chapman et al orientation development paper.
 
          If the two maps are made on different days or with variable
             alignment, then it is wise to expand 'size' to some value greater 
             than 1.  This is not necessary with the two maps made in an
             interleaved run.


CALLING SEQUENCE:
         First execute the prefile with the command @pre_corr
         Then compute_cc,filename,reference_filename

CALLS:   ang_cc_roi.pro
         ang_corr.pro

CONTROL: The 'flip' versions of all these routines compute the identical 
            functions on maps after a 180-deg rotation.  This is an appropriate
            control, on average, for the correlation imposed at random

AUTHOR:  Mike Crair and Michael Stryker, 1997

(See c:\idl_loc\lib\anal_tools\crosscorrelate\compute_cc.pro)


CONCAT

[Previous Routine] [Next Routine] [List of Routines]
 NAME:	
	CONCAT

 PURPOSE:
		Removes headers from *.spe files and concatenates remaining data
		into output file.

 CATEGORY:
	Special purpouse utility

 CALLING SEQUENCE:
	CONCAT, Filepattern, Outfilename

 INPUTS:
	Filepattern: 	String (e.g. 'R:\IDL\IMAGES\OR\ABC*.SPE')

	Outfilename:	String (e.g. 'R:\IDL\IMAGES\OR\out1.dat')


 EXAMPLE: CONCAT, 'R:\idl\images\or\*.spe', 'r:\idl\images\or\out.dat'


 MODIFICATION HISTORY:
 	Written by:	Gerhard Brändle, 21.09.93
	Month, Year	Any additional mods get described here.  

(See c:\idl_loc\lib\or_pros\concat.pro)


DOCUMENT -- TEMPLATE FILE FOR ADDING DOCUMENTATION

[Previous Routine] [Next Routine] [List of Routines]
NAME: 
  document -- template file for adding documentation

URPOSE:
  DOCUMENT is a template file for adding documentation to our IDL programs

  This file is located in /net/faure/idl_loc/sfo_pros/document.pro
  Please copy it at the beginning of any program that you will use
  more than once, and edit it appropriately.

  This is an example of a purpose:
  This procedure reads either the old optrec or the new 
  OI/ORA headers and always returns an old-format header

CATEGORY:
  conversions

CALLING SEQUENCE:
  document  (nothing)

INPUTS:
  nothing:	A string which contains nothing

KEYWORD PARAMETERS:
  none

OUTPUTS:
  something

SIDE-EFFECTS:
  something else, for example, also sets the HEADERSIZE global in COMMON RD_GLOBALS

RESTRICTIONS:

PROCEDURE:
  This gives details of HOW the program works, if it is at all tricky or
  would not be obvious to someone who looks at the source code.  It should 
  not be necessary for the casual user to understand the content of this field.

  Here is an example:  The program determines the file type by checking the 
  header length field stored with the OI header (assumes 1716L).
  this may have to be modified if the OI/ORA header size changes.

EXAMPLES:
  example of how to call it (to show format of a call from an actual program

SEE ALSO:
  MK_DOCS  RD_ORHEAD  

 MODIFICATION HISTORY:
 	Written by:	  Author, Date

(See c:\idl_loc\lib\sfo_pros\document.pro)


DO_PRINT_ORHEAD

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	DO_PRINT_ORHEAD

 PURPOSE:
	This function prints the contents of an optrec-style file header

 CATEGORY:
	Header functions

 CALLING SEQUENCE:

	DO_PRINT_ORHEAD, Orheader

 INPUTS:
	orheader:	A optrec-style header for sumfiles or image files.

 OUTPUTS:
	None


 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993.
	29.12.97    Michael Stryker made into print_orheader

(See c:\idl_loc\lib\sfo_pros\do_print_orhead.pro)


DUMMY

[Previous Routine] [Next Routine] [List of Routines]
 NAME:	
	DUMMY

 PURPOSE:
	This function does absolutely nothing !

 CATEGORY:
	NIRVANA

 CALLING SEQUENCE:
	DUMMY

 INPUTS:
	Karma

 OUTPUTS:
	Spirit

 RESTRICTIONS:
	Does not work in real world !

 MODIFICATION HISTORY:
 	Written by:	Gerhard Brändle, 27.7.93.
	Month, Year	Any additional mods get described here.  

(See c:\idl_loc\lib\sfo_pros\dummy.pro)


FIXGREEN

[Previous Routine] [Next Routine] [List of Routines]
fixgreen.pro

Purpose:  fixes defective green files produced by optrec9
 by inserting correct tag and lDataType and lFiletype and LSizeOf
 fields into old-style optrec header so that rd_head will work
 properly

Michael Stryker, 18 Aug 98

(See c:\idl_loc\lib\sfo_pros\fixgreen.pro)


GB_FSLIDER

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	GB_FSLIDER

 PURPOSE:
	The standard slider provided by the WIDGET_SLIDER() function is
	integer only. This compound widget provides a floating point
	slider.

 CATEGORY:
	Compound widgets.

 CALLING SEQUENCE:
	widget = GB_FSLIDER(parent)

 INPUTS:
       PARENT - The ID of the parent widget.

 KEYWORD PARAMETERS:
	DRAG - Zero if events should only be generated when the mouse
		is released. Non-zero if events should be generated
		continuously when the sliders are adjusted. Note: On slow
		systems, /DRAG performance can be inadequate. The default
		is DRAG=0.
	FORMAT - Provides the format in which the slider value is displayed.
		This should be a format as accepted by the STRING procedure.
		The default is FORMAT='(G13.6)'
	FRAME - Nonzero to have a frame drawn around the widget. The
		default is FRAME=0.
	MAXIMUM - Maximum value of slider (default=100).
	MINIMUM - Minimum value of slider (default=0).
	SUPPRESS_VALUE - If true, the current slider value is not displayed.
		(default is to display value).
	TITLE - Title of slider (Default is no title).
	UVALUE - Supplies the user value for the widget.
	VALUE - Initial value of slider
	VERTICAL - If non-zero, the sliders are oriented vertically.
		The default is horizontal.
	XSIZE - For horizontal sliders, sets the length.
	YSIZE - For vertical sliders, sets the height.

 OUTPUTS:
       The ID of the created widget is returned.

 COMMON BLOCKS:
	CW_FSLIDER_BLK: Private to this module.

 SIDE EFFECTS:
	This widget generates event structures containing a field
	named value when its selection thumb is moved. This is a
	floating point value.

 PROCEDURE:
	WIDGET_CONTROL, id, SET_VALUE=value can be used to change the
		current value displayed by the widget.

	WIDGET_CONTROL, id, GET_VALUE=var can be used to obtain the current
		value displayed by the widget.

 MODIFICATION HISTORY:
	April 2, 1992, SMR and AB
		Based on the RGB code from XPALETTE.PRO, but extended to
		support color systems other than RGB.
	July 2, 1993, Gerhard Brändle
		Changed name from CW_FSLIDER to GB_FSLIDER and made it work
		with Windows. The range was 0-1000000, so the steps were much too
		small to see any changes when the arrow-buttons were pressed.
		I have reduced the range to 0-1000.

(See c:\idl_loc\lib\or_pros\gb_fslid.pro)


GETACLIP

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	GETACLIP

 PURPOSE:
	This function sorts the input float array and returns
	the two floating point values of input array 
	at position A % and B % (Get auto clip values)

 CATEGORY:
	Image manipulation

 CALLING SEQUENCE:

	Floatarr=GETACLIP(Inputarr, A, B, /AVERAGE)

 INPUTS:

	Inputarr:		Floating point array, to calculate return values for.

	A:		Floating point value, defining the percental position in
			Inputarr of return value 1.

	B:		Floating point value, defining the percental position in
			Inputarr of return value 2.

	/AVERAGE:	Optional keyword to average 3 neighbours in the 
			sorted array to compute the return values.
			

 OUTPUTS:

	Floatarr: 	A floating point array with 2 elements, containing the 
			Inputarr values (sorted) at position A % and B %.

 EXAMPLE:

	The following command:

		temp=	FLOAT(INDGEN(20, 20))
		result=	GETACLIP(temp, 5.1, 95.7)

	returns result(0) -> 20.0 and result(1) -> 383
	
 MODIFICATION HISTORY:
 	Written by:	Gerhard Brändle, September 1993.
	14.09,93	Added optional keyword /AVERAGE, GB

(See c:\idl_loc\lib\or_pros\getaclip.pro)


GETDIRS

[Previous Routine] [Next Routine] [List of Routines]
 NAME: 
       GETDIRS

 PURPOSE:
       This function returns a list of directories, matching the Dirpattern.
       Files are filtered out (see GETFILES.PRO).

 CATEGORY:
       DOS, FILE-SYSTEM

 CALLING SEQUENCE:
       Result = GETDIRS(Dirpattern)

 INPUTS:
       Dirpattern:     String (e.g. 'c:\ABC*')

 OUTPUTS:
       This function returns a string array with the matched directory names

 RESTRICTIONS:
       Works with DOS filing sytem only !!!
       The same function exists in pickfile.pro for other OS versions than
       Windows. Pickfile doesn't need the function with Windows IDL anyway
       (All stuff is done by OS_PICKFILE).
       This one here adds the getdirs function to Windows IDL if
       COMPILED AFTER PICKFILE.PRO !!! Thats why we need different
       command-files for different OS-Versions (e.g. VMS compiles pickfile.pro
       including its own getdirs, whereas Windows IDL needs to compile
       pickfile.pro first, followed by getdirs.pro to override the first one !

 EXAMPLE:

 
       dirs=GETDIRS('C:\ABC*')

       The string array dirs contains all dirnames found in directory C:\ beginning with ABC
       and having no extension. If no directory matched a scalar Null string is returned ('')


 MODIFICATION HISTORY:
       Written by:     Gerhard Brändle, 08.09.93
       July 12, 94     Added comments (RESTRICTIONS) concerning OS dependencies
                       of pickfile.pro, that comes with its own getdirs ! GB

(See c:\idl_loc\lib\or_pros\getdirs.pro)


GETFILES

[Previous Routine] [Next Routine] [List of Routines]
 NAME: 
       GETFILES

 PURPOSE:
       This function returns a list of files, matching the Filepattern.
       Directories are filtered out (see GETDIRS.PRO).

 CATEGORY:
       DOS, FILE-SYSTEM

 CALLING SEQUENCE:
       Result = GETFILES(Filepattern)

 INPUTS:
       Filepattern:    String (e.g. 'c:\*.txt')

 OUTPUTS:
       This function returns a string array with the matched filenames

 RESTRICTIONS:
       Works with DOS filing sytem only !!!
       The same function exists in pickfile.pro for other OS versions than
       Windows. Pickfile doesn't need the function with Windows IDL anyway
       (All stuff is done by OS_PICKFILE).
       This one here adds the getfiles function to Windows IDL if
       COMPILED AFTER PICKFILE.PRO !!! Thats why we need different
       command-files for different OS-Versions (e.g. VMS compiles pickfile.pro
       including its own getfiles, whereas Windows IDL needs to compile
       pickfile.pro first, followed by getfiles.pro to override the first one !

 EXAMPLE:

 
       files=GETFILES('C:\*.bat')

       The string array files contains all filenames found in directory C:\ with the extension .bat.
       If no files matched, a scalar Null string is returned ('')


 MODIFICATION HISTORY:
       Written by:     Gerhard Brändle, 08.09.93
       July 12, 94:    Added comments on OS dependencies and conflicts
                       with oickfile.pro   GB

(See c:\idl_loc\lib\or_pros\getfiles.pro)


GET_BIT

[Previous Routine] [Next Routine] [List of Routines]
 NAME:	
	GET_BIT

 PURPOSE:
	This function extracts the bit value(s) at
	the given position Bitpos from the given integer
	Value (scalar or array).

 CATEGORY:
	Low level function for bit operations

 CALLING SEQUENCE:
	Result = GET_BIT(Value, Bitpos)

 INPUTS:

	Value:		Integer (1, 2 or 4 byte) scalar or array to get
			bit values from.

	Bitpos:		Integer value (valid range: [0-31]) defining the
			bit position to be extracted from Value.
			NOTE:	Bitpos counting starts with 0 !

 OUTPUTS:
	This function returns the bit value(s) at Bitpos in Value.

 RESTRICTIONS:
	Does not work with data types of 'Value' other than integer.

 EXAMPLE:
	The instruction:
		val=	7
		bitpos2=GET_BIT(val, 2)
	results in bitpos2=1, as the 3'rd bit (=bit no 2) in value 7 is set !

	Now with a non scalar value:
		vec=	[4,66,189]
		bitpos1=GET_BIT(vec, 1)
	results in bitpos1=[0,1,0]	
		


 MODIFICATION HISTORY:
 	Written by:	Gerhard Brändle, 21.7.93.
	Month, Year	Any additional mods get described here.  

(See c:\idl_loc\lib\or_pros\get_bit.pro)


GET_OFILES

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	GET_OFILES

 PURPOSE:
	Get individual orientation files for further analysis.

 CATEGORY:
	Analysis tool.

 CALLING SEQUENCE:
	Result = GET_OFILES(infilename, infilename_suffix, numorients, o_or_n_answer)


 INPUTS:
	Infilename:	Character array to put names of individual orientation files into.
					infilename(0) should have the infilename prefix (including
							the path in it. This element will be replaced with
							 the full filename, including the path.
	Infilename_suffix: Suffix to be used for infilename (example '0ac').
	Numorients: Number of orients to be used.
	O_or_n_answer:  Old or new file naming convention.
					 1 if it is a new name, 0 if it is an old name.

 OUTPUTS:
	An array Infilename that has the names of all of the individual orientations,
		including the file path.

 RESTRICTIONS:
	None that I know of.

 PROCEDURE:
	Simple!

 EXAMPLE:
	Typical calling sequence:
		infilename = strarr(32,50)
		infilename(0) = file_path
		infilename = GET_OFILES(infilename, infilename_suffix, numorients, o_or_n_answer)
   Note that infilename is self-referential, the 0th element has filepath in it when
       the function is called, and when it is returned it has all of the orientation
       file names in it.

 MODIFICATION HISTORY:
 	Written by:	MC Crair, Jan '98

(See c:\idl_loc\lib\anal_tools\new_but_untested\get_ofiles.pro)


GREEN2TIFF -- COPIES GREEN OR OPTREC/ORA ANALYZE FILES TO TIFF FORMAT

[Previous Routine] [Next Routine] [List of Routines]
NAME:
  green2tiff -- copies green or Optrec/ORA analyze files to tiff format

PURPOSE:
  This lets you make quick pictures for Corel or Photoshop.
  Oidp should do this, but it screws up, and only makes Poscript
    files with few grey levels.  Oidp seems to silently fail to
    make the tiff output files.  Hence this clooge.  I should fix
    oidp some day.

CATEGORY:
  conversions

CALLING SEQUENCE:
  green2tiff OR green2tiff, input_file

INPUTS:
  optional analyze or green filename

KEYWORD PARAMETERS:
  none

OUTPUTS:
  a tiff file of the same name as the input file with .tif appended

 MODIFICATION HISTORY:
 	Written by:	  Stryker, October 23, 1999

(See c:\idl_loc\lib\sfo_pros\green2tiff.pro)


GREENUSH2FLT

[Previous Routine] [Next Routine] [List of Routines]
NAME:
  greenush2flt

PURPOSE:
  This procedure reads new ORA/OI Green files, which are saved as single-frame
  image files of unsigned shorts, and converts them into the old Greenfile format,
  which is single-frame image files of floats.  This old format is the same as the
  one used by the output files from ANALYZE.   

  The converted files are returned with a new-style ORA/OI header. 

  By default, the output files are the input filenames+'_float'
  The REPLACE keyword causes the output file to overwrite the input file.

CATEGORY:
	conversions

CALLING SEQUENCE:

	greenush2flt, INFILE=infile, OUTFILE=outfile, /REPLACE

INPUTS:
	none

KEYWORD PARAMETERS:
	INFILE=infile 
	OUTFILE=outfile
	/REPLACE


OUTPUTS:
	a new file


PROCEDURE:
  It determines the file type by checking the header length field stored with the OI header (assumes 1716L).
  this may have to be modified if the OI/ORA header size changes.

  It determines the tag field by looking for DAT_FLOATt&IMAGEFILE or DAT_USHORT&SUMFILE, and it stops
  for debugging purposes if neither combination is set.  The user can set the tag field by typing
  orhdr.tag=byte('A_01') and continue if he likes by typing .cont on the next line.

 MODIFICATION HISTORY:
 	Written by:	  Michael Stryker, 19 Jan 98

(See c:\idl_loc\lib\forora\greenush2flt.pro)


GT_DATE

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	GT_DATE

 PURPOSE:
	This function obtains the current system time and returns the date as MMDDYY
	(instead of the stupid RSI format)

 CATEGORY:
	Miscellaneous

 CALLING SEQUENCE:
	Result = GT_DATE()

 INPUTS:
	None

 OUTPUTS:
	This function returns the a string which contains the current date in the
	form MMDDYY


 EXAMPLE:
	If now it is     		Wed Jul 21 14:42:09 1993 (in RSI format)
	The result of the operation 	Result=gt_date()
	will be	the string		072193

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, May 1993
	July, 1994	Any additional mods get described here.  

(See c:\idl_loc\lib\or_pros\gt_date.pro)


GT_USER

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	GT_USER

 PURPOSE:
	This function returns the current user name in the different operating systems.
	It looks for the !VERSION system variable and depending on the operating
	system decides on how to do it.
	In Windows it will read the USERNAME from the environment, and
     prompt for it and then set it if it is not already set
	In UNIX it will find the environment variable USER
   Otherwise it returns 'default'

 CATEGORY:
	File functions

 CALLING SEQUENCE:
	Result = GT_USER()

 INPUTS:
	None

 OUTPUTS:
	This function returns a string which contains the current users login name

 EXAMPLE:
	Result = GT_USER()

 KNOWN BUGS:
	currently only Windows and Unix are detected, everything else returns 'default'

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, July 1994
   February, 1999, modified to work with Win95 and WinNT using setenv/getenv calls

(See c:\idl_loc\lib\or_pros\gt_user.pro)


HISTOPLOT -- PLOTS HISTOGRAM OF DATA

[Previous Routine] [Next Routine] [List of Routines]
NAME:
  histoplot -- plots histogram of data

URPOSE:
  histoplot plots a histogram of a one-dimensional array of data,
  correctly preserving and representing the x-axis

CATEGORY:
  plotting

CALLING SEQUENCE:
  HISTOPLOT, A [, DMIN=dmin, DMAX=dmax, DBINSIZE=dbinsize, DNBINS=dnbins]

INPUTS:
  a: a one-dimensional array of values

KEYWORD PARAMETERS:
  DMIN controls minimum value of data considered in histogram (defaults to minimum of A)
  DMAX controls maximum value of data considered in histogram (defaults to maximum of A)
  DBINSIZE controls the width of each bin of histogram (defaults to 1, unless DNBINS is set)
  DNBINS controls number of bins in final histogram (but has no effect if DBINSIZE is set)

OUTPUTS:
  only a plot

EXAMPLES:
  y=randomn(seed,1000) & histoplot,y,dnbins=50

MODIFICATION HISTORY:
 	Written by:	  Michael P Stryker, 4 January 1999

(See c:\idl_loc\lib\sfo_pros\histoplot.pro)


HLS_MAP

[Previous Routine] [Next Routine] [List of Routines]
 NAME: 
       HLS_MAP 
 
 PURPOSE: 
       This function produces an HLS map from 4 or 8 input arrays 
       which are the single activity maps 
 
 CATEGORY: 
       Analysis 
 
 CALLING SEQUENCE: 
 
       Hls_map = HLS_MAP(In_maps, N, Lightness) 
 
 INPUTS: 
       In_maps:        An array of maps which must be of the format (N,header.x_size,header.y_size) 
       N:              Number of maps from which the maps should be calculated. Currently only 
                       the values 4 and 8 are supported 
       Lightness:      Controls the lightness of the resulting map. 
 
 OUTPUTS: 
       HLS_map:        An array of (3,header.x_size,header.y_size) in which the three components are 
                       the three R G and B maps 
 
 SIDE EFFECTS: 
       MESSAGES are generated which report the errors 
 
 RESTRICTIONS: 
       Only N=4 and N=8 are supported 
 
 EXAMPLE: 
 
       see above 
 
 MODIFICATION HISTORY: 
       Written by:     Tobias Bonhoeffer, October 1993. 
       July, 1994      Any additional modifictaions are described here. 

(See c:\idl_loc\lib\or_pros\oipp\hls_map.pro)


INT2FLT

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	INT2FLT

 PURPOSE:
	This function converts an UNSIGNED intarr 
	into a float array

 CATEGORY:
	Conversions

 CALLING SEQUENCE:

	Flt_array=INT2FLT(Int_array)

 INPUTS:
	Int_array:	An unsigned intarr which is to be 
			converted into fltarray

 OUTPUTS:
	This function produces a float array which contains 
	the values of the input array

 EXAMPLE:

	The command

	Flt_array=INT2FLT(Input_array)

	produces a float array called Flt_array which contains
	the data of Input_array.

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, Imke Gödecke 1.Dec 1993.

(See c:\idl_loc\lib\or_pros\int2flt.pro)


ISO_PLOT

[Previous Routine] [Next Routine] [List of Routines]
Pro iso_plot plot a black and white or greyscale stick-contour map for an orientation
		angle map.  Output file is named mapfile.ps by default
Parameters [default value]:
 MAPFILE=the input file (24-bit TIFF, hue=orientation*2:  ie, 0=360 deg)
 TEMPLATE=if present, a 0-1 mask for the computation and display, in optrec rd_imag format
 /USEPOLAR = set if mapfile is a polar map and you want line length to reflect tuning
 /USEHLS = set if mapfile is an hls map and you want line blackness to reflect response
		strength
 NABERADIUS=[2 -> 5X5 square for analysis] Typically 2/3 of RADIUS value
 RADIUS=[3 radius for analysis of local orientation contours] analysis is done using
		actual radial distance, but only within a square of naberadius size.  Noisier maps
		require larger radius values, and correspondingly larger naberadius.
    	Computation is more nearly exact is naberadius > radius, but is slower.
 LINELENGTH=[.5 or half the maximum size] controls the length of the stick-contour lines
 PLOTSKIP=[4] number of pixels in the original mapfile skipped between drawn contour lines
 MAG=[4] I'm not sure how this works-controls at least the size of the image on the screen,
		but it may not affect the postscript file

 For hls maps, use a grey scale to indicate responsiveness, and the black bars inside a
 thicker white bar to indicate orientation, and the length of the bar to indicate
 selectivity (as in polar map).

(See c:\idl_loc\lib\anal_tools\iso_plot.pro)


IV2TIFF

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	IV2TIFF

 PURPOSE:
	This procedure converts iv-format files (Imager 2001) to tiff-files.
	The extension of the iv-file is converted into .tif

 CATEGORY:
	conversions 

 CALLING SEQUENCE:

	IV2TIFF,iv_filename

 INPUTS:
	iv_filename:	A string which contains the name of the file to be
			converted.

 KEYWORD PARAMETERS: 
       DISPLAY:       Determines whether the converted image is displayed
		       on the screen
		       Default is NODISPLAY

 OUTPUTS:
	None, really. 

 SIDE-EFFECTS:
	A new tiff-file is generated

	The command

	IV2TIFF,'d:\or\data\072390\example.iv'

	produces an outputfile named  'd:\or\data\072390\example.tif'
	which contains the same image as a tiff-file

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, Imke Gödecke May 1995.

(See c:\idl_loc\lib\or_pros\iv2tiff.pro)


LAST_POS

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	LAST_POS

 PURPOSE:
	This function takes in_string and finds the last position of a pos_string
	This function is often helpful for extracting the directory name from a long filename

 CATEGORY:
	String manipulations

 CALLING SEQUENCE:
 
	Pos = LAST_POS(In_string, Pos_string)

 INPUTS:

	In_string:	The string in which the operation should be performed

	Pos_string:	Substring the last position of which should be found


 OUTPUTS:
	This function returns the position at which the string could last be found

 EXAMPLE:
	If A contains "c:\temp\temp\temp\tmp.tmp", B contains "\" 

	pos=LAST_POS(A,B)	will return pos=17

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1995
	July, 1994	Any additional mods get described here.  

(See c:\idl_loc\lib\or_pros\last_pos.pro)


LICENSE INSTRUCTIONS

[Previous Routine] [Next Routine] [List of Routines]
NAME: 
  license instructions 

Instructions for installing IDL licenses on Stryker lab computers:

To install the new license, (or if when you start the present IDL, it
starts in timed demo mode) run IDL5.2 in the unlicensed timed
demo mode and after it starts up, type Ctrl-Alt-L (holding down all 3
keys at once).  You will probably see the floating network licensing 
radio button checked, and a dialog box with lots of lines like those 
below.  If this button is not checked, please check it, and the dialog
box will appear.

Select-Copy the lines below, and then select all the lines in the license
dialog box, and then paste (Ctrl-V) the new lines in on top of the old
ones.  Then Exit (not Cancel) from the licensing dialog box and and
File>>Exit IDL, and the next time that you start IDL the licenses will
be up and running.

This file is also saved as idl_loc/license.txt on faure.

(See c:\idl_loc\lib\sfo_pros\license_installation.pro)


LICENSE STATUS -- UNIX COMMAND TO DETERMINE LICENSE CHECKOUTS

[Previous Routine] [Next Routine] [List of Routines]
NAME: 
  license status -- Unix command to determine license checkouts

URPOSE:
  If you can not get IDL to run except in 7-minute timed demo mode,
  use the following command from any Unix login to determine who 
  has checked out one of our IDL licenses.  

    /usr/local/flexlm/lmutil lmstat -S idl_lmgrd

  We have 26 license units.
  Running IDL on a PC takes 6 license units, so in principle we can run
  up to 4 simultaneous IDL sessions on PCs.  Running IDL on a Unix
  machine takes 10 license units, so we could run only 2 Unix and 
  1 PC session simultaneously to use up all 26 license units.
  Running multiple instances of IDL on a single workstation does not
  use up additional license units beyond the first, unless the output 
  is displayed on a different workstation. 

  If the timed demo mode persists even with a sufficient number
  of license available, then check the licensing of your machine.  
  Run IDL in timed demo mode, then type Ctrl-Alt-L to bring up the
  licensing dialog box.  Check Floating (software) and fill in the
  contents of the dialog box with the contents of the file
  /net/faure/idl_loc/license.txt, by opening the license.txt file with 
  Notepad, and selecting it all, copying, then selecting all the contents 
  of the text box in the IDL licensing box, and finally pasting the clipboard in. 

 On all the alphas, the command
 /usr/local/flexlm/lmutil lmstat -a
 Will list all the flexlm licenses being used (mainly MatLab but including IDL).

  /usr/local/flexlm/lmutil lmstat -S idl_lmgrd  
  will only list idl licenses.

EXAMPLE:
 keck /home/stryker> /usr/local/flexlm/lmutil lmstat -S idl_lmgrd
 lmutil - Copyright (C) 1989-1997 Globetrotter Software, Inc.
 Flexible License Manager status on Fri 4/30/1999 16:16
 
 DAEMONs in configuration file: MLM idl_lmgrd
 Users of features served by idl_lmgrd:
 Users of idl_drawx:  (Total of 3 licenses available)
 
 Users of insight:  (Total of 3 licenses available)
 
 Users of idl:  (Total of 26 licenses available)
 
  "idl" v5.200, vendor: idl_lmgrd
   floating license
 
    stryker phy-char.ucsf.edu phy-char.ucsf.edu (v5.2) (keck.ucsf.edu/1711 152),
  start Fri 4/30 16:16, 6 licenses

(See c:\idl_loc\lib\sfo_pros\license.pro)


LTOUARRAY -- CONVERT LONG ARRAY TO UNSIGNED SHORT

[Previous Routine] [Next Routine] [List of Routines]
NAME:
  ltouarray -- convert long array to unsigned short

PURPOSE:
  LTOUARRAY converts an array of signed long (32-bit) integers to an 
  array of unsigned short integers (16-bit).

  IDL lacks an unsigned integer type, but our sumfiles are stored as
  16-bit unsigned integers.  IDL naturally reads the sumfiles as signed
  integers, making the large values negative.  To store an unsigned integer 
  array, we must first represent it in another form, such as a long array, and
  then convert it to unsigned int for storage.
  This routine does the appropriate  conversion efficiently (more or less).

  To read a sumfile or unsigned int array, we have a routine that does
  the reverse conversion, utolarray.

CATEGORY:
  conversions

CALLING SEQUENCE:

  ltouarray(larray)

INPUTS:
  larray:  an array of longs (32-bit signed numbers (-1*(2^31) to 2^31)

KEYWORD PARAMETERS:
  none

OUTPUTS:
  an unsigned int array of the same values


EXAMPLES:
  uarray = ltouarray(larray)

RESTRICTIONS:
  Very bad behavior if the data overflows the range that can be represented  as
  an unsigned int.  If this could be a problem, then check the range or else
  mask the low 16 bits of the inital long array to get the normal overflow 
  behavior.

SEE ALSO:
  UTOLARRAY  

 MODIFICATION HISTORY:
       Written by:       Michael Stryker, 28 Dec 97

(See c:\idl_loc\lib\sfo_pros\ltouarray.pro~)


LTOUARRAY -- OBSOLETE CONVERT LONG ARRAY TO UNSIGNED SHORT

[Previous Routine] [Next Routine] [List of Routines]
NAME:
  ltouarray -- OBSOLETE convert long array to unsigned short

PURPOSE:
  LTOUARRAY converts an array of signed long (32-bit) integers to an 
  array of unsigned short integers (16-bit).

 THIS ROUTINE WAS MADE OBSOLETE BY THE NEW UINT DATA TYPE IN IDL 5.2

  IDL lacks an unsigned integer type, but our sumfiles are stored as
  16-bit unsigned integers.  IDL naturally reads the sumfiles as signed
  integers, making the large values negative.  To store an unsigned integer 
  array, we must first represent it in another form, such as a long array, and
  then convert it to unsigned int for storage.
  This routine does the appropriate  conversion efficiently (more or less).

  To read a sumfile or unsigned int array, we have a routine that does
  the reverse conversion, utolarray.

CATEGORY:
  conversions

CALLING SEQUENCE:

  ltouarray(larray)

INPUTS:
  larray:  an array of longs (32-bit signed numbers (-1*(2^31) to 2^31)

KEYWORD PARAMETERS:
  none

OUTPUTS:
  an unsigned int array of the same values


EXAMPLES:
  uarray = ltouarray(larray)

RESTRICTIONS:
  Very bad behavior if the data overflows the range that can be represented  as
  an unsigned int.  If this could be a problem, then check the range or else
  mask the low 16 bits of the inital long array to get the normal overflow 
  behavior.

SEE ALSO:
  UTOLARRAY  

 MODIFICATION HISTORY:
       Written by:       Michael Stryker, 28 Dec 97

(See c:\idl_loc\lib\sfo_pros\ltouarray.pro)


MAKE_HEL

[Previous Routine] [Next Routine] [List of Routines]
 NAME:   
       MAKE_HEL   
   
 PURPOSE:   
       This nongeneral procedure generates the IDL help files (*.hel) for our   
       procedure directories:   
               R:\idl\lib\muc_pros\   
               R:\idl\lib\or_pros\   
               R:\idl\lib\sfo_pros\   
   
 CATEGORY:   
       HELP, SPECIAL, NONGENERAL   
   
 CALLING SEQUENCE:   
       MAKE_HEL   
   
 INPUTS:   
       No   
   
 OUTPUTS:   
       No   
   
 PROCEDURE:   
       Calls the IDL mk_library_help procedure to generate the IDL help files.   
   
 RESTRICTIONS:    
       !!! Deserves a change-directory to R: prior to execution !!!
       This is possibly due to a bug in the filepath() command, which
       does NOT generate a proper temporary path with the /TMP keyword.

 EXAMPLE:   
       MAKE_HEL   
       Just type this at the IDL prompt to have it executed.   
   
 MODIFICATION HISTORY:   
       Written by:     Gerhard Brändle, 27.7.93   
       27.01.94        Changed message text to reflect IDL V 3.5.1 capability to set the  
                       help-path in the preferences menu. GB  

(See c:\idl_loc\lib\or_pros\make_hel.pro)


MK_DOCS (MAKE LOCAL IDL DOCUMENTATION IN HTML FORMAT)[1]

[Previous Routine] [Next Routine] [List of Routines]
NAME:
  MK_DOCS (make local idl documentation in html format)

PURPOSE:
  This procedure descends the the directory tree recursively from rootdir
  and makes html documentation using the built-in idl mk_html_help routine.
  Uses built-in idl expand_path and no longer uses find_file routines.

  Only source files with appropriate documentation headers are included, and
  we depend on the programmers to make the documentation correspond with
  what the program actually needs or does.  Silly, huh?

  An example of an appropriate documentation header is seen in document.pro

CATEGORY:
	documentation

CALLING SEQUENCE:

  pro mk_docs, rootdir=rootdir, doctitle=doctitle , outfile=outfile , unix=unix

INPUTS:
	none

KEYWORD PARAMETERS:

  unix = set default parameters for running on unix

  rootdir=Root directory for the programs for which documentation will be
	generated (this routine automatically prepends the required '+')
	By default '/net/faure/idl_loc'

  doctitle=The html Title field, used to name the page and the bookmark

  outfile=The name of the output html file, '~idl/www_public/idl_loc.htm'
	by default

OUTPUTS:
  an html file containing all the documentation

EXAMPLE:
  mk_docs

SEE ALSO:
  DOCUMENT

 MODIFICATION HISTORY:
 	Written by:	  Michael Stryker, 28 Dec 97

(See c:\idl_loc\lib\sfo_pros\mk_docs.pro)


MK_DOCS (MAKE LOCAL IDL DOCUMENTATION IN HTML FORMAT)[2]

[Previous Routine] [Next Routine] [List of Routines]
NAME:
  MK_DOCS (make local idl documentation in html format)

PURPOSE:
  This procedure descends the the directory tree recursively from rootdir
  and makes html documentation using the built-in idl mk_html_help routine.
  Uses built-in idl expand_path and no longer uses find_file routines.

  Only source files with appropriate documentation headers are included, and
  we depend on the programmers to make the documentation correspond with
  what the program actually needs or does.  Silly, huh?

  An example of an appropriate documentation header is seen in document.pro

CATEGORY:
	documentation

CALLING SEQUENCE:

  pro mk_docs, rootdir=rootdir, doctitle=doctitle , outfile=outfile

INPUTS:
	none

KEYWORD PARAMETERS:

  rootdir=Root directory for the programs for which documentation will be 
	generated (this routine automatically prepends the required '+')
	By default '/net/faure/idl_loc'

  doctitle=The html Title field, used to name the page and the bookmark

  outfile=The name of the output html file, '~idl/www_public/idl_loc.htm' 
	by default

OUTPUTS:
  an html file containing all the documentation

EXAMPLE:
  mk_docs

SEE ALSO:
  DOCUMENT  

 MODIFICATION HISTORY:
 	Written by:	  Michael Stryker, 28 Dec 97

(See c:\idl_loc\lib\sfo_pros\mk_docs.pro~)


MK_OIFIL

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	MK_OIFIL

 PURPOSE:
	This function creates an *empty* but complete OI datafile (with OI header, of course).
	The file contains empty frames for all header-defined conditions and frames count.

 CATEGORY:
	OI file functions

 CALLING SEQUENCE:

	ret = MK_OIFIL(filename, header, /OVERWRITE)

 INPUTS:
	filename:	A string which specifies the filename of an *not existing* file (if no param /OVERWRITE)

	header:	An OI header structure that will be used as the OI datafile header.

	OVERWRITE:	An optional parameter which allows the procedure to overwrite an existing file.


 OUTPUTS:
	A file is created and the 'header' is written to it. All frames are zeroed.
	The function returns 0 if OK, else error number of the file-open function OPENW (see also !ERR_STRING)
	If the file does already exist, -1 is returned signaling an error.

 EXAMPLE:

	Issuing the command

	ret = mk_oifil('d:\or\data\072390\example.0a', header)

	creates a OI data file 'd:\or\data\072390\example.0a', writes the 'header' to the file,
	adds empty frames to the file as defined by the header.
	A nonzero value is returned if an error occurred.
	Note: The error value is the one that was returned by the OPENW function.
           See !ERR_STRING for further information.

 MODIFICATION HISTORY:
 	Written by:	Gerhard Braendle, August 1996.
	Modified:	19.08.96/GB		Now with optional /OVERWRITE param to allow mk_oifil to overwrite an existing file.

(See c:\idl_loc\lib\oi_general\mk_oifil.pro)


MK_OIHDR

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	MK_OIHDR

 PURPOSE:
	This function creates an OI header *frame* from a couple of parameters.
	The header is just a raw *frame* which normally needs to be completed manually !

 CATEGORY:
	OI header functions

 CALLING SEQUENCE:

	header = MK_OIHDR(filetype, filesubtyp, datatype, pixelx, pixely, frames, stims, username)

 INPUTS:
	filetype:		A long int defining the type of the OI data file (RAWBLOCK_FILE, DCBLOCK_FILE, SUM_FILE)
	filesubtype:	A long int defining the creator prog. of this header (file) (FROM_VDAQ, FROM_ORA)
	datatype:		A long int defining the type of pixel data (DAT_UCHAR, DAT_USHORT, DAT_LONG, DAT_FLOAT)
	pixelx:		A long int defining the width of one frame in pixels
	pixely:		A long int defining the height of one frame in pixels
	frames:		A long int defining the number of frames per condition (stimulus)
	stims:		A long int defining the number of conditions (stims)
	username:		A byte array with max. 32 bytes


 OUTPUTS:
	With the given parameters, a OI header is created and returned.

 EXAMPLE:

	Issuing the command

	header = mk_oihdr(SUM_FILE, FROM_ORA, DAT_FLOAT, 192L, 144L, 5L, 4L, byte('Frank Zappa'))

	creates and returns an OI header with these parameters.


 MODIFICATION HISTORY:
 	Written by:	Gerhard Braendle, August 1996.
	Modified:	27.09.96/GB	Removed predefinition of ROI from width and height values.

(See c:\idl_loc\lib\oi_general\mk_oihdr.pro)


NWSMOOTH

[Previous Routine] [Next Routine] [List of Routines]
 NAME:NEW_SMOOTH
	

 PURPOSE:
       The original IDL SMOOTH has the problem that it only works when the box (of the car)
       fully fits into the array (for the other pixels it leaves the original values). 
       This causes problems with large smoothing values since only a minor part of the array 
       is actually smoothed
       The NEWSMOOTH function circumvents this problem by "doing its best" at the edges. It takes 
       boxcar mask and calculates the average with this mask, disregarding the pixels outside of
       the array. It does the scaling properly.

 CALLING SEQUENCE:
       result=NEWSMOOTH (in_array, boxcar_width)

 INPUTS:
       in_array:     The array to be smoothed. It can be of any type and any size (hopefully)

	boxcar_width: The width of the boxcar to be used is (2*boxcar_width+1)


 OUTPUTS:
	The function returns the original array smoothed in the way explained above



 EXAMPLE:
	array=RANDOMN(seed,200,200)
	smoothed_array=NEW_SMOOTH(array,30)

	smoothed_array will be a more or less uniform array

; MODIFICATION HISTORY:
 	Written by:	Imke Goedecke, Tobias Bonhoeffer	April 1994
	July, 2001	Any additional modifications will be described here.

(See c:\idl_loc\lib\or_pros\nwsmooth.pro)


OI2OR

[Previous Routine] [Next Routine] [List of Routines]
NAME:
	OI2OR

PURPOSE:
  This procedure converts the new  ORA format files 
  (ORA 2001 after to V3.x) to OPTREC  files.
  If the Keyword /REPLACE is set, then the input file 
  will be OVERWRITTEN with the converted one !!!
  Otherwise, the output file will have a 'x' appended 
  to the input  filename

  This program works on 3 types of files:  
  sum_files (TAG=S) with ncondsXnframes of unsigned short data,
  and anlyze files or green files (TAG=A_01), each of which contain a 
  single frame of float data.  It sets the tag field appropriately.

  Due to the fact that the old header doesn't include the specification 
  of the data type used for pixel storage, the converter expects unsigned 
  short for files with the "S" tag, and float for those with the "A" tag.

  Note: The old ORA (prior to V3.x) wrote sumfiles with an "S" tag and 
  used unsigned shorts, green files had the "A" tag and used floats (this 
  is also what the old analyze used when creating image files).


CATEGORY:
	conversions

CALLING SEQUENCE:

	OI2OR

INPUTS:
	none required

 KEYWORD PARAMETERS:

  FILESPEC=filespec to give specifier for filenames 
    The normal * ? wildcards are permitted if you want to do multiple files.
    If no FILESPEC keyword is given, the program invokes pickfile to 
    let you choose the single filename interactively.

   /REPLACE to over-write the input file.

 OUTPUTS:
	an optrec-type file

 SIDE-EFFECTS:

 RESTRICTIONS:

 PROCEDURE:
	Straightforward.

	Examples:

		OI2OR, FILESPEC='/net/faure3/idl/f/s_031295.0a' ,/REPLACE

		overwrites this file with the result of the conversion.
 SEE ALSO:
       RD_HEAD


 MODIFICATION HISTORY:
 	Written by:	Gerhard Braendle September 96
	Modified: 28 Dec 97 Michael Stryker for the reverse conversion

(See c:\idl_loc\lib\forora\oi2or.pro)


OIDP

[Previous Routine] [Next Routine] [List of Routines]
NAME:
  oidp

PURPOSE:
  to display image files

RESTRICTIONS:
  Curently works only on single-frame float files, like those made by
  ANALYZE, or the green files made by the old version of OPTREC.
  It also works on the output files from SHORT2FLOAT

BUGS:
  AFter clipping, the output files made from input files with the new OI/ORA
  headers are mis-aligned.  This must be fixed.

AUTHOR:
  Mostly Bonhoeffer and Braendle, with additions by Stryker

MORE DOCUMNETATIOPN SHOULD FOLLOW

(See c:\idl_loc\lib\or_pros\oidp\oidp.pro)


OITELL

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	OITELL

 PURPOSE:
	This function prints the new-style ORA header in hman-readable form. 

 CATEGORY:
	OI file functions

 CALLING SEQUENCE:

	OITELL, FILENAME=filename

 INPUTS:
	(optional) filename:	A string which specifies the filename of an *existing* OI data file.
	If input is omitted, then a dialog box is offered for picking an input file.

 OUTPUTS:
	Nothing besides the contents of the log window.

 MODIFICATION HISTORY:
 	Written by:	Gerhard Braendle, August 1996.
	Documented by:	Michael Stryker

(See c:\idl_loc\lib\oi_general\oitell.pro)


OLD_OR_NEW

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	OLD_OR_NEW

 PURPOSE:
	Determine if file_name follows old OR naming convention or new naming convention
     example of old naming convention: aor_r_000_.0ab

 CATEGORY:
	Analysis tool.

 CALLING SEQUENCE:

	Result = old_or_new(File_name)


 INPUTS:
	File_name:	File_name to determine type of

 OUTPUTS:
	This simple function returns a 1 if it is a new name, 0 if it is an old name.

 RESTRICTIONS:
	Can be used on unix or windows, looks at forward and backward slashes.

 PROCEDURE:
	Simple!

 EXAMPLE:

		answer = Old_or_new(file_path)

 MODIFICATION HISTORY:
 	Written by:	MC Crair, Jan '98

(See c:\idl_loc\lib\anal_tools\new_but_untested\old_or_new.pro)


ORA2OI

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	ORA2OI

 PURPOSE:
	This procedure converts the old ORA format files (ORA 2001 prior to V3.x) to Optical Imaging files.
	The input file will be OVERWRITTEN with the converted one !!!
	Due to the fact that the old header doesn't include the specification of the data type used for pixel
	storage, the converter expects unsigned short for files with the "S" tag, and float for those with the "A" tag.
	Note: The old ORA (prior to V3.x) wrote sumfiles with an "S" tag and used unsigned shorts, green files
		had the "A" tag and used floats (this is also what the old analyze used when creating image files).


 CATEGORY:
	conversions

 CALLING SEQUENCE:

	ORA2OI, oldorafilename

 INPUTS:
	oldorafilename:	A string which contains the name of the file to be converted.

 KEYWORD PARAMETERS:

 OUTPUTS:
	Overwrites the input filename "oldorafilename"

 SIDE-EFFECTS:

 RESTRICTIONS:

 PROCEDURE:
	Straightforward.

	Examples:

		ORA2OI, 'd:\or\data\072390\s_031295.0a'

		overwrites this file with the result of the conversion.

 MODIFICATION HISTORY:
 	Written by:	Gerhard Braendle September 96
	Modified:	03.11.96/GB	Now with autodetection of input file format.

(See c:\idl_loc\lib\oi_general\ora2oi.pro)


ORIMG3D

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	ORIMG3D

 PURPOSE:
	This procedure loads an image file in the OR-Format, scales, rebins (with smoothing)
	a little and finally displays it as a shaded surface.

 CATEGORY:
	Image processing, image display

 CALLING SEQUENCE:

	ORIMG3D, Filename

 INPUTS:
	Filename:	Filename of an OR-image

 OUTPUTS:
	Plots a shaded surface.
	The axes label values are incorrect, as the image is a scaled one !

 RESTRICTIONS:
	Will not work with images with odd dimension(s)(no problem to make this work as well).

 EXAMPLE:

	The image 'R:\IDL\IMAGES\OR\test.3aa' will be read and displayed as a surface plot:

	ORIMG3D, 'R:\IDL\IMAGES\OR\test.3aa'

 MODIFICATION HISTORY:
 	Written by:	Gerhard Brändle, November 1993.
	July, 1994      Any additional modifictaions are get described here.

(See c:\idl_loc\lib\or_pros\orimg3d.pro)


OTI

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	OTI

 PURPOSE:
	Computes the oriented response (and orientation tuning index - OTI)
      of an analyzed orientation map.
   Can handle 4 or 8 orientations; old or new filenaming conventions.

 CATEGORY:
	Analysis routine.

 CALLING SEQUENCE:
	OTI, Local_smoothing_width, High_pass_width, Number_of_orients

 INPUTS:
	Local_smoothing_width: This is the (half) width of the smoothing filter in pixels.
           An odd integer number should be used, if not 1 will be added to the number.
			A typical value is 3. Note this variable is called hp_width!
	High_pass_width: This is the (half) width of high pass filter in pixels.
			A typical value is around 70. Note this variable is called lp_width!
	Number_of_orients: Number of orientations, should be 4 or 8.

 KEYWORD PARAMETERS:
	NAME: Name of a file to use for the calculation. This can be any one of the orientations
         for either eye. This will be used for drawing the template too.

 OUTPUTS:
	This program has lots of outputs.

 SIDE EFFECTS:
	Might be many. Not sure.
	Updates analysis_config.user.

 RESTRICTIONS:
	There should be a file called 'analysis_config.user' in the idl directory.
		This program uses that file to keep a record of the latest directory used
       for analysis, and possibly other configuration information.
	Calls a number of other home-built functions, including:
				get_ofiles
				old_or_new
				get_template
				path_from_name
				notemplate_smooth
		and maybe others too.

 PROCEDURE:
	This is the foobar superfloatation method.

 EXAMPLE:

 	To run, input '@XOTI' at the idl prompt and follow instructions.

   The prefix and suffix will be taken from the file chosen
		 	to define the region of iterest.


 MODIFICATION HISTORY:
 	Written by:	MC Crair, 05/96.
   May 11, 1996  Make screen output both orientation tuning and histograms
          Include hardcopy output of these orientation tuning pictures as
          eg "analysis/aor_8lor.1ab" for the 8 orientation map of left orientation
          of the *.1ab analysis files.
          Also makes hardcopy output as postscript files of the histograms, and text files
          of the histogram values so they can be imported to other graphing routines. These
          files are called eg "lor_1ab.txt" or "lor_1ab.ps" etc.
   June 6, 1996 Modify to allow computation of orientation tuning as a function of distance
           from a user specified point (the cannulae).
	Jan 98  Modify to work in IDL 5.0, on the PC and Unix workstations.
			Works with new and old filename conventions.
           Uses widget to define directory and file to use for defining region
           	of interes.
		    Should now be insensitive to image size, but this is not tested.
           Output of files should be to the same directory as where input came from.
			Uses a SAVE and RESTORE routine from a file called analysis_config.user
				to save last file name and directory used.
           This program and OTI_DIST are very similar.

(See c:\idl_loc\lib\anal_tools\new_but_untested\oti.pro)


OTI_DIST

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	OTI_DIST

 PURPOSE:
	Computes the oriented response (and orientation tuning index - OTI)
      of an analyzed orientation map. Calculates same as a function of distance
      from a user specified point (such as a cannula position).
   Can handle 4 or 8 orientations.

 CATEGORY:
	Analysis routine.

 CALLING SEQUENCE:
	OTI_DIST, Local_smoothing_width, High_pass_width, Number_of_orients

 INPUTS:
	Local_smoothing_width: This is the (half) width of the smoothing filter in pixels.
           An odd integer number should be used, if not 1 will be added to the number.
			A typical value is 3. Note this variable is called hp_width!
	High_pass_width: This is the (half) width of high pass filter in pixels.
			A typical value is around 70. Note this variable is called lp_width!
	Number_of_orients: Number of orientations, should be 4 or 8.

 KEYWORD PARAMETERS:
	NAME: Name of a file to use for the calculation. This can be any one of the orientations
         for either eye. This will be used for drawing the template too.
	TEMPLATE_FILENAME: Name of template file. If set, not prompted for filename..
   OUTPUT: Set if desire postscript and text output of graphs and don't want to be
				prompted for answer.

 OUTPUTS:
	This program has lots of outputs displayed to the screen, and written to text
         postscript files if desired.

 SIDE EFFECTS:
	Might be many. Not sure.
	Updates analysis_config.user.

 RESTRICTIONS:
	There should be a file called 'analysis_config.user' in the idl directory.
		This program uses that file to keep a record of the latest directory used
       for analysis, and possibly other configuration information.
	Calls a number of other home-built functions, including:
				get_ofiles
				old_or_new
				get_template
				path_from_name
				notemplate_smooth
		and maybe others too.

 PROCEDURE:
	This is the foobar superfloatation method.

 EXAMPLE:

 	To run, input '@XOTI_DIST' at the idl prompt and follow instructions.

   The prefix and suffix will be taken from the file chosen
		 	to define the region of iterest.


 MODIFICATION HISTORY:
 	Written by:	MC Crair, 05/96.
   May 11, 1996  Make screen output both orientation tuning and histograms
          Include hardcopy output of these orientation tuning pictures as
          eg "analysis/aor_8lor.1ab" for the 8 orientation map of left orientation
          of the *.1ab analysis files.
          Also makes hardcopy output as postscript files of the histograms, and text files
          of the histogram values so they can be imported to other graphing routines. These
          files are called eg "lor_1ab.txt" or "lor_1ab.ps" etc.
   June 6, 1996 Modify to allow computation of orientation tuning as a function of distance
           from a user specified point (the cannulae).
	Jan 98  Modify to work in IDL 5.0, on the PC and Unix workstations.
			Works with new and old filename conventions.
           Uses widget to define directory and file to use for defining region
           	of interest and cannulae position
		    Should now be insensitive to image size, but this is not tested.
           Output of files should be to the same directory as where input came from.
			Uses a SAVE and RESTORE routine from a file called analysis_config.user
				to save last file name and directory used.

(See c:\idl_loc\lib\anal_tools\new_but_untested\oti_dist.pro)


PATH_FROM_NAME

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	PATH_FROM_NAME

 PURPOSE:
	Extract a file path from a full file name.

 CATEGORY:
	Analysis tool.

 CALLING SEQUENCE:

	Result = PATH_FROM_NAME(File_name)


 INPUTS:
	File_name:	File_name to extract path from

 OUTPUTS:
	This simple function returns the file path from a file name.


 RESTRICTIONS:
	Can be used on unix or windows, looks at forward and backward slashes.

 PROCEDURE:
	Simple!

 EXAMPLE:

		File_name = Path_from_name(file_path)

 MODIFICATION HISTORY:
 	Written by:	MC Crair, Jan '98

(See c:\idl_loc\lib\anal_tools\new_but_untested\path_from_name.pro)


PERCCLIP (PERCENT_CLIP)[1]

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	PERCCLIP (Percent_clip)

 PURPOSE:
	This function calculates absolute clipping values for an array so that
	PERCENT_CLIP(0)% of the values will lie below the clipping range and
	PERCENT_CLIP(1)% of the values will lie above the clipping range
	i.e. the upper clip value is in element #1 of the array PERCENT_CLIP

 CATEGORY:
	Image manipulations

 CALLING SEQUENCE:

	Result=PERCCLIP(Float_array,Clip_values)

 INPUTS:
	Float_array:	The float array for which the absolute clipping
			values for the percentiles given are to be
			calculated
	Clip_values:	The percentiles for which the absolute values should be
			calculated

 OUTPUTS:
	A float array with two values is outputted of which the 0th element
	is the lower and the 1st value the upper absolute clipping value

 COMMON BLOCKS:
	GLOBAL_SWITCH:		contains the two values for verbose and calc

 PROCEDURE:
	The input array is sorted and in this sorted array a pointer points 
	at the location where e.g. Clip_value(0) values lie 'to the left' of 
	this value. The absolute value at this location is then returned

 EXAMPLE:

	If A is an array produced by A=INDGEN(100)
	the command

	B=PERCCLIP(A,[5,5])

	produces the values B(0)=5 and B(1)=94

	NOTE: This only works if the common blocks are properly defined

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993.
	MAY, 1994, TB	Keyword verbose doesn't HAVE to be given anymore. 
				If it is omitted verbose is on.	
	MAY, 1994, TB	Sever bug removed which caused it to work only for 192x144 arrays
	AUGUST, 96, GB	Removed common block 'global_ana_vars' which was irrelevant 
				(and defined differently from analyze.pro !)	
				In addition, the common 'global_switch' is WITHOUT a variable list
				and depends now on the prior compilation of the common-defining analyze code.
	

(See c:\idl_loc\lib\oi_general\percclip.pro)


PERCCLIP (PERCENT_CLIP)[2]

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	PERCCLIP (Percent_clip)

 PURPOSE:
	This function calculates absolute clipping values for an array so that
	PERCENT_CLIP(0)% of the values will lie below the clipping range and
	PERCENT_CLIP(1)% of the values will lie above the clipping range
	i.e. the upper clip value is in element #1 of the array PERCENT_CLIP

 CATEGORY:
	Image manipulations

 CALLING SEQUENCE:

	Result=PERCCLIP(Float_array,Clip_values)

 INPUTS:
	Float_array:	The float array for which the absolute clipping
			values for the percentiles given are to be
			calculated
	Clip_values:	The percentiles for which the absolute values should be
			calculated

 OUTPUTS:
	A float array with two values is outputted of which the 0th element
	is the lower and the 1st value the upper absolute clipping value

 COMMON BLOCKS:
	GLOBAL_ANA_VARS:	which contains lots of variables which are 
				necessary for the data-analysis
	GLOBAL_SWITCH:		contains the two values for verbose and calc

 PROCEDURE:
	The input array is sorted and in this sorted array a pointer points 
	at the location where e.g. Clip_value(0) values lie "to the left" of 
	this value. The absolute value at this location is then returned

 EXAMPLE:

	If A is an array produced by A=INDGEN(100)
	the command

	B=PERCCLIP(A,[5,5])

	produces the values B(0)=5 and B(1)=94

	NOTE: This only works if the common blocks are properly defined

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993.
	MAY, 1994, TB   Keyword verbose doesn't HAVE to be given anymore. If
			it is omitted verbose is on.	
	MAY, 1994, TB	Sever bug removed which caused it to work only for 192x144 arrays

(See c:\idl_loc\lib\or_pros\percclip.pro)


PLOTFRMS[1]

[Previous Routine] [Next Routine] [List of Routines]
Name:
  plotfrms -- plots all the frames of a sumfile

PURPOSE:
  This plots all the frames of a sumfile on the monitor so that the
  user may visually check the data integrity.  They should all look pretty
  much alike.

CALLING SEQUENCE:
  plotfrms, sumfile_name

PROCEDURE
  In retrospect, the way this is coded is really stupid, and I should
  have used the associated variable technique as in binsumfile.pro
  I also have the order of storage wrong, which is
  uintarray(nconds,nframes,ysize,xsize).  This routine reforms the arays,
  wasting a lot of time.

  It is probably a good example of how even really badly or stupidly coded
  IDL programs can work well enough to be quite useful.

MODIFICATION HISTORY
  Written by Michael Stryker, 1996 sometime

(See c:\idl_loc\lib\sfo_pros\plotfrms.pro)


PLOTFRMS[2]

[Previous Routine] [Next Routine] [List of Routines]
Name:
  plotfrms -- plots all the frames of a sumfile

PURPOSE:
  This plots all the frames of a sumfile on the monitor so that the
  user may visually check the data integrity.  They should all look pretty
  much alike.

CALLING SEQUENCE:
  plotfrms, sumfile_name

PROCEDURE
  In retrospect, the way this is coded is really stupid, and I should 
  have used the associated variable technique as in binsumfile.pro
  I also have the order of storage wrong, which is 
  uintarray(nconds,nframes,ysize,xsize).  This routine reforms the arays,
  wasting a lot of time.

  It is probably a good example of how even really badly or stupidly coded 
  IDL programs can work well enough to be quite useful.

MODIFICATION HISTORY
  Written by Michael Stryker, 1996 sometime

(See c:\idl_loc\lib\sfo_pros\plotfrms.pro~)


POLARMAP

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	POLARMAP

 PURPOSE:
	This function produces a polar map from 4 or 8 input arrays
	which are the single activity maps

 CATEGORY:
	Analysis

 CALLING SEQUENCE:

	Polar_map = POLARMAP(In_maps, N, Lightness)

 INPUTS:
	In_maps:	An array of maps which must be of the format (N,header.x_size,header.y_size)
	N:		Number of maps from which the maps should be calculated. Currently only
			the values 4 and 8 are supported
	Lightness:	This paramter controls the lightness of the resulting map (0.5 is the default value)

 OUTPUTS:
	Polar_map:	An array of (2,header.x_size,header.y_size) in which the first map describes
			the angle of the resulting map and the second map the magnitude
 SIDE EFFECTS:
	MESSAGES are generated which report the errors

 RESTRICTIONS:
	Only N=4 and N=8 are supported

 EXAMPLE:

	see above

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, September 1993.
	Oct, 5. 93	Removed bug, that caused modification of passed parameter in_maps.
			Now working on a copy of in_maps !
			Changed 256 to 255 to invert in_maps !
			Speeded up by FIX instead of FLOAT and rearranged math operation.
			G. Brändle
	Oct 8, 93	Added parameter lightness to provide a possibility to control this parameter
			from the outside routines
			Tobias Bonhoeffer
	Oct 10, 93	Added keyword STEPS to provide a possibility to control the number of "hue steps"
			from the outside routines
			Tobias Bonhoeffer
	Nov 26, 93	Removed little bug that caused the lightness to have an inverted effect
			Tobias Bonhoeffer

(See c:\idl_loc\lib\or_pros\oipp\polarmap.pro)


PRINT_ORHEAD[1]

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	PRINT_ORHEAD

 PURPOSE:
	This function prints the header of a file specified by filename

 CATEGORY:
	Header functions

 CALLING SEQUENCE:

	PRINT_ORHEAD, File_name

 INPUTS:
	File_name:	A string which specifies the filename from which
			the header should be read.

 OUTPUTS:
	None


 EXAMPLE:

	Issuing the command

	Print_orhead, 'd:\or\data\072390\example.0a'

	prints all the fields in the header structure of that file

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993.
	26.12.97    Michael Stryker made into print_orheader

(See c:\idl_loc\lib\sfo_pros\do_print_orhead.pro~)


PRINT_ORHEAD[2]

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	PRINT_ORHEAD

 PURPOSE:
	This function prints the header of a file specified by filename

 CATEGORY:
	Header functions

 CALLING SEQUENCE:

	PRINT_ORHEAD, Filename=filename

 INPUTS:
       None.  
       If given with no FILENAME keyword, it invokes pickfile to let you choose a filename interactively

 KEYWORDS:
	FILENAME=filename	filename is a string which specifies the filename of an old
             optrec-style sumfile or image file or else a new ORA/OI style sumfile or image file
             from which the header should be read.

 OUTPUTS:
	None


 EXAMPLE:

	Issuing the command

	Print_orhead, FILENAME='d:\or\data\072390\example.0a'

	prints all the fields in the header structure of that file

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993.
	29.12.97    Michael Stryker made into print_orheader

(See c:\idl_loc\lib\sfo_pros\print_orhead.pro)


PRINT_ORHEAD[2]

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	PRINT_ORHEAD

 PURPOSE:
	This function prints the header of a file specified by filename

 CATEGORY:
	Header functions

 CALLING SEQUENCE:

	PRINT_ORHEAD, Filename=filename

 INPUTS:
       None.  
       If given with no FILENAME keyword, it invokes pickfile to let you choose a filename interactively

 KEYWORDS:
	FILENAME=filename	filename is a string which specifies the filename of an old
             optrec-style sumfile or image file or else a new ORA/OI style sumfile or image file
             from which the header should be read.

 OUTPUTS:
	None


 EXAMPLE:

	Issuing the command

	Print_orhead, FILENAME='d:\or\data\072390\example.0a'

	prints all the fields in the header structure of that file

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993.
	29.12.97    Michael Stryker made into print_orheader

(See c:\idl_loc\lib\sfo_pros\print_orhead.pro~)


RD_HEAD

[Previous Routine] [Next Routine] [List of Routines]
NAME:
  rd_head

PURPOSE:
  This procedure reads files with EITHER the old OPTREC or the new OI/ORA
  headers and always returns an old-format header.

  The headersize element of the returned header structure is filled in the the
  real size of the header in the input file (NOT the size of the header that
  is returned).  It can be used to point to the start of the image in the
  input file, adn to distinguish between old-style and new-style input files.

  If you are using a copy of this returned header to write an output file,
  make sure to set the headersize field to 512, since the headersize will
  otherwise be wrong for the file that you are writing.

   This program works on 3 types of files:
	sum_files (TAG=S) with ncondsXnframes of unsigned short data, and
   	analyze image files or green image files (TAG=A_01), each of which
	contains a single frame of float data.  It also does the new green
       files that contain a single fram of unsigned short data.

  The program now sets lDataType, lFileType, and lSizeOf appropriately
  for the INPUT file.  A later program (like rd_imag) may want to modify
  these values if it does a type conversion.

  The Program sets the tag field appropriately.

CATEGORY:
	conversions

CALLING SEQUENCE:

	RD_HEAD (OptrecOrORAfilename)

INPUTS:
	OptrecOrORAfilename:	A string which contains the name of the file.

KEYWORD PARAMETERS:

OUTPUTS:
	an optrec-type header

SIDE-EFFECTS:
  Also sets the headersize field and lFileType and lDataType and lSizeOf fields in header  structure

RESTRICTIONS:

PROCEDURE:
  It determines the file type by checking the header length field stored with the OI header (assumes 1716L).
  this may have to be modified if the OI/ORA header size changes.

  It determines the tag field by looking for DAT_FLOAT&IMAGEFILE or DAT_USHORT&SUMFILE or
  DAT_USHORT&IMAGEFILE, and it stops for debugging purposes if neither combination is set.
  The user can set the tag field by typing orhdr.tag=byte('A_01') and continue if
  he likes by typing .cont on the next line.

EXAMPLES:
  Header = RD_HEAD( 'd:\or\data\072390\s_031295.0a')

SEE ALSO:
  RD_IMAG  RD_ORHEAD  RD_OIHEADER

 MODIFICATION HISTORY:
 	Written by:	  Michael Stryker, 28 Dec 97

(See c:\idl_loc\lib\forora\rd_head.pro)


RD_IMAG

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	rd_imag

 PURPOSE:
	This function reads image files in either the old optrec or
       new ORA/OI format and and uses
	the header to return a float_array of the proper size

 CATEGORY:
	File functions

 CALLING SEQUENCE:

	Image=rd_imag(File_name)

 INPUTS:
	File_name:	A string which specifies the file_name from which the
			image should be read

 OUTPUTS:
	This function produces a float array of the proper dimensions
	which contains the image data

 EXAMPLE:

	The command

	Image=rd_imag('d:\or\data\072390\example.0a')

	produce a float array called Image which contains
	the image data.

SEE ALSO:
  RD_HEAD  RD_ORHEAD  RD_OIHEADER

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993.
	June, 1993:	Little reformatting and speeding up (/NOZERO) !
			Gerhard Braendle
	20.09.93	Now with @orheader.inc GB
   28 Dec 1997  Michael Stryker
        Added Call to rd_head to make it work with both the old
        optrec and new OI/ORA files.

  25 Mar 98:  Now works properly with the green unsigned short images
              Michael Stryker

(See c:\idl_loc\lib\forora\rd_imag.pro)


RD_INI

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	RD_INI

 PURPOSE:
	This function reads an .ini file which conforms to the Windows conventions
	and extracts the desired information from it

 CATEGORY:
	File functions

 CALLING SEQUENCE:
	Result = RD_INI(Filename, Section, Item)

 INPUTS:

	Filename:	The .ini file which should be checked

	Section:	The section iun the .ini file which should be checked

	Item:		The item of which the value should be returned

 OUTPUTS:
	This function returns a string which contains the value of the item that was requested

 EXAMPLE:
	Result = RD_INI('or.ini','general','current_user')

	returns the current_user which is stored in the or.ini file located in the windows subdirectory

 KNOWN BUGS:
	Doesn't totally conform with the windows ini-file structure. For instance, currently
	only equal signs (=) are allowed for definition and not colons (:)

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, January 1994
	February, 1994	Windows directory is detected		TB
	February, 1994	Removed some bugs 			GB
	July,     1994  changed backslash to slash for UNIX compatibility TB
	July,     1994  changed to lower case for UNIX compatibility TB
   February, 1999  changed to use /tmp as base for storage MPS

(See c:\idl_loc\lib\or_pros\rd_ini.pro)


RD_OIFR1

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	RD_OIFR1

 PURPOSE:
	This function reads the *first* frame of the *first* condition of the specified file 
	and returns this frame. 

 CATEGORY:
	OI file functions

 CALLING SEQUENCE:

	frame = RD_OIFR1(filename)

 INPUTS:
	filename:	A string which specifies the filename of an *existing* OI data file.

 OUTPUTS:
	The first frame in the file is returned as an array. The format and size of the array is 
	as specified in the data files header. A scalar is returned if an error occurred.

 EXAMPLE:

	Issuing the command

	frame = rd_oifr1('d:\or\data\072390\example.0a')

	will produce a named array 'frame' which contains the first frame (condnum=0, framenum=0) 
	of OI data file 'd:\or\data\072390\example.0a'.

 MODIFICATION HISTORY:
 	Written by:	Gerhard Braendle, August 1996.

(See c:\idl_loc\lib\oi_general\rd_oifr1.pro)


RD_OIFRX

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	RD_OIFRX

 PURPOSE:
	This function reads the frame at position 'condition number' and 'frame number' of
	the file with the LUN 'lun'. The frame is returned with the same data type as 
	specified in the header. 
	Note: As IDL does not understand unsigned data types, those are returned as signed.
	The header passed is used to extract (quickly) some important data for the computation of frame
	positions and for validation purpouse.

 CATEGORY:
	OI data functions

 CALLING SEQUENCE:

	frame = RD_OIFRX(lun, header, condnum, fnum)

 INPUTS:
	lun:		A LUN of the opened data file, which the frame will be read from.
	header:	The header of *this* data file (used to compute positions and to check stuff).
			Note: For performance reasons, the header is *not* read again and therfore has 
				to be provided as a parameter !
	condnum:	The condition number of the frame (zero-based!).
	fnum:		The frame number of the frame (zero-based!).

 OUTPUTS:
	The function returns the specified frame with the appropriate dimensions and data types,
	or a scalar error number.

 EXAMPLE:

	Issuing the command

	frame = RD_OIFRX(lun, header, condnum, fnum)

	returns the frame at position 'condnum', 'fnum' of the file that has been opened
	before with LUN 'lun'. The additional parameter 'header' helps to speed up the operation
	as the header must not be read in from the data file again.
	If the function returns a scalar, an error occurred.

 MODIFICATION HISTORY:
 	Written by:	Gerhard Braendle, August 1996.

(See c:\idl_loc\lib\oi_general\rd_oifrx.pro)


RD_OIHDR

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	RD_OIHDR

 PURPOSE:
	This function returns the OI header of a file specified by filename

 CATEGORY:
	OI header functions

 CALLING SEQUENCE:

	header = RD_OIHDR(filename, VERSION=ver)

 INPUTS:
	filename:	A string which specifies the filename from which
			the header should be read.

 KEYWORDS:
	VERSION	The header version number. The routine returns 0 and prints an error message
			if this number is not the same as in the header !

 OUTPUTS:
	A structure which contains the header information or a scalar error number is returned.
	Note: The error value is the one that was returned by the OPENR function (see also !ERR_STRING)

 EXAMPLE:

	Issuing the command

	header=rd_oihdr('d:\or\data\072390\example.0a', VERSION=101)

	produces a structure named 'header' which contains the information
	from the OI header (see oiheader.inc) of the file d:\or\data\072390\example.0a
	If the header version is NOT 101, a scalar 0 is returned and en error message is printed.

 MODIFICATION HISTORY:
 	Written by:	Gerhard Braendle, July 1996.
	22.08.96/GB	Added VERSION KEYWORD to check header version.

(See c:\idl_loc\lib\oi_general\rd_oihdr.pro)


RD_ORHEAD

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	RD_ORHEAD

 PURPOSE:
	This function returns the header of a file specified by filename

 CATEGORY:
	Header functions

 CALLING SEQUENCE:

	Result=RD_ORHEAD(File_name)

 INPUTS:
	File_name:	A string which specifies the filename from which
			the header should be read.

 OUTPUTS:
	A structure which contains the header information is returned


 EXAMPLE:

	Issuing the command

	Header=rd_orhead('d:\or\data\072390\example.0a')

	produces a structure named Header which contains the information
	from the header of the file d:\or\data\072390\example.0a

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993.
	18.6.1993       Very little reformatting (header). GB
	20.09.93	Now with @orheader.inc GB
	28.02.95	hi_pass and lo_pass added to the header TB, MH, IG

(See c:\idl_loc\lib\forora\rd_orhead.pro)


RD_ORIMAG

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	RD_ORIMAG

 PURPOSE:
	This function reads image files and and uses
	the header to produce float_arrays of the proper size

 CATEGORY:
	File functions

 CALLING SEQUENCE:

	Image=RD_ORIMAG(File_name)

 INPUTS:
	File_name:	A string which specifies the file_name from which the
			image should be read

 OUTPUTS:
	This function produces a float array of the proper dimensions
	which contains the image data

 EXAMPLE:

	The command

	Image=R_ORIMAG('d:\or\data\072390\example.0a')

	produce a float array called Image which contains
	the image data.

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993.
	June, 1993:	Little reformatting and speeding up (/NOZERO) !
			Gerhard Braendle
	20.09.93	Now with @orheader.inc GB

(See c:\idl_loc\lib\forora\rd_orimag.pro)


ROUTINE_NAME

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	ROUTINE_NAME

 PURPOSE:
	Tell what your routine does here.  I like to start with the words:
	"This function (or procedure) ..."
	Try to use the active, present tense.

 CATEGORY:
	Put a category (or categories) here.  For example:
	Widgets.

 CALLING SEQUENCE:
	Write the calling sequence here. Include only positional parameters
	(i.e., NO KEYWORDS). For procedures, use the form:

	ROUTINE_NAME, Parameter1, Parameter2, Foobar

	Note that the routine name is ALL CAPS and arguments have Initial
	Caps.  For functions, use the form:
 
	Result = FUNCTION_NAME(Parameter1, Parameter2, Foobar)

	Always use the "Result = " part to begin. This makes it super-obvious
	to the clueless user that this routine is a function!

 INPUTS:
	Parm1:	Describe the positional input parameters here. Note again
		that positional parameters are shown with Initial Caps.

 OPTIONAL INPUTS:
	Parm2:	Describe optional inputs here. If you don't have any, just
		delete this section.
	
 KEYWORD PARAMETERS:
	KEY1:	Document keyword parameters like this. Note that the keyword
		is shown in ALL CAPS!

	KEY2:	Yet another keyword. Try to use the active, present tense
		when describing your keywords.  For example, if this keyword
		is just a set or unset flag, say something like:
		"Set this keyword to use foobar subfloatation. The default
		 is foobar superfloatation."

 OUTPUTS:
	Describe any outputs here.  For example, "This function returns the
	foobar superflimpt version of the input array."  This is where you
	should also document the return value for functions.

 OPTIONAL OUTPUTS:
	Describe optional outputs here.  If the routine doesn't have any, 
	just delete this section.

 COMMON BLOCKS:
	BLOCK1:	Describe any common blocks here. If there are no COMMON
		blocks, just delete this entry.

 SIDE EFFECTS:
	Describe "side effects" here.  There aren't any?  Well, just delete
	this entry.

 RESTRICTIONS:
	Describe any "restrictions" here.  Delete this section if there are
	no important restrictions.

 PROCEDURE:
	You can describe the foobar superfloatation method being used here.
	You might not need this section for your routine.

 EXAMPLE:
	Please provide a simple example here. An example from the PICKFILE
	documentation is shown below.

	Create a PICKFILE widget that lets users select only files with 
	the extensions 'pro' and 'dat'.  Use the 'Select File to Read' title 
	and store the name of the selected file in the variable F.  Enter:

		F = PICKFILE(/READ, FILTER = ['pro', 'dat'])

 MODIFICATION HISTORY:
 	Written by:	Your name here, Date.
	July, 1994	Any additional modifications will be described here.

(See c:\idl_loc\lib\read_me\hd_templ.pro)


SAV_IMAG

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	SAV_IMAG

 PURPOSE:
	This procedure saves float_arrays to image files,
	also writing the provided header into the same file.

 CATEGORY:
	File functions

 CALLING SEQUENCE:

	SAV_IMAG,Float_array,File_name,Header

 INPUTS:
	Float_array:	The float array which should be stored
			in the file
	File_name:	A string which specifies the file_name under
			which the image should be stored
	Header:		A structure that be included as header for these
			data

 OUTPUTS:
	None

 SIDE EFFECTS:
	A file named File_name which contains the float array and the
	header is produced

 EXAMPLE:

	The command

	SAV_IMAG,Image,'d:\or\data\072390\example.0a',Header

	saves the float array Image together with Header under the
	name d:\or\data\072390\example.0a

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993.
	MAY, 1994, TB   Keyword verbose doesn't HAVE to be given anymore. If
			it is omitted verbose is on.
   February 1999 added line header.headersize = 512

(See c:\idl_loc\lib\or_pros\sav_imag.pro)


SET_BIT

[Previous Routine] [Next Routine] [List of Routines]
 NAME:	
	SET_BIT

 PURPOSE:
	This function sets the bit at position Bitpos in value Value
	and returns the modified Value.

 CATEGORY:
	Low level function for bit operations

 CALLING SEQUENCE:
	Result = SET_BIT(Value, Bitpos)

 INPUTS:

	Value:		Integer (1, 2 or 4 byte) scalar or array.

	Bitpos:		Integer value (valid range: [0-31]) defining the bit position to
 			be set to 1 in 'Value'.
			NOTE: Bitpos counting starts with 0 !

 OUTPUTS:
	This function returns the modified value(s) with the bit at Bitpos set to 1.

 RESTRICTIONS:
	Does not work with data types of Value other than integer.

 EXAMPLE:
	The instruction:
		a=2
		b= SET_BIT(a, 3)
	returns 10, that is assigned to b.

	Now with a vector:
		vec=	[21, 195, 13]
		modvec=	SET_BIT(vec, 1)
	results in modvec=[23,195,15].
	

 MODIFICATION HISTORY:
 	Written by:	Gerhard Brändle, 21.7.93.
	Month, Year	Any additional mods get described here.  

(See c:\idl_loc\lib\or_pros\set_bit.pro)


SFILE_TO_ARRAY[1]

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	SFILE_TO_ARRAY

 PURPOSE:
	This function reads image files in either the old optrec or
       new ORA/OI format and and uses
	the header to return a float_array of the proper size

 CATEGORY:
	File functions

 CALLING SEQUENCE:

	Image=SFILE_TO_ARRAY(File_name)

 INPUTS:
	File_name:	A string which specifies the file_name from which the
			image should be read

 OUTPUTS:
	This function produces a float array of the proper dimensions
	which contains the image data

 EXAMPLE:

	The command

	Image=SFILE_TO_ARRAY('d:\or\data\072390\example.0a')

	produce a float array called Image which contains
	the image data.

SEE ALSO:
  RD_HEAD  RD_ORHEAD  RD_OIHEADER

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993.
	June, 1993:	Little reformatting and speeding up (/NOZERO) !
			Gerhard Braendle
	20.09.93	Now with @orheader.inc GB
   28 Dec 1997  Michael Stryker
        Added Call to rd_head to make it work with both the old
        optrec and new OI/ORA files.

  25 Mar 98:  Now works properly with the green unsigned short images
              Michael Stryker

(See c:\idl_loc\lib\anthony\sfile_to.pro)


SFILE_TO_ARRAY[2]

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	SFILE_TO_ARRAY

 PURPOSE:
	This function reads image files in either the old optrec or
       new ORA/OI format and and uses
	the header to return a float_array of the proper size

 CATEGORY:
	File functions

 CALLING SEQUENCE:

	Image=SFILE_TO_ARRAY(File_name)

 INPUTS:
	File_name:	A string which specifies the file_name from which the
			image should be read

 OUTPUTS:
	This function produces a float array of the proper dimensions
	which contains the image data

 EXAMPLE:

	The command

	Image=SFILE_TO_ARRAY('d:\or\data\072390\example.0a')

	produce a float array called Image which contains
	the image data.

SEE ALSO:
  RD_HEAD  RD_ORHEAD  RD_OIHEADER

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993.
	June, 1993:	Little reformatting and speeding up (/NOZERO) !
			Gerhard Braendle
	20.09.93	Now with @orheader.inc GB
   28 Dec 1997  Michael Stryker
        Added Call to rd_head to make it work with both the old
        optrec and new OI/ORA files.

  25 Mar 98:  Now works properly with the green unsigned short images
              Michael Stryker

(See c:\idl_loc\lib\anthony\sfile_to_array.pro)


SHRINKFL

[Previous Routine] [Next Routine] [List of Routines]
procedure SHRINKFL
this procedure shrinks a file to an integral fraction of its original size
 designed to make the green files displayable with oidp, etc
 normally called shrinkfl,2,greenfile,greenfile+'s'

 Michael Stryker, Feb1, 1996

(See c:\idl_loc\lib\sfo_pros\oldsuperpix.mps\shrinkfl.pro)


SIMILARITY

[Previous Routine] [Next Routine] [List of Routines]
NAME:    similarity index

  See the description for COMPUTE_CC in compute_cc.pro
 

(See c:\idl_loc\lib\anal_tools\crosscorrelate\similarity.pro)


STICKPLOT

[Previous Routine] [Next Routine] [List of Routines]
STICKPLOT makes a stick contour map from orientation angle, polar, or hls maps.
		Output file is named the same as the input file  with '.ps' appended by default

Parameters [default value]:
 MAPFILE=the input file (24-bit TIFF file, hue=orientation*2:  ie, 0=360 deg)
 TEMPLATE=if present, a 0-1 mask for the computation and display, in optrec rd_imag form
 /SHOWVALUE sticks indicate the preferred orientation, with length of the sticks indicating
       the coherence of orientation among the points averaged (set by radius).
 		Default behavior (without /showvalue) is to plot the iso-value contour lines
 /USEPOLAR = set if mapfile is a polar map and you want line length to reflect tuning
 /USEHLS = set if mapfile is an hls map and you want line blackness or greyscale
		to reflect response	strength.  This is not yet done; and this option is now the same as /usepolar.
 NABERADIUS=[2 -> 5X5 square for analysis] Typically 2/3 of RADIUS value
 RADIUS=[3 radius for analysis of local orientation contours] analysis is done using
		actual radial distance, but only within a square of naberadius size.  Noisier maps
		require larger radius values, and correspondingly larger naberadius.
    	Computation is more nearly exact is naberadius > radius, but is slower.
 LINELENGTH=[.5] controls the length of the stick-contour lines
 PLOTSKIP=[4] number of pixels in the original mapfile skipped between drawn contour lines
 MAG=[4] Controls the size of the image on the screen, but not the postscript file
 OUTIMAGE=


 Future enhancements will make it do contour maps of OD images (lifting code from aslope.pro)

 For hls maps, use a grey scale to indicate responsiveness, and the black bars inside a
 thicker white bar to indicate orientation, and the length of the bar to indicate
 selectivity (as in polar map).

(See c:\idl_loc\lib\anal_tools\stickplot.pro)


STICKPLOT_NEW

[Previous Routine] [Next Routine] [List of Routines]
STICKPLOT makes a stick contour map from orientation angle, polar, or hls maps.
		Output file is named the same as the input file  with '.ps' appended by default

Parameters [default value]:
 MAPFILE=the input file (24-bit TIFF file, hue=orientation*2:  ie, 0=360 deg)
 TEMPLATE=if present, a 0-1 mask for the computation and display, in optrec rd_imag form
 /SHOWVALUE sticks indicate the preferred orientation, with length of the sticks indicating
       the coherence of orientation among the points averaged (set by radius).
 		Default behavior (without /showvalue) is to plot the iso-value contour lines
 /USEPOLAR = set if mapfile is a polar map and you want line length to reflect tuning
 /USEHLS = set if mapfile is an hls map and you want line blackness or greyscale
		to reflect response	strength.  This is not yet done; and this option is now the same as /usepolar.
 NABERADIUS=[2 -> 5X5 square for analysis] Typically 2/3 of RADIUS value
 RADIUS=[3 radius for analysis of local orientation contours] analysis is done using
		actual radial distance, but only within a square of naberadius size.  Noisier maps
		require larger radius values, and correspondingly larger naberadius.
    	Computation is more nearly exact is naberadius > radius, but is slower.
 LINELENGTH=[.5] controls the length of the stick-contour lines
 PLOTSKIP=[4] number of pixels in the original mapfile skipped between drawn contour lines
 MAG=[4] Controls the size of the image on the screen, but not the postscript file
 OUTIMAGE=the name of an image to place under the sticks in the postscript output file
 OUTRGB=[0,0,0] RGB triplet vector for the color of the sticks in the postscript output file.


 Future enhancements will make it do contour maps of OD images (lifting code from aslope.pro)

 For hls maps, use a grey scale to indicate responsiveness, and the black bars inside a
 thicker white bar to indicate orientation, and the length of the bar to indicate
 selectivity (as in polar map).

(See c:\idl_loc\lib\anal_tools\stickplot_new.pro)


STR2STR

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	STR2STR

 PURPOSE:
	Insert String2 into String1 at position Pos (position count starts with 0 !).
	If String1 is too short to keep the result, String1 is expanded.
	String2 overwrites String1 !

 CATEGORY:
	STRING

 CALLING SEQUENCE:
	Result = STR2STR(String1, String2, Pos)

 INPUTS:
	String1:	Initial string to have String2 inserted at position Pos.

	String2:	This string will be inserted into String1 at position Pos.

	Pos:		The position, where String2 is inserted into String1.

	
 OUTPUTS:
	This function returns the original String1 with String2 inserted at position Pos.

 RESTRICTIONS:
	Does not work with string arrays !

 EXAMPLE:
	The following code:
		newstring= str2str('This is the original string !', 'was', 5)
 		print, newstring
	produces this output:
		This wasthe original string !


 MODIFICATION HISTORY:
 	Written by:	Gerhard Brändle, 27. July 1993
	Month, Date	Any additional modifications will be described here.

(See c:\idl_loc\lib\or_pros\str2str.pro)


STRINS

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	STRINS

 PURPOSE:
	This function inserts (insert instead of overwrite) a 
	given string at the given position

 CATEGORY:
	String manipulations

 CALLING SEQUENCE:
 
	Result = STRINS(Source_string, Insert_string, Position)

 INPUTS:

	Source_string:		String in which insertion should be made

	Insert_string:		String which is to be inserted

	Position:		Position at which the insertion should take place

 OUTPUTS:
	This function retruns a composite string in which the Insert_string 
	was inserted into the Source_string at Position

 EXAMPLE:

	If A contains "IDL a bitch" and B contains "is " a
	string C containing "IDL is a bitch" can be created by 
	the following command:

	C=STRINS(A,B,5)

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, May, 93.
	July, 1994	Any additional mods get described here.  Remember to
			change the stuff above if you add a new keyword or
			something!

(See c:\idl_loc\lib\or_pros\strins.pro)


STRPARSE

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	STRPARSE

 PURPOSE:
	This function parses an in_string for delimiters of one type.
	the resulting single elements are put as the elements of a strarr

 CATEGORY:
	String manipulations

 CALLING SEQUENCE:
	Result = STRPARSE(In_string,Delimiter)

 INPUTS:

	In_string:	The string which should be parsed

	Delimiter:	The Delimiter by which the substrings are spearated


 OUTPUTS:
	This function returns an array of strings which contains the single
	substrings which were separated by the Delimiter in the original 
	In-string

 EXAMPLE:
	If A contains "IDL is a bitch" and B contains " " an 
	strarr C ['IDL','is','a','bitch'] can be created by 
	the following command:

	C=STRPARSE(A,B)

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, February 1993
	July, 1994	Any additional mods get described here.  

(See c:\idl_loc\lib\or_pros\strparse.pro)


STRRPLC

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	STRRPLC

 PURPOSE:
	This function takes in_string and replaces old_string with new_string

 CATEGORY:
	String manipulations

 CALLING SEQUENCE:
 
	Result = STRRPLC(In_string,Old_string, New_string)

 INPUTS:

	In_string:	The string in which the operation should be performed

	Old_string:	Substring which is to be replaced

	New_string:	Substring which is replacing Old_string


 OUTPUTS:
	This function returns a string in which Old_string
	is replaced by New_string

 EXAMPLE:
	If A contains "IDL was a bitch", B contains "was" 
	and C contains "is" a string D containing 
	"IDL is a bitch" can be produced by the command

	D=STRRPLC(A,B,C)

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, February 1993
	July, 1994	Any additional mods get described here.  

(See c:\idl_loc\lib\or_pros\strrplc.pro)


TB_PICKF

[Previous Routine] [Next Routine] [List of Routines]
 NAME: 
       TB_PICKF 
 
 PURPOSE: 
       This function allows the user to interactively pick a file.  A file 
       selection tool with a graphical user interface is created.  Files 
       can be selected from the current directory or other directories. 
	THIS IS A MODIFIED PICKFILE PROCEDURE (MODIFIED BY TOBIAS BONHOEFFER, APRIL 95)
	WHICH ALLOWS TO RETURN ALSO FILENAMES WITH WILDCARDS. THIS IS NECESSARY
	FOR THE OI ANALYSIS PROGRAMS
 
 CATEGORY: 
       Widgets. 
 
 CALLING SEQUENCE: 
       Result = PICKFILE() 
 
 KEYWORD PARAMETERS: 
 
       FILE:   A string value for setting the initial value of the 
               selection. Useful if there is a default file 
 
       GET_PATH: Set to a named variable. Returns the path at the 
               time of selection. 
 
       GROUP:  The widget ID of the widget that calls PICKFILE.  When this 
               ID is specified, a death of the caller results in the death of 
               the PICKFILE widget application. 
 
       READ:   Set this keyword to make the title of the PICKFILE window  
               "Select File to Read". 
 
       WRITE:  Set this keyword to make the title of the PICKFILE window  
               "Select File to Write". 
 
       PATH:   The initial path to select files from.  If this keyword is  
               not set, the current directory is used. 
 
       FILTER: A string value for filtering the files in the file list.  This 
               keyword is used to reduce the number of files to choose from. 
               The user can modify the filter unless the FIX_FILTER keyword 
               is set.  Example filter values might be "*.pro" or "*.dat". 
 
       FIX_FILTER: When this keyword is set, only files that satisfy the 
               filter can be selected.  The user has no ability to modify 
               the filter and the filter is not shown. 
 
       TITLE:  A scalar string to be used for the window title.  If it is 
               not specified, the default title is "Select File" 
 
       NOCONFIRM: Return immediately upon selection of a file.  The default 
               behavior is to display the selection and then return the 
               file when the user uses the "ok" button. 
 
       MUST_EXIST: When set, only files that actually exist can be selected. 
 
 OUTPUTS: 
       PICKFILE returns a string that contains the name of the file selected. 
       If no file is selected, PICKFILE returns a null string. 
 
 COMMON BLOCKS: 
       PICKER: COMMON block that maintains state for the widget. 
 
 SIDE EFFECTS: 
       This function initiates the XMANAGER if it is not already running. 
 
 RESTRICTIONS: 
       This routine is known to work on Suns (OPEN LOOK), MIPS, RS/6000,  
       DEC Ultrix, HP/700, VAX/VMS and SGI machines. 
 
       Only one instance of the PICKFILE widget can be running at one time. 
 
       PICKFILE does not recognize symbolic links to other files in UNIX. 
 
 PROCEDURE: 
       Create and register the widget and then exit, returning the filename 
       that was picked. 
 
 EXAMPLE: 
       Create a PICKFILE widget that lets users select only files with  
       the extensions 'pro' and 'dat'.  Use the 'Select File to Read' title  
       and store the name of the selected file in the variable F.  Enter: 
 
               F = PICKFILE(/READ, FILTER = '*.pro *.dat') 
 
 MODIFICATION HISTORY: 
       Written by:     Steve Richards, April, 1991 
       July, 1991      Added a FILTER keyword to allow users 
                       to select files with a given extension or  
                       extensions. 
       August, 1991    Fixed bugs caused by differences between 
                       spawned ls commands on different machines. 
       September, 1991 Made Myfindfile so only one pass was 
                       necessary to find files and directories. 
       3/92 - ACY      Corrected initialization of dirsave, change spawn 
                       command to "ls -lL" and added case for links 
                       add NOCONFIRM keyword for auto exiting on selection 
       8/92 - SMR      Rewrote pickfile as a compound widget. 
       10/92 - SMR     Fixed a bug where extremely large file namess didn't 
                       show up properly in the file list or as return 
                       values. 
       12/92 - JWG     Add better machine dependency code 
       1/93 - JWG      Added FILE, GET_PATH keywords. 
       1/93 - TAC      Added Windows Common dialog pickfile code 
       2/93 - SMR      Fixed the documentation example for multiple extensions
       1/94 - KDB      If directory had no execute permission on Unix  
                       platforms, CD fails and causes error. Added check 
                       for this. Increased spawn speed by using /sh for unix. 
                       Added -a switch to ls so that all files can be found  
                       on unix machines. 
       2/94 - KDB	Values passed to CD cannot end in a '\' on DOS 
			platforms. Program would crash if the PATH keyword
			was supplied a value that ended with a "\". Added
		        a check for this.
	3/94 - BMH	Deleted the reference here to OS_PICKFILE for the
			Unix platforms and created an IDL routine to 
			to call the Mac and Windows specific OS_PICKFILE 
			routines.  This solved the saving and restoring on
	 		different platforms problem.
	4/94 - KDB      The vms call to lib$findfile in valid_dir was
		        commented out. This caused errors when path was
			changed by user. Uncommented. In Valid_Dir, with
			vms the type of directory specification was not
		        checked (directory can be a path or a filename):
			Fixed this. In dirlist section of event handler,
		        a "[-]" would get trimmed to "" and cause error:
			Fixed.
	4/95 - TB	AS DESCRIBED ABOVE

(See c:\idl_loc\lib\or_pros\tb_pickf.pro)


UNSGNCVT (UNSIGNED_CONVERT)

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	UNSGNCVT (unsigned_convert)

 PURPOSE:
	This function converts an array of unsigned integers into an array of longs
	(It should be replaced by a C-program as soon as possible since it is not
	very effective)
	
 CATEGORY:
	Conversions

 CALLING SEQUENCE:
	Result = UNSGNCVT(In_arr)

 INPUTS:

	In_array:	The input array containing unsigned integers


 OUTPUTS:
	This function returns an array of longs containing the same numbers 
	as in the in_array of unsigned integers.

 COMMON BLOCKS:
	TMP,outarr
	
	in order to save space

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993
	July, 1994	Any additional mods get described here.  

(See c:\idl_loc\lib\or_pros\unsgncvt.pro)


USET_BIT

[Previous Routine] [Next Routine] [List of Routines]
 NAME:	
	USET_BIT

 PURPOSE:
	This function unsets the bit at position Bitpos in value Value
	and returns the modified Value.

 CATEGORY:
	Low level function for bit operations

 CALLING SEQUENCE:
	Result = USET_BIT(Value, Bitpos)

 INPUTS:

	Value:		Integer (1, 2 or 4 byte) scalar or array.

	Bitpos:		Integer value (valid range: [0-31]) defining the bit position to
 			be set to 0 in 'Value'.
			NOTE: Bitpos counting starts with 0 !

 OUTPUTS:
	This function returns the modified value(s) with the bit at Bitpos set to 0.

 RESTRICTIONS:
	Does not work with data types of Value other than integer.

 EXAMPLE:
	The instruction:
		a=7
		b= USET_BIT(a, 2)
	returns 3, that is assigned to b.

	Now with a vector:
		vec=	[21, 195, 13]
		modvec=	USET_BIT(vec, 1)
	results in modvec=[21,193,13].
	

 MODIFICATION HISTORY:
 	Written by:	Gerhard Brändle, 22.7.93.
	Month, Year	Any additional mods get described here.  

(See c:\idl_loc\lib\or_pros\uset_bit.pro)


UTOLARRAY -- OBSOLETE UNSIGNED INTEGER ARRAY TO LONG CONVERSION

[Previous Routine] [Next Routine] [List of Routines]
NAME:
  utolarray -- OBSOLETE unsigned integer array to long conversion

PURPOSE:
  UTOLARRAY converts an unsigned integer (16-bit) array to the signed
  long (32-bit) type.

 THIS ROUTINE WAS MADE OBSOLETE BY THE NEW UINT DATA TYPE IN IDL 5.2

  IDL lacks an unsigned integer type, but our sumfiles are stored as
  16-bit unsigned integers.  IDL naturally reads the sumfiles as signed
  integers, making the large values negative.  To do arithmetic on these
  unsigned integer arrays, we need to convert them to signed long arrays.
  This routine does the appropriate  conversion efficiently (more or less).

  To store a sumfile or unsigned int array, we have a routine that does
  the reverse conversion, ltouarray.

CATEGORY:
  conversions

CALLING SEQUENCE:

  utolarray(uarray)

INPUTS:
  uarray:  an array of unsigned ints (16-bit numbers, 0-2^16)

KEYWORD PARAMETERS:
  none

OUTPUTS:
  a long array (32-bit signed) of the same values


EXAMPLES:
  larray = utolarray(uarray)

SEE ALSO:
  LTOUARRAY

 MODIFICATION HISTORY:
       Written by:       Michael Stryker, 28 Dec 97

(See c:\idl_loc\lib\sfo_pros\utolarray.pro)


UTOLARRAY -- UNSIGNED INTEGER ARRAY TO LONG CONVERSION

[Previous Routine] [Next Routine] [List of Routines]
NAME:
  utolarray -- unsigned integer array to long conversion

PURPOSE:
  UTOLARRAY converts an unsigned integer (16-bit) array to the signed
  long (32-bit) type.

  IDL lacks an unsigned integer type, but our sumfiles are stored as
  16-bit unsigned integers.  IDL naturally reads the sumfiles as signed
  integers, making the large values negative.  To do arithmetic on these
  unsigned integer arrays, we need to convert them to signed long arrays.
  This routine does the appropriate  conversion efficiently (more or less).

  To store a sumfile or unsigned int array, we have a routine that does
  the reverse conversion, ltouarray.

CATEGORY:
  conversions

CALLING SEQUENCE:

  utolarray(uarray)

INPUTS:
  uarray:  an array of unsigned ints (16-bit numbers, 0-2^16)

KEYWORD PARAMETERS:
  none

OUTPUTS:
  a long array (32-bit signed) of the same values


EXAMPLES:
  larray = utolarray(uarray)

SEE ALSO:
  LTOUARRAY

 MODIFICATION HISTORY:
       Written by:       Michael Stryker, 28 Dec 97

(See c:\idl_loc\lib\sfo_pros\utolarray.pro~)


VERIFY_FRAMES

[Previous Routine] [Next Routine] [List of Routines]
Name:
   verify_frames -- verifies that all the frames of a sumfile are pretty similar

PURPOSE:
  This plots all the frames of a sumfile on the monitor so that the
  user may visually check the data integrity.  They should all look pretty
  much alike.

CALLING SEQUENCE:
  verify_frames, file=file, DIFFTHRESHOLD=diffthreshold

PROCEDURE


MODIFICATION HISTORY
  Written by Michael Stryker, 1996 sometime

(See c:\idl_loc\lib\sfo_pros\verify_frames.pro)


WHATTYPE

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	WHATTYPE

 PURPOSE:
	This function checks and returns the type code of if its param

 CATEGORY:
	General purpouse procedure

 CALLING SEQUENCE:
	typecode = WHATTYPE(variable)

 INPUTS:
	variable:	Any kind of variable

 OUTPUTS:
	Nothing

 EXAMPLE:
	typecode = WHATTYPE(testvar)

	Depending on the type of testvar, typecode is set to one of
	the following scalar values (see IDL Size()):

	Type Code	Data Type
     --------------------------------------
	0		Undefined
	1		Byte
	2		Integer
	3		Longword integer
	4		Floating point
	5		Double-precision floating
	6		Complex floating
	7		String
	8		Structure
	9		Double-precision complex



 MODIFICATION HISTORY:
 	Written by:	Gerhard Braendle, August, 96.

(See c:\idl_loc\lib\oi_general\whattype.pro)


WRI_HEAD

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	WRI_HEAD

 PURPOSE:
	This procedure replaces the header of a file specified by filename.

 CATEGORY:
	Header functions

 CALLING SEQUENCE:

	WRI_HEAD, File_name, Header

 INPUTS:
	File_name:	A string which specifies the filename into which 
			the new header should be written.
	Header:		A structure which contains the header information
			NOTE: This structure must have the correct format

 OUTPUTS:
	None

 SIDE EFFECTS:
	A changed file with the provided file_name is produced.

 RESTRICTIONS:
	No checking of the correct format of the structure Header is done

 EXAMPLE:

	Replacing the header in the file d:\or\data\072390\example.0a with
	New_header is done 
	wri_head, 'd:\or\data\072390\example.0a', New_header

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993.
	July, 1994      Any additional modifications are described here.

(See c:\idl_loc\lib\or_pros\wri_head.pro)


WR_OIFR1

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	WR_OIFR1

 PURPOSE:
	This function overwrites the *first* frame of the *first* condition in the specified file with a new frame.

 CATEGORY:
	OI file functions

 CALLING SEQUENCE:

	ok =	WR_OIFR1(filename, frame)

 INPUTS:
	filename:	A string which specifies the filename of an *existing* OI data file.
	frame:	A frame that will replace the first frame in the data file.

 OUTPUTS:
	The first frame in the file is overwritten with the frame that was passed to this routine in 
	the command line. The format and size of the frame array must be compatible with the data files 
	frames. If the functions returns a scalar 0, the frame was written successfully.
	A nonzero value is returned if an error occurred.
	Note: The error value is the one that was returned by the OPENW function.
           See !ERR_STRING for further information.


 EXAMPLE:

	Issuing the command

	ok =	wr_oifr1('d:\or\data\072390\example.0a', frame)

	will overwrite the *first* frame of the *first* condition of the 
	OI data file 'd:\or\data\072390\example.0a' with array 'frame'.
	A scalar 0 is returned if the frame was written successfully.

 MODIFICATION HISTORY:
 	Written by:	Gerhard Braendle, August 1996.

(See c:\idl_loc\lib\oi_general\wr_oifr1.pro)


WR_OIFRX

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	WR_OIFRX

 PURPOSE:
	This function overwrites the frame at position 'condition number' and 'frame number' of
	the file with the LUN 'lun' with the frame 'frame' (byte, short, long or float).
	The passed header is used to extract quickly some important data for the computation of frame
	positions and for validation purpouse.

 CATEGORY:
	OI data functions

 CALLING SEQUENCE:

	ret = WR_OIFRX(lun, header, condnum, fnum, frame)

 INPUTS:
	lun:		A LUN of the opened data file to which the frame will be writte to.
	header:	The header of *this* data file (used to compute positions and to check stuff).
			Note: For performance reasons, the header is *not* read again and therfore has
				to be provided as a parameter !
	condnum:	The condition number of the frame (zero-based!).
	fnum:		The frame number of the frame (zero-based!).
	frame:	The frame data itself.

 OUTPUTS:
	The function returns 0 if OK, else error number of the file-open function OPENU (see also !ERR_STRING)

 EXAMPLE:

	Issuing the command

	ret = WR_OIFRX(lun, header, condnum, fnum, frame)

	writes the frame 'frame' to the position 'condnum', 'fnum' of the file that has been opened
	before with LUN 'lun'. The additionl parameter 'header' helps to speed up the operation
	as the header must not be read in from the data file again.
	If the functions returns a scalar 0, the data 'frame' was written successfully.
	A nonzero value is returned if an error occurred.

 MODIFICATION HISTORY:
 	Written by:	Gerhard Braendle, August 1996.

(See c:\idl_loc\lib\oi_general\wr_oifrx.pro)


WR_OIHDR

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	WR_OIHDR

 PURPOSE:
	This function replaces the header of a file specified by filename with a new header

 CATEGORY:
	OI header functions

 CALLING SEQUENCE:

	ret = WR_OIHDR(filename, header)

 INPUTS:
	filename:	A string which specifies the filename of an *existing* file, to which the 
			new header should be written.

	header:	An OI header structure that will replace the existing file header.

 OUTPUTS:
	The function returns 0 if OK, else error number of the file-open function OPENU (see also !ERR_STRING)

 EXAMPLE:

	Issuing the command

	ret = wr_oihdr('d:\or\data\072390\example.0a', newheader)

	writes the structure 'newheader' at the beginning of file 'd:\or\data\072390\example.0a',
	without checking anything before.
	If the functions returns a scalar 0, the header was written successfully.
	A nonzero value is returned if an error occurred.
	Note: The error value is the one that was returned by the OPENR function.
           See !ERR_STRING for further information.

 MODIFICATION HISTORY:
 	Written by:	Gerhard Braendle, July 1996.

(See c:\idl_loc\lib\oi_general\wr_oihdr.pro)


X_HEXCVT (EXTENDED_HEX_CONVERT)

[Previous Routine] [Next Routine] [List of Routines]
 NAME:
	X_HEXCVT (extended_hex_convert)

 PURPOSE:
	This function converts numbers from 0 to 35 to "extended HEX"
	i.e. 16 is G, 17 H, etc. The input is a number, the output a string.

 CATEGORY:
	Miscellaneous

 CALLING SEQUENCE:
 
	Result = X_HEXCVT(Integer)

 INPUTS:
	Integer:	This is a positive integer number between 0 and
			35 which is to be converted to extended HEX

 OUTPUTS:
	This function produces a string which is the extended HEX value
	of the input number.

 RESTRICTIONS:
	This only works for 0 to 35 that is for the numbers 0-9 and a-z

 EXAMPLE:

		STRING = X_HEXCVT(18)

	will yield STRING being 'i'

 MODIFICATION HISTORY:
 	Written by:	Tobias Bonhoeffer, April 1993
	July, 1994      Any additional modifications will be described here.

(See c:\idl_loc\lib\or_pros\x_hexcvt.pro)


YES_NO

[Previous Routine] [List of Routines]
 NAME:
	YES_NO

 PURPOSE:
	This function creates a widget requester that displays a message and waits
	for a click onto the YES or the NO button.

 CATEGORY:
	Muc_pros, widgets

 CALLING SEQUENCE:
 
	Result = YES_NO, Message

 INPUTS:
	Message:	String with the message/question to be displayed
	
 OUTPUTS:
	Returns 0 if "NO" button was clicked, 1 if "YES" button was clicked,
	returns -1 (undefined) if requester was killed (closed).

 RESTRICTIONS:

 EXAMPLE:
	answer=yes_no('Alles klar ?')
	IF (answer EQ 1) THEN yes_was_clicked
	IF (answer EQ 0) THEN no_was_clicked


 MODIFICATION HISTORY:
 	Written by:	Gerhard Braendle, November 1993
		

(See c:\idl_loc\lib\or_pros\yes_no.pro)