I'm trying to help a friend with his transforms. He sent me his images of M67. With a little editing of the FITS header (adding RA, DEC, FILTER, BDF) and plate solving with Astrometry.net I was able to get a sample image to upload in VPhot and got a "green board" for Filter, WCS, Cal. The problem is that this image will not display properly. The image is totally black.
In image display mode I can faintly see the curser legend which shows the x,y and RA, Dec coordinates changing normally as I scan over the black image. I can open the header, and use other tools. I just can't see the image. If I load my saved sequence of standard stars for M67, the star list (at the upper left corner of the image display) indicates that all the stars are saturated.
There is no problem when I open this image with AIP, CCDSoft, or DS9.
I'd be happy to share this image with anyone who may be able to help.
Phil
Hi Phil:
Go ahead and share to MZK.
You know vphot, so we'll see if I get anything different?
Ken
Phil:
Assuming the system is RFO14, why is the exposure 1620 seconds??
Ken
Phil:
Open image. Look under tools/image display. Compare to any other of your images.
Something is bonkers with this image!! Try again?
Ken
Ken,
Yes, something is bonkers, but it displays fine in every other program I have that uses FITS, so it's something that just seems to drive VPhot bonkers.
1620 second exposure: According to the header, this image is the mean stack of eighteen 90s exposures (yes, a bit of overkill). I'm not used to seeing the total exposure of a stacked image in the header, but I use TheSky6, CCDSoft5 in the observatory. The RFO telescope\camera system (the source of this image) is run by TheSkyX, so I'm not surprised that the header info is somewhat different.
I think the problem may be related to the fact that this is a 32 bit image. That may be why the photometry tool thinks that every star is saturated. I tried opening the image in AIP and saved it as a 16 bit image, but I still got the same problem.
I'll suggest a "do over" with 16 bit images from the start.
Phil
Phil:
I tend to agree. I'm not sure if VPhot is set up to work with 32 bit images. I have sent an email to Geir with that question.
More disturbing that saving it as a 16 bit image and trying again also failed? Perhaps trying again from "the start" may be different??
I may try to save one of my 16 bit images as a 32 bit floating point image and see what happens?
Has any other VPhot user tried a 32 bit image successfully?
Ken
Phil:
I saved one of my 16 bit images to 32 bit integer and one to 32 bit floating with Maxim.
I uploaded both to VPhot but I could only see what appears to be 32 bit integer in my image list. This may be a duplicate issue?
I opened this 32 bit integer image (as indicated in fits header) and I can see it fine. I can load comps/targets onto it as normal.
So 32 bit integer is perhaps not the issue? Did you save yours as integer or floating?
I will try a different image as 32 bit float and see what happens?
Curious!! Please share your current 16 bit image and your new 16 bit image when ready.
Ken
Phil;
BTW, if the ccd has a 16-bit chip does saving the image as 32 bit add much value to the photometry? Doesn't it just interpolate the pixel values and stretch the display?
Ken
Phil:
I opened one 16 bit image in Maxim and saved it as 32 bit integer. I opened another and saved it as 32 bit floating. I uploaded them both to VPhot.
They both appeared in my VPhot image list. I opened both and could see the image. I confirmed in the fits headers that one was 32 bit integer (32) and the other was 32 bit float (-32).
I added comps and targets to the images as normal. The photometry was as expected.
SO VPHOT WORKS WITH my 32 BIT IMAGES!
Ken
PS: I just shared my two images with you.
Phil, Ken,
Just to support the last thoughts...
I believe that most programs will convert 16-bit raw images to 32-bit floating during calibration procedures. My calibrated images are always 32-bit and work with VPhot.
Best,
Helmar (AHM)
I'll be glad to look at the offending frame, if someone will send it to me or share it with me on VPHOT. Usually display problems are due to some sort of scaling problem, and since this is a median stack of 19 frames, scaling is likely to be an issue.
Whether to store a frame as 16-bit unsigned integer, 32-bit integer or floating point is an interesting question. In general, a CCD frame has less than 16 bits of dynamic range. You add/subtract/multiply/divide constants and not change the precision; you can always scale and store in 16-bit unsigned FITS format using BSCALE and BZERO. Where you run into more difficulty is when you perform arithmetic with a second frame (say, master flat) which has its own dynamic range. The combination can exceed a 16-bit range under those circumstances. Say, for example, that you have strong vignetting in your field, and there is a bright (but unsaturated) star in the vignetted region. After applying the proper flat, that star may end up with 100K values in its peak, while in the center of the frame your sky values are near zero. If you then store this frame as a 16-bit unsigned integer, you've lost some of the dynamic range. Note that this doesn't happen often, and since most frames start out with ~12bit dynamic range (roughly max ADU / readnoise), you can lose some of the maximum dynamic range without impacting the signal/noise in the frame. I always personally store single frames as scaled, unsigned 16-bit integer to save storage and transfer time, but I do look at BSCALE when the frame is being stored and redo the process (or revert to floating point) if it is significantly less than 1.0.
When you stack frames, you can exceed 16-bit dynamic range. For stacked frames, I highly recommend storing your resultant stacked frame as floating point to preserve the maximum signal/noise.
Arne
Thanks, Arne. I've shared the image with you in VPhot. In the VPhot Telescope Information form, the linearity limit for this scope is set to 50000 ADU and gain is 1.27.
Phil
While the frame displays fine in IRAF, the data values are bogus. The minimum value is -1.056x10**9, and the maximum value is 1.200x10**9. I don't know what type of camera was used; the frame size is 1024x1024. The frame as shared is a 32-bit floating point file with no BSCALE or BZERO.
Bottom line is that however you created the mean, it was not done properly or at least not stored properly. For a set of frames where each one is a 16-bit value, the mean should return something within that same data range, not something with limits corresponding to the maximum 32-bit signed integer range.
Rather than spending more time working on this frame, I suggest redoing the stack and submitting again. I don't see any problems with VPHOT in that this is a pathological case. It is amazing that IRAF/DS9 can display it!
Arne
Arne,
I should just say (again) that this it not my image but one of a B,V,I set sent to me by a friend who is requesting help in determining his transforms. I also found that this image displayed without problem in DS9 and AIP. I'll ask what software he used to stack the images and suggest he might try something else.
Thanks for your help.
Phil
Phil:
Why not just upload the individual images to VPhot? Perhaps 4 of each filter (BVI). Then you could stack in VPhot (or not) and download the instrumental magnitude files and import all into TG.
Just an idea. Are they too big and hard for him to send to you?
Ken
Hi Phil,
If the B and Ic frames stacked ok, then I don't think he needs to use any different software. Something just went wrong in processing the V stack. I'd have him do it again.
Arne
Arne, Ken,
Thanks for your comments, and I'm sorry for the delayed response.
Steve's idea was for him to process the M67 images with his own software (I think AIP) and use the spreadsheet method in the CCD Photometry Guide to calculate the transforms. Then, I would use his images to show him how I do the photometry part using VPhot. I think we've both gotten a bit side-tracked by other things in the meantime.
When he's ready, I'll suggest we get together and look at his B and Ic stacks. If they work okay, I'll process them with VPhot. I'll also suggest we also do the stacking again of (at least) the V images in his software or VPhot.
I'm hoping to convert him to VPhot. I think once he sees how easy it can be he'll want to learn how to use it himself.
Phil