Re: 1999 Mark III Data Collecting Season

[Nick Beser <beser@aplcomm.jhuapl.edu>]

On Sat, 20 Mar 1999, Chris Albertson wrote:

> 
> To feed the above real-time pipeline I thought of a real kludge/hack
> that would work.  Linux (and other UNIX) systems have a file that defines
> how printing is done.  It is /etc/printcap.  One of the things you can
> specify there is the name of a program that all files to be printed much
> first be "run through".  They call this the "printer input filter".
> Another thing that you can specify is that print jobs are to be sent to
> some other computer on the network for printing.  My printers are called
> "HP_Laser" and "Epson_Stylus".  I could define a third called "TASS_Reduce".
> The input filter associated with this printer would run the data reduction
> pipeline on the data and never actually send it to a real printer.  This
> filter would live on the data-muncher computer.  It could even be a Sun
> SPARC and DEC Alpha.  On the real-time computer the "TASS_Reduce"
> printer would be set up to pass the files off to other computer. 

This would work well with our current setup. We have 5 Sparc 2 
workstations setup for control and data analysis (another 2 Sparc 2's are 
setup for a data server in another building). The TASS linux system 
copies the data to one of the 5 sparc 2's, and then the receiving machine 
can route the data to the other sparc's. (one for each channel). Since we 
have very good control now of the door (It can be closed even when the 
outside light sensor says it is dark outside), I can collect dark current 
prior to data collection instead of after collection is complete). 

Would it also be better to create a flat vector file for each data set 
collected instead of once at the begining of the run?

> Still we'd need an automated "hands off" data reduction pipeline.

Another benefit is that the processed data can appear on our web site 
during collection, rather than a few days later.

> 
> Are you by any chance using that program I wrote called "fits2raw"?  If so
> all it does is a very simple linear mapping of gray scale values.  It finds
> the FITS pixel with the minimum and maximum ADU values and maps that range
> onto the range 0...255.  It would be easy apply a log function or to use
> say, +/- 2.5 sigma in place of min and max.  If you want I could do it or I
> could point out the place in the code where I'd change the mapping function.
> You may want to try it yourself so you can experiment and get the "look"
> to your liking
> 
> One other thing that I could do that is specific to TASS Mk III images is
> to use only the central pixels as we have non-image pixels on the edges.


I have a cfitsio routine that reads the TASS file and then generates a 
pgm file. At this point I will take anything I can get. I would suggest a 
log function. I tried +/- 2.5 sigma (I am going to go back to my code to 
check if that is all I did), and it did seem to do much better.

Nick