| | |
- common.database.DBMain.DBObject(__builtin__.object)
-
- Chip
class Chip(common.database.DBMain.DBObject) |
| |
An object that describes a single chip
NOTE: The presistent attributes NAXIS1 and NAXIS2 have been moved to
BaseFrame; the persistent attributes PRSCX, OVSCX, PRSCY, OVSCY
have been moved to RawFrame; the persistent attribute orientation
has been moved to RawFrame and has become a transient attribute
read from the image header. The purpose for these moves was to
accommodate necessary variation in geometries of the same (or
effectively the same) physical CCD. This allows proper
characterization of instruments whose CCDs change logical
geometries over time due to software or hardware changes.
The persistent properties PRSCXPRE, OVSCXPRE, PRSCYPRE, OVSCYPRE,
PRSCXPST, OVSCXPST, PRSCYPST, OVSCYPST, have been added directly
to RawFrame to support a more flexible representation of the scan
regions. Their description has been integrated into this
documentation.
The chip description deals mainly with the definition of prescan
and overscan regions. The prescan (PRSCX, PRSCY) and overscan
(OVSCX, OVSCY) attributes divide a chip in 9 regions. The definition
of 'pre' and 'over' is with respect to the readout direction.
| | +
| | | OVSCY
---+--------//-----+--- +
| |
| |
= =
| |
| |
---+-------//------+--- +
| | | PRSCY
| | +
+--+ +--+
PRSCX OVSCX
To allow exclusion of bad columns/rows within a scan region, a pre-
and post-skip area is defined such that the pre-skip area is
adjacent to the edge of the chip and the post-skip area is adjacent
to the data region. The relation of these areas to the scan region
is described in the following schematic of one corner of a CCD chip:
. . . .
. . . .
. . . .
| | | |
| PRE | | POST |
| BAD | SCAN REGION USED FOR CORRECTION | BAD | DATA REGION
| | | |
|______|_________________________________|______|____________...
For instance, for the prescan region in X, the appropriate
attributes would describe the regions below:
|------| |------|
PRSCXPRE PRSCXPST
|-----------------------------------------------|
PRSCX
Note that the sense of direction as defined by the read-out port,
may not be the same as the one defined by the pixel coordinate
system. Consider these four examples
1. 2.
====== FIERA
(NAXIS1, NAXIS2) (NAXIS1, NAXIS2)
+-----o overy +-----o prey
| | | |
| | | |
| | | |
| | | |
o-----+ prey o-----+ overy
(1,1) (1,1)
======= FIERA prex overx
prex overx
3. 4.
====== FIERA
(NAXIS1, NAXIS2) (NAXIS1, NAXIS2)
+-----o overy +-----o prey
| | | |
| | | |
| | | |
| | | |
o-----+ prey o-----+ overy
(1,1) (1,1)
======= FIERA overx prex
overx prex
Note how in these examples the coordinates of prescan and overscan
regions have changed.
Several regions are of particular interest. In the default case (1),
these regions have the following coordinate definition
(llc_x, llc_y, urc_x, urc_y) or similarly (x0, y0, x1, y1)
TX = NAXIS1-OVSCX
TY = NAXIS2-OVSCY
trim: PRSCX+1, PRSCY+1, TX, TY
prescan_x: PRSCXPRE+1, PRSCY+1, PRSCX-PRSCXPST, TY
prescan_y: PRSCX+1, PRSCYPRE+1, TX, PRSCY-PRSCYPST
overscan_x: TX+OVSCXPST+1, PRSCY+1, NAXIS1-OVSCXPRE, TY
overscan_y: PRSCX+1, TY+OVSCYPST+1, TX, NAXIS2-OVSCYPRE
For case 2 (OVSCY<-->PRSCY) we have:
TX = NAXIS1-OVSCX
TY = NAXIS2-PRSCY
trim: PRSCX+1, OVSCY+1, TX, TY
prescan_x: PRSCXPRE+1, OVSCY+1, PRSCX-PRSCXPST, TY
prescan_y: PRSCX+1, TY+OVSCYPST+1, TX, NAXIS2-OVSCYPRE
overscan_x: TX+OVSCXPST+1, OVSCY+1, NAXIS1-OVSCXPRE, TY
overscan_y: PRSCX+1, OVSCYPRE+1, TX, OVSCY-OVSCYPST
For case 3 (PRSCX<-->OVSCX) we have:
TX = NAXIS1-PRSCX
TY = NAXIS2-OVSCY
trim: OVSCX+1, PRSCY+1, TX, TY
prescan_x: TX+PRSCXPST+1, PRSCY+1, NAXIS1-PRSCXPRE, TY
prescan_y: OVSCX+1, PRSCYPRE+1, TX, PRSCY-PRSCYPST
overscan_x: OVSCXPRE+1, PRSCY+1, OVSCX-OVSCXPST, TY
overscan_y: OVSCX+1, TY+OVSCYPST+1, TX, NAXIS2-OVSCYPRE
For case 4 (PRSCX<-->OVSCX, PRSCY<-->OVSCY) we have:
TX = NAXIS1-PRSCX
TY = NAXIS2-PRSCY
trim: OVSCX+1, OVSCY+1, TX, TY
prescan_x: TX+PRSCXPST+1, OVSCY+1, NAXIS1-PRSCXPRE, TY
prescan_y: OVSCX+1, TY+OVSCYPST+1, TX, NAXIS2-OVSCYPRE
overscan_x: OVSCXPRE+1, OVSCY+1, OVSCX-OVSCXPST, TY
overscan_y: OVSCX+1, OVSCYPRE+1, TX, OVSCY-OVSCYPST
The attribute orientation (header keyword CHIPORNT) is used to
distinguish between these cases
Note that (in all cases) the sizes of the regions are given by
xsize ysize
trim NAXIS1-OVSCX-PRSCX NAXIS2-OVSCY-PRSCY
prescan_x PRSCX-PRSCXPRE-PRSCXPST NAXIS2-OVSCY-PRSCY
prescan_y NAXIS1-OVSCX-PRSCX PRSCY-PRSCYPRE-PRSCYPST
overscan_x OVSCX-OVSCXPRE-OVSCXPST NAXIS2-OVSCY-PRSCY
overscan_y NAXIS1-OVSCX-PRSCX OVSCY-OVSCYPRE-OVSCYPST
|
| |
- Method resolution order:
- Chip
- common.database.DBMain.DBObject
- __builtin__.object
Methods defined here:
- update_header(self, header)
Data descriptors defined here:
- name
- Name of the CCD chip [None]
- object_id
- The object identifier
The object identifier is an attribute shared by all persistent
instances. It is the prime key, by which object identity is established
Data and other attributes defined here:
- pixelsize = 15
Methods inherited from common.database.DBMain.DBObject:
- __del__(self)
- Destructor for the DBObject
This destructor is called by the garbage collector for the transient
part of the DBObject. When it is called it calls the gc_transient()
method of the DBProxy implementation. The implementation of the
gc_transient() method can then decide what to do with the persistent
counterpart.
E.g. the database can be synchronized with its transient counterpart.
Another possibility is that the gc_transient() implementation checks
whether any attributes of a read-only object have changed since an
object was fetched from the database. If there are differences an
exception can be raised.
- __reduce__(self)
- Method necessary to create picklable objects
This mehod return a tuple containg a function object used for
unpickling and a picklable state tuple, to be used as argument
to the unpickle function. If necessary this object is registered
in the pickle cache
- as_dict(self, seqnr=1, dependency_name='', dictionary={}, allow_lazy_typed_list=False)
- Method much like the info method, but returns a dictionary.
Dictionary looks like:
{'<classname>.<property1_name>.<property2_name>': value,
'<classname>.<property2_name>.<property3_name>': value}
Problem: infinite loops for cold/flat dependencies. It seems a maximum
recursion depth limits the problem.
- commit(self)
- Commits object including objects that are referenced and have been changed.
If this object refers to other persistent object a commit() ensures that
1. ALL changes to the object and referred objects are made persistent.
2. NONE of the changed object and referred objects are made persistent.
Under normal circumstances only the first thing should ever happen.
If the second case occurs it is almost certainly because of some bug in
the routine that implements the DBProxy interface.
- get_creator(self)
- Returns the name of the user who created this object.
- get_persistent(self)
- get_project(self)
- Returns the name of the project to which this object belongs.
- info(self, level=0, doc=False, _indent=0, _printclass=True)
- Print the values of all persistent properties of the object.
level : level of introspection
doc : display docstrings for attributes
_indent : internal parameter used for formatting
_printclass : internal parameter used for formatting
- inverse_objects(self, max_results=100)
- Iterate through and return all objects that use the current object
max_results The maximum number of objects returned per query
- inverse_query(self)
- go through all inverse properties to see if this object is used
- persists(self)
- Returns whether an object is already made persistent or transient.
- recommit(self)
- Commits changes to an object, without following links.
Class methods inherited from common.database.DBMain.DBObject:
- get_inverse_properties(cls, props=None) from common.database.DBMeta.DBObjectMeta
- return all inverse properties
that are all the properties that point to this class
Data descriptors inherited from common.database.DBMain.DBObject:
- __dict__
- dictionary for instance variables (if defined)
- __weakref__
- list of weak references to the object (if defined)
Data and other attributes inherited from common.database.DBMain.DBObject:
- __metaclass__ = <class 'common.database.DBMeta.DBObjectMeta'>
- This is the metaclass for persistent classes
Provides:
__new__ -- manages class construction
__call__ -- manages object instantiation
- database = <common.database.DBOracle.DBProxy instance at 0xe3dcf8>
- pickle_id = None
| |