Re: My problem or yours?

[Tom Droege <tdroege@veriomail.com>]

Tassers,

I would be happy to put anything in the fits headers that you all 
request.  That is, if I can figure out how to do it.

You just have to keep after me.  I have a short attention span, and you 
really need to remind me after each data set goes out.  Just keep bugging 
me with a list of what to change.

Hopefully, I just put in the "one day off" fix.  That can be checked for 
the next data going out.

I think one of you put up a global edit tool.  If one does not exist, it 
sure should.  This would allow fixing up old data runs.

Tom

At 04:59 PM 10/24/01 -0400, you wrote:
>Tom,
>
>Based on examination of images from DS 19, it did the following
>
>hedit *.fit datasec '[ 17:2041, 3:2033]'
>hedit *.fit biassec '[  5:10,   3:2033]'
>
>in IRAF to tell trim up the images.
>
>Just thought I'd pass that along....
>
>
>
> >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.
> >
> >Hmmmm!  It is just possible that I am writing more than the memory
> >holds.  Yep!   That is it.  I am writing 2064 x 2037 x 4 bytes =16817472
> >bytes into a memory that holds 16777216 bytes.
> >
> >The memory writes around.  This means that the bytes at the bottom of the
> >frame are to be found in the first 5 lines at the top.  The 5 lines at the
> >top of the frame are lost.
> >
> >I have sent out hundreds of disks, and you are the first to notice!
> >
> >I am inclined to live with it.  But will take advice from others.  What say?
> >
> >Many thanks to Andrew for looking carefully at the data and writing up what
> >he saw in a way that I could understand the problem.  This is why I send
> >out all this data.  I hope that someone will look at it and give me
> >feedback.  Working alone one can make mistakes.  I now recall that I
> >intended to reduce the number of vertical lines read to hold within the
> >memory limit.  I need to read out 2032 instead of 2037.  I would pick these
> >in the middle of the frame, of course.  But I am not sure it is worth doing
> >at this time.  I would need to send out a new vertical prom.
> >
> >Tom Droege
> >
> >
> >At 11:02 PM 10/23/01 +0100, you wrote:
> >>I am looking at the CD19 set.
> >>Just a couple of problems: I was modifying
> >>programs back in the spring and now they don't
> >>work. Just two programs: the one to analyse the
> >>data and the one to display it. Um.
> >>
> >>But I have now got the display program sort of working
> >>(I think) and now I am trying to find a 2032x2032
> >>image in there somewhere.
> >>It's 2064x2037 raw, right?
> >>I find 11mixed+2032data+6covered+15overscan = 2064 OK?
> >>But the other way it's
> >>1 not data?
> >>4 maybe data with big ramp. Presume Dark subtraction copes ...
> >>2027 data
> >>1 part data part constant: the constant part starts
> >>exactly 2^23 bytes in; 8 MB.
> >>4 constant
> >>    total 2037
> >>So I don't have 2032 data in that direction. Damn nuisance -
> >>I built in square images so I didn't need to try to remember
> >>if Axis1 was X or Y today ...
> >>
> >>My problem or yours?
> >>
> >>Andrew Bennett, Avondale Vineyard
>
>
>
>Regards,
>
>Richard G. von Blucher,  KD1KJ          Eastman Kodak Co.
>richard.vonblucher@kodak.com            CrossPoint Tower 3
>(978) 323-7545                          900 Chelmsford Street
>KNET: 276-7545                          Lowell, MA 01851