Each pixel on the screen is made up of three colours: red, green and blue, each of which is represented by one byte and can therefore take on values between 0 (black) and 255 (as bright as possible). There are therefore 256 cubed = 16777216 possible colours. That's why white was 256*256*256-1 (counting from zero remember) in the surface plotting example.
Some monitors (hopefully all of the ones you will use) have three bytes ( 24 bits ) of video memory for each pixel - on such a monitor you can make any pixel any one of these 16777216 colours any time you like. A few older monitors may have only one byte of video memory per pixel, which means that there are only 256 colours available. You can make a pixel any of the 16777216 possible colours BUT you can only have 256 of those colours on the screen at any one time. Hopefully you won't encounter one of these. However as a result of this history, a lot of colour management in IDL is done via tables of (up to) 256 colours.
I wasn't looking forward to writing this bit of the course at all! However, Jason Lander (Leeds) seems to have worked out a system that works.
To use a 256 element colour table, such as those built in to IDL:
set_plot,'x' device,true_color=24,decomposed=0,retain=2 ;NEW LINE window,0,retain=2 loadct,39 tvlct,r,g,b,/get plot,r,xtitle='Index',ytitle='Intensity' oplot,r,color=230 oplot,g,color=150 oplot,b,color=50 oplot,[0,0],[0,0],color=0,psym=3 write_png,'~lecjm/filename.png',tvrd(true=1),r,g,bmakes it look right on the screen and right in the file. I have defined a procedure set_col.pro that just calls the line:
device,true_color=24,decomposed=0,retain=2 ;NEW LINEsince I use it so much.
From the help facility ``The colormap/visual class combination is chosen when IDL first connects with the X Window server. Note that if you connect with the X server by creating a window or using the DEVICE keyword to the HELP procedure, the visual class will be set; it then cannot be changed until IDL is restarted. If you wish to use a visual class other than the default, be sure to set it with a call to the DEVICE procedure before creating windows or otherwise connecting with the X Window server.'', so once you've set it that's it.
I think that means that you should set the ``device '' command first and then not change it.
Postscript is easier,
set_plot,'ps' device,file='~lecjm/filename.eps',/encapsulated,/color loadct,39 tvlct,r,g,b,/get plot,r,xtitle='Index',ytitle='Intensity' oplot,r,color=230 oplot,g,color=150 oplot,b,color=50 oplot,[0,0],[0,0],color=0,psym=3 device,/close
Why does this work? Jason says:
``TrueColor'' and ``DirectColor'' visuals both represent colours as separate (R,G,B) values.
The latter allows finer control of the exact colours associated with a set of (R,G,B) indices via a second set of look-up tables but IDL doesn't take advantage of this.
For a modern display, the IDL `X' device will pick one of the TrueColor or DirectColor visuals. Exactly which depends on what the program does first and - I suspect - this doesn't matter in the slightest.
The DEVICE specifications for True and Direct Color will either treat the (R,G,B) values as either:
The ``TV'' and ``TVRD'' commands are designed to take arrays of single bytes and copy them to or from a window. This worked well for PseudoColor but is a pain for newer displays.
BUT: both ``TV'' and ``TVRD'' accept ``CHANNEL'' and ``TRUE'' flags which tell it how to handle 24-bit displays.
We found that ``TVRD(TRUE=1)'' seems to grab bitmaps from 24-bit displays. According to the documentation, this returns a (3,nx,ny) array.
It is possible that ``TVRD(CHANNEL=1)'' would be more reliable (but I haven't got this to work - John).