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.

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

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


(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 libfindfile 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)

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)

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)

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

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

CATEGORY:

CALLING SEQUENCE:

INPUTS:
File_name:	A string which specifies the filename into which
the new header should be written.
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

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


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:

CALLING SEQUENCE:

INPUTS:
filename:	A string which specifies the filename of an *existing* file, to which the

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

EXAMPLE:

Issuing the command

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: