Re: My problem or yours?

[Chris Albertson <chrisalbertson90278@yahoo.com>]

Tom,

As you say the FITS header will take care of it.

In the header are (well should be) both the dimensions of
the raw image array AND the location within that array of
the actual image pixels.  So you can fix the PROM code when
you can get around to it and then fix the header to match.
In theory you would not have to tell anyone as FITS files
are self descriptive.

There are two keywords IMAGESEC and DATASEC that are synonyms
for the area that contains the "real image data" and the FITS file
should contain lines line this:

   IMAGESEC   [10:2042,5:2037]
   DATASEC    [10:2042,5:2037]

I would include both lines as some readers will look for one
and others will look for the other.  (The numeric values are
made up examples and likely wrong.)

This syntax with the square brackets allows an image processing
pipeline to easily extract the image pixels with some command
like the following

  imcopy tomsimage.fits$IMAGESEC foo/bar.fits

The above would expand to

  imcopy tomsimage.fits[10:2042,5:2037] foo/bar.fits

If your program either uses the CFITSIO library or is IRAF
based then it can handle the above syntax.  Your program, when
it tries to open "tomsimage.fits[10:2042,5:2037]" will "see"
only the 2032^^2 image pixels.  Those headers save the software
and the programmer a lot of work.


Tom Droege wrote:
> 
> Andrew (and all),
> 
> (All be sure to read this if you have a Mark IV or are looking at data.)
> 
> This is called "product enhancement".  The old images were 2043 x 2037, and
> you had to know these numbers.
> 
> The new images are something else.  I recall 2064 x 2037.  But I no longer
> need to know these numbers since the various .fits viewers read them from
> the WCS header and do everything right.  I assume that if I read them with
> DS-9 and they come up and the cursor shows close to the right co-ordinates
> for a star then I am doing everything right.
> 
> OK, there is no change in the vertical lines read out.  For the horizontal
> line, I now try to read all the covered pixels at the start and end of the
> image, as well as 16 overscan pixels.
> 
> OK, it may be my problem, but it is now yours as it is not likely to be
> changed.
> 
> But there is really no change in the vertical direction.  In fact, I am
> still using the same prom code, so the images are read out just as they
> were before - i.e. the same vertical lines are read.  It is just that more
> pixels are read in the horizontal line.
> 
> >1 part data part constant: the constant part starts
> >exactly 2^23 bytes in; 8 MB.
><SNIP>
--
   Chris Albertson             
   Redondo Beach, California
   home:   310-376-1029   chrisalbertson90278@yahoo.com
   cell:   310-990-7550
   office: 310-336-5189   Christopher.J.Albertson@aero.org