Re: bad columns not masked properly?

[Tom Droege <tdroege2@earthlink.net>]

Michael and all,

Well, I did read the documentation.  I did try to figure out how to patch 
out the bad column.  It is pretty confusing to someone who has not written 
the code.  ;^)   Still, there is documentation, and I could have got it 
right had I really studied it.   The problem with something like this that 
there are endless pits to fall into.  One really has to read all the code 
and understand what is going on.  That is a big job.

OK, below I notice you did not do anything to the 62 - the total number of 
pixels patched out.  Does the program care if this is not right?  I assume 
not.

Also, I give up:

|So the second line in the mask file describes a bad region
|which covers columns 1948 to 1953, and rows 450 to 470.

How can you get 62 bad pixels out of this?    Note that 62 is only 
divisible by 31.  So the bad area can only be 1 x 62 or 2 x 31.  Some 
creative geometry is required, I think!  ;^)

Well I had just run some data through attempting to patch out the bad 
data.  But I did it wrong so will have to try again.  I think that this bad 
column will not be the cause of the crummy I data.  But I will try it to 
see if fixing the column does anything.

Tom Droege

At 02:47 PM 7/6/02 -0400, you wrote:

> > 2)  The mask does not realize that the defect extends down the whole 
> column.
>
>   Yup.  The program which created the mask didn't get it right.
>In a case like this, the user should edit the mask file manually,
>so that its second line looks something like this:
>
> > 1899    62      0      2028     1948    1953
>
>   _Now_ the mask will cover the entire set of columns (assuming that
>the trimmed images have 2029 rows).
>
>   The pipeline isn't going to get this part right automatically.
>The user should check images manually every now and then, and modify
>the mask files as needed.
>