Colours in IDL

So far, everything that we have seen has come out in grey. Now we'll look at how to get things to be in colour. Before looking at colours in IDL, we'll cover briefly how colours are done on computer monitors in general. 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,'~jmarsham/filename.png',tvrd(true=1),r,g,b

makes it look right on the screen and right in the file.

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='~jmarsham/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:

1. Decomposed (with the device,/decomposed) IDL treats the image as 3 separate blocks of single byte values: one for each colour, or,
2. Combined (with device,decomposed=0) IDL treats the image as a block of 3-byte values

The former allows the window to behave as a older PseudoColor visual by using just one field.

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).