BPM keyword
Frank Valdes wrote on May 08, 1998
Q: I'd like to report a feature of using BPM with display. I have the bpmask set to BPM in my display parameter set, and the BPM card in the headers of some images set to bad pixel pl files which reside in the same directory as the images. When I display an image from that directory the BPM is used correctly. But if I try to display from another directory (ie "display ../image 1") the BPM is not found. I tried using the HDR$ notation in the setting of the BPM card but that also failed. I suppose I could set the BPM to be the entire path of the bad pix mask but that is not a good solution to the problem. A: As you say one can describe this as either a bug or a feature. The BPM keyword points to a filename. If there is nothing but a filename then it follows the common OS/IRAF convention that this means the current working directory. I can see that you might want a different interpretation which would be added by the bad pixel mask code to look in the same directory as the image. As you said this is not the case now. Also the HDR$ syntax is not involved in this. What does work is since this is an IRAF file name you can have IRAF logical directory paths as well as absolute paths. For me having an entire path is a good solution. I guess you don't think it is a good solution because it would break when you move data around. In the short term I don't see anything changing. In the longer term I think it is realized that the BPM keyword pointing to a separate file was just a quick feature added during the first implementation. We have to think about how masks can be assigned to images in a more general way. One goal is to have the pixel masks be stored with the images. For certain types of FITS format data, such as mosaic data, we intend to implement a FITS extension that would allow storing the pixel mask in the same file. How the primary image would reference the extension is yet to be worked out but it probably will lead to ideas such as the HDR$ idea. ------ Anyone want to add to this discussion?
Steve Allen wrote on May 12, 1998
On Fri 1998-05-08T10:57:37 -0600, Frank Valdes hath writ: > such as mosaic data, we intend to implement a FITS extension that > would allow storing the pixel mask in the same file. How the primary > image would reference the extension is yet to be worked out but it > probably will lead to ideas such as the HDR$ idea. > Anyone want to add to this discussion? This seems to approach the concept which prompted the proposal of the FITS Grouping convention. I think it would be good if it is at all possible for the solution of the BPM references to mesh with or improve the specification of the Grouping convention. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 sla@ucolick.org Voice: +1 408 459 3046 http://www.ucolick.org/~sla PGP: 768/4A62BED1 0D C8 E1 9F 39 E7 C4 BF 24 12 ED 94 E4 C6 2F DA
Last post on May 12, 1998