Re: My problem or yours?

[Tom Droege <tdroege@veriomail.com>]

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