Where's the first place to go for troubleshooting help?
A few notes on colo(u)rs in IDL.
What happened to my colours in Postscript?
I get an "% Unsupported X Windows visual..." error
message.
My windows are flashing! When I change focus to an IDL
plot window, the entire desktop flashes into that colo(u)r table! I'm
using 24-bit color.
I've been put into 7-minute demo mode.
IDL 5.4 and up doesn't support GIF writing.
How do I produce an MPEG movie from IDL?
How do I pass an evaluation of a variable?
A incremental count wraps from 32,767 to -32,768!
I'm getting strange
faint lines in postscript device output which aren't visible in X
output.
A function in an external file
isn't compiling.
My landscape Postscript
plots keep printing in portrait format.
Where's the first place to go for troubleshooting help?
David Fanning's excellent IDL Programming Tips. He is the guru of IDL. Alternatively, there is an IDL FAQ hosted by Interactive Visuals, Inc, but they keep moving it (so you might need to go into their top level directory and hunt around if this link is broken), and it's not terribly up to date. Alternatively (again), there is the comp.lang.idl-pvwave newgroup.
A few notes on colo(u)r in IDL.
There is often some confusion over colours (spelling will henceforth swap between UK and English fairly randomly) in IDL. Hopefully this will explain a few things, drawing from articles by David Fanning et al:
A display (ie, your video card, monitor and Xwindows software combination) will be one of either 8-bit, 16-bit or 24-bit colour. (It is not (easily) possible to have multiple levels of colour on a single display.) It means that the total number of different colours is 2^8 = 256, 2^16 = 65K or 2^24 = 16.7M.
In 8-bit colour, the colours are indexed. That is, each colour table (rainbow, white-blue, etc) has a specific colour associated with each index from 0 to 255, and colours are referenced by their index. For example:
; Loads 'yellow' (RGB triplet = red+green) into colour index 100
TVLCT, [[255],[255],[0]], 100
; Plots a yellow line
PLOT, data, COLOR=100
In 24-bit colour, IDL uses decomposed colour by default, and assumes that a value of COLOR is the hex representation of the RGB triplet. For example, to get the above yellow, you would want:
PLOT, data, COLOR='00FFFF'x
You don't have to use decomposed colour. You can force IDL on a 24-bit display to use 8-bit formulations by setting the Decomposed keyword. For example,
; Sets the decomposed keyword to be OFF.
DEVICE, DECOMPOSED=0
; Loads yellow into colour index 100
TVLT, [[255], [255], [0]], 100
; Plots a yellow line
PLOT, data, COLOR=100
If you use a program that calls pre-selected colour tables (eg XLOADCT, LOADCT, XPALETTE) this forces IDL to use decomposed colour. Each of these colour tables will only contain 256 individual colours, regardless of whether you are using a 16- or 24-bit display. You will have to go outside these colour tables to display an image with more than 256 individual colours.
The difference between 24-bit true color and 24-bit direct color is essentially that true colour uses fixed (linear) R,G,B scales, whereas direct colour allows you to modify the linearity of the R,G,B fields to allow colour correction.
The difference between 8-bit static color and 8-bit pseudo color is that static colour indices reference fixed RGB triplets, whereas pseudo-colour indices reference to user-adjustable RGB triplets.
What happened to my colours in Postscript? It looks terrible.
By default, IDL only uses 4 bits per pixel when writing to a Postscript image. The workaround is to use the keyword BITS_PER_PIXEL:
SET_PLOT,'PS'
DEVICE,/COLOR,BITS_PER_PIXEL=8
I get an "% Unsupported X Windows visual..." error message.
In IDL 5.4 or earlier, attempting to create a graphics window on a
Linux box results in this error message:
% Unsupported X Windows visual (class: StaticGray, depth: 0).
Substituting default (class: , Depth: 0).
The short answer: as root, run Xconfigurator, or edit /etc/X11/XF86Config-4, and remove all 16-bit color modes.
The long answer: See RSI's tech tips
My windows are flashing! When I change focus to an IDL plot window, the entire desktop flashes into that colo(u)r table! I'm using 24-bit color.
Edit your .cshrc file (or equivalent) and insert the line...
setenv IDL_STARTUP ~/.idl_startup
device,true=24
window,/pixmap &wdelete
device,bypass_translation=0
data=[1,2,3,4,3,2,1]
plot,data,color='FF0000'x
I've been put into 7-minute demo mode.
We may have run out of licenses. Check who else is using the licenses with:
% /usr/local/flexlm/bin/lmstat -f idl
IDL 5.4 upwards doesn't support GIF writing.
There is an article on the whole sorry GIF/LZW issue, but the upshot is that IDL no longer supports GIF writing functionality for licensing reasons. But there is a workaround for all of you animatedGIFaholics; first, use IDL to write the frame sequence as a series of postscript files. Then get IDL to call the convert program to convert to a gif. It will even accept an input like this:
% convert frame*.ps anim.gif
How do I produce an MPEG movie in IDL?
Stewart James says:
xinteranimate is pointless for writing MPEGs (unless they're small). Template for producing animations of plots in IDL:
window,0,xsize=512,ysize=512 ;Note this will be the final size of the animation
var1=mpeg_open([512,512])
for i=0,(number of frames) do begin
(Plot commands should go here)
mpeg_put,var1,frame=i,image=reverse(tvrd(),2)
endfor
mpeg_save,var1,filename='filename.mpeg'
mpeg_close,var1
end
UPDATE: There is now a full article on animation writing in IDL on David Fanning's website.
How do I pass the evaluation of an array?
This was the original problem:
I want to evaluate a (string) variable to then perform an operation on
(another) variable whose name is the result of that evaluation.
Let me clarify...
I have a number of 1-D floating-point arrays. I want to take each array
in
turn and do stuff with it, something like this:
PRO blah
array1=[1,4,3,5.3,42,234,32,..(etc)]
array2=[1,6,4.65]
array3=[9.1,4,2.02,5,6]
arrays=['array1','array2','array3']
arrayno=-1
REPEAT BEGIN
arrayno=arrayno+1
; Pick which array I want to operate on, in order
; **************************************
thisarray=arrays(arrayno)
; **************************************
; Do stuff on the selected array
ROUTINE_DOSTUFF,thisarray
; Loop through all the arrays.
ENDREP UNTIL arrayno=2
END
Except, of course, that this doesn't work, because (in the highlighted
line) the variable 'thisarray' is set to be the string value 'array1'
(etc), instead of having the actual array1 copied into it.
If I try this instead...
arrays=[array1,array2,array3]
thisarray=arrays(start,stop)
...this works, except I have to fiddle around calculating start and stop
by finding the sizes of the array and all the preceding arrays, which
isn't very nice.
Ahah, I think, I'll put them into one big 2-D array so I /know/ where
each one starts. But, alas, their lengths are very variable, so I'd end up
with a huge array, much of which would be 0, which seems a bit wasteful).
The same problem comes if I set up pointers to a structure:
arraystruct={array1:PTR_NEW(array1),array2:PTR_NEW(array2)...}
thisarray=arraystruct.arrayX ???
I'm having a brainfade here. What's the best way of doing this in IDL?
All I want to do is evaluate a string variable to read the value of the
variable that it evaluates to (say that three times quickly)
You could put your arrays into some kind of a list. (Something
as simple as a pointer array might work, or you could use
something like a linked list, if you want something more
complicated.) I'd try something like this:
myArrays = PtrArr(3)
myArrays[0] = Ptr_New(array1, /No_Copy)
myArrays[1] = Ptr_New(array2, /No_Copy)
myArrays[2] = Ptr_New(array3, /No_Copy)
Then, when you want an array to work with:
thisarray = *(myArrays[arrayno])
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
32,768 is, of course, 2^16, which should be a clue ;-) This is to do with the way that IDL (and other languages) store (integer, in this case) numbers. By default, they are stored in 16-bit space - the last 15 bits represent the number and the left-hand-most bit represents the sign. So, when you reach 32,767 (2^16-1) your righthand-most bits are all 1. Then you try to represent 32,768, which is 1000000000000000 in binary, which sets the sign bit...
The solution is naturally to make your integer count LONG when you
initialise it, eg
count=LONG(0)
which puts your address storage into 32-bit address space - so you
can represent up to 2^32-1 as an integer. If this is still too small,
then you can go to 64-bit addressing. If THIS is too small, then
you're in serious need of rethinking your program :-)
I'm getting strange
faint lines in my postscript image that aren't there in my X image.
A plot (with filled areas of greyscale) rendered in X
flawlessly. When it was written to a postscript file and the file
viewed with ghostview, it had several irregularly spaced faint grey
lines. However, when the file was ported to another machine
and viewed with a different version of ghostview, it was
fine. Ghostview weirdness, probably.
When a routine calls a function that's written in an external file,
it thinks it's a variable:
PRO mainprogram
result=SOMEFUNCTION(arguments)
END
You have to compile SOMEFUNCTION explicitly, ie
IDL> .compile mainprogram somefunction
My Postscript graphs are
landscape format, but they print in portrait.
You need to set the device to be landscape explicitly, ie
DEVICE,FILENAME='landscapeplot.ps',/LANDSCAPE
