Index: /trunk/archive/scripts/src/phase2/readouts.txt
===================================================================
--- /trunk/archive/scripts/src/phase2/readouts.txt	(revision 5465)
+++ /trunk/archive/scripts/src/phase2/readouts.txt	(revision 5465)
@@ -0,0 +1,41 @@
+Behaviour of readouts:
+
+
+typedef struct {
+	const char *extname;
+	psMetadata *header;
+	psArray *images;
+	psArray *masks;
+	psArray *weights;
+} pmPixelData;
+
+typedef struct {
+	...
+	psMetadata *concepts;
+	pmCell *parent;
+	psImage *image;
+	psImage *mask;
+	psImage *weight;
+} pmReadout;
+
+
+Procedures:
+
+a. Read: set pmReadout->image = pmPixelData->images->data[i],
+   pmReadout->mask = pmPixelData->masks->data[i], pmReadout->weight =
+   pmPixelData->weights->data[i]
+
+b. Mask bad pixels: Copy the provided mask into the input image mask.
+
+c. Bias/overscan subtraction: Read the CELL.BIASSEC, and apply to the
+   CELL.TRIMSEC.
+
+d. Trim: Cut the CELL.TRIMSEC, and paste into pmReadout->image,
+   pmReadout->mask, pmReadout->weight.
+
+e. Flat-fielding: Pretty straight-forward.  The FF just needs to be of
+   the same format as the input image.
+
+f. Splice: If images are untrimmed, then have to pluck out the
+   CELL.TRIMSEC and CELL.BIASSEC, and need to worry about the overscan
+   regions.
Index: /trunk/archive/scripts/src/phase2/testing.txt
===================================================================
--- /trunk/archive/scripts/src/phase2/testing.txt	(revision 5465)
+++ /trunk/archive/scripts/src/phase2/testing.txt	(revision 5465)
@@ -0,0 +1,63 @@
+Overscans:
+
+Modes: NONE | INDIVIDUAL | ALL
+
+* NONE produces warnings that there is no overscan subtraction:
+  "Proceeding to full fram subtraction."  This is probably
+  unnecessary.  The second warning is "bias frame is NULL.  Returning
+  original image."  This is in the spec --- good.
+
+* INDIVIDUAL works well.  The exponential ramp at the bottom of the
+  megacam image is removed. It leaves horizontal streaks, but I've
+  seen these before, and I figure they're part of the instrument, not
+  our software.
+
+* ALL also works.  The bias is removed, but the ramp remains, which is
+  exactly what I expected.
+
+Bin: An integer.  Using INDIVIDUAL mode.
+
+* 1 removes the ramp
+* 0 removes the ramp
+* Large values (50,100) have the effect of smoothing out the
+  horizontal streaks.
+
+Stat: MEAN | MEDIAN
+
+* Do a similar job (not identical).  Slightly less horizontal
+  structure with median.
+
+Fit: NONE | POLYNOMIAL | SPLINE
+
+* NONE is fine.
+
+* POLYNOMIAL produces a SEGV when I try to print out the resultant
+  polynomial.  I realise I haven't told it the polynomial order
+  (should create a psPolynomial1D to feed in to specify the order),
+  but I would have expected an error message.  Fixing this up, the
+  polynomial fitting works fairly well.
+
+* SPLINE doesn't seem to work --- it won't give back a spline for me
+  to print out the results of the fit.  Filed a bug.
+
+
+Flat: it works, but I'm concerned it's doing the entire image area,
+instead of just the appropriate area (CELL.TRIMSEC).  I added a trim
+to the phase 2, and it runs faster now.  The program still outputs the
+overscan, beacause it writes the pixels it read it.  The trim only
+affects where the computations are done.  Flat-fielding the image by
+itself (w/o overscan) results in ones everywhere, except the overscan.
+ 
+Full-frame bias subtraction: Works, but it acts on the entire image.
+Fixed the definition so that this is only done on the region specified
+by CELL.TRIMSEC.  That way, the overscan of the input image isn't
+affected by the full-frame subtraction.
+
+Non-linearity: This is really slow, or there's something really weird
+going on.  It used a heap of memory.  OK, found the problem: I had an
+extraneous free that caused corruption of the number of elements in
+the vector of coefficients.  Again, it wants to act on the entire
+image, so adding to the spec that it should only act on the
+CELL.TRIMSEC (assuming the non-linearity is from the CCD itself, not
+the amplifier).  It's fairly slow, but that might be because of the
+multiple trace messages in the polynomial evaluation.