Re: My problem or yours?

[Tom Droege <tdroege@veriomail.com>]

Andrew and all,


>By the way, Tom is wrong in thinking that the end of
>the data overwrites the beginning.

Gosh, I don't know how I could be wrong as it has never happened before.

Well, there are two possibilities.  Either it overwrites the first 5 lines, 
or it writes into the second block of memory which is not installed.  It 
may depend on where the jumper is set.

Look Andrew, I am easier to get along with than Raccoons.  At least if you 
bat me often enough with a 2 by 4 I eventually get the message.

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

If someone who understands what should be in these positions with the 
present configuration will send me a correct entry, I will start writing 
properly.

Tom Droege




At 11:11 PM 10/24/01 +0100, you wrote:
>On Tue, 23 Oct 2001 21:45:13 -0700, Chris Albertson
><chrisalbertson90278@yahoo.com> wrote:
>
> >
> >Tom,
> >
> >As you say the FITS header will take care of it.
>
>Ha!!
>
> >
> >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]
>
>My image actually has
>DATASEC = '[ 17:2064, 1:2048]'
>which is not right. It is flagged in the FITS header as being
>a "place keeper."
>
>Anybody blindly using packaged FITS routines is getting
>silly answers.
>
> > ... Your program ... will "see" only the 2032^^2 image pixels.
>
>Not quite. Data is being lost. As I said in my post
>to Tom, this leaves the image non-square and means that
>Bennett is going to have to try one more time to sort out
>if Axis1 is X or Y. Yeccchhh!
>
>By the way, Tom is wrong in thinking that the end of
>the data overwrites the beginning.
>
>I am not too sure what is there but I am sure it is
>not the end data. I think it is one row or is that column
>of garbage, one row of covered pixels and then the data with
>a horrid ramp (1400 adu or so) superposed. This has to be
>the start of the data recorded in more or les its proper
>place?
>
> >  Those headers save the software
> >and the programmer a lot of work.
>
>again: Ha!!
>
>Andrew Bennett, Avondale Vineyard