Shared Memory Access to Image Header and Data

The RTD uses the FITS image format internally. Currently no other formats are supported, however when they are added, the other formats will be converted to FITS internally. The RTD can be told to use sysV shared memory for the FITS image data and/or header on start-up (by default image files are memory mapped using mmap ). If an application attempts to get the sysV shared memory Id for an image, the RTD automatically starts using shared memory for it. External applications can use the shared memory created by the RTD or they can create their own and tell the RTD to use it. The RTD shm subcommand controls the sysV shared memory access. It has the following syntax:

 
 
<imageName> shm set $data_size $data_id $data_owner  
                    ?$header_size $header_id $header_owner? 
<imageName> shm get data 
<imageName> shm get header 
<imageName> shm create $size 
<imageName> shm delete $Id 
<imageName> shm update

The shm set subcommand allow you to set the shared memory Ids to use to access the image data and header. The data and header in the area specified should be in FITS format. If the header is not specified, the previous header is reused. For both data and header, the size of the area (in bytes) and the shared memory Id must be specified. In addition a flag indicating who owns the shared memory is specified (if true, then the area will be deleted when no longer needed).

The shm get subcommand returns the shared memory Id of the data or header. If the data or header is not currently in shared memory, it is copied to a new shared memory area and the Id for this area is returned.

The shm create subcommand creates a new shared memory area with the given size and returns the Id. The memory should be deleted with the shm delete subcommand when no longer needed.

The shm delete command deletes the shared memory with the given Id (which should have been returned from the shm create subcommand).

The shm update command causes the display to be updated to reflect any changes in the image memory.

Coordinate Systems

The RTD understands and supports the following coordinate systems:

Coordinate System	Description
canvas	canvas coordinates (canvas scroll area)
screen	canvas window coords (visible area)
image	basic image pixel coords (at mag 1, no transformations)
chip	detector chip coordinates.
wcs equinox	world coordinates in H:M:S
deg equinox	world coordinates in degrees

Where it makes sense to do so, the RTD subcommands accept coordinates of the form:

 
$x $y $coord_type

Where $x and $y are the coordinate values and the coordinate type is one of the types in the above table. For world coordinates, the equinox may also be included as part of the coordinate type specification, for example:

 
$image get $ra $dec "wcs 1950"

There is also a subcommand convert for explicitly converting coordinates from one system to another, for example:

 
$image convert coords $ra $dec "wcs 1950" x y canvas

converts $ra and $dec in equinox 1950 to canvas coordinates $x,$y, while:

 
$image convert dist $sw $sh screen iw ih image

converts a screen distance $sw,$sh to an image distance $iw,$ih.