image2pnm error

59 views
Skip to first unread message

Koen Looijmans

unread,
Nov 2, 2023, 8:05:17 AM11/2/23
to astrometry
When I try to solve-field my "own" images, I'm getting errors. The example-pictures provided with the software do seem to work. Included below is the error I'm getting.

Some things that may cause this (I have no idea if these are related, but Im just throwing around ideas here)
- The image is a .fits-file, which for some reason isn't handled well (astropy and cfitsio should both be installed!)
- The image is a mosaic (the fits file itself containing 144 different images)
- The image is very large (~25k x 25k / 1.2GB)

Thanks in advance!

Reading input file 1 of 1: "C_20230804_084042_E_0000302D.VIS.bin_01_01.fits"...
Base: "./C_20230804_084042_E_0000302D.VIS.bin_01_01", basefile "C_20230804_084042_E_0000302D.VIS.bin_01_01.fits", basedir ".", suffix "fits"
Checking if file "C_20230804_084042_E_0000302D.VIS.bin_01_01.fits" ext 0 is xylist or image: image
 (not xyls because: Missing required columns: : FITS extension 1 in file C_20230804_084042_E_0000302D.VIS.bin_01_01.fits is not a table (or there was an error opening the file): error: [C_20230804_084042_E_0000302D.VIS.bin_01_01.fits]
extension 1 is not a table)
Running: /usr/bin/image2pnm --infile C_20230804_084042_E_0000302D.VIS.bin_01_01.fits --uncompressed-outfile /tmp/tmp.uncompressed.nIwRWo --outfile /tmp/tmp.ppm.gGsamv --ppm --mydir /usr/bin/solve-field
qfits: error: NAXIS = 0 in file C_20230804_084042_E_0000302D.VIS.bin_01_01.fits ext 0
an-fitstopnm.c:225:main: Failed to load pixels.
Command failed: /usr/bin/an-fitstopnm -i C_20230804_084042_E_0000302D.VIS.bin_01_01.fits > /tmp/tmp6nwayp2x.pnm
Traceback (most recent call last):
 File "/usr/lib64/python3.11/site-packages/astrometry/util/image2pnm.py", line 298, in main
   convert_image(options.infile, options.outfile,
 File "/usr/lib64/python3.11/site-packages/astrometry/util/image2pnm.py", line 235, in convert_image
   (imgtype, errstr) = image2pnm(infile, outfile, force_ppm=force_ppm,
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/usr/lib64/python3.11/site-packages/astrometry/util/image2pnm.py", line 200, in image2pnm
   do_command(cmd % (shell_escape(infile), shell_escape(outfile)))
 File "/usr/lib64/python3.11/site-packages/astrometry/util/image2pnm.py", line 60, in do_command
   sys.exit(-1)
SystemExit: -1
augment-xylist.c:591:backtick Failed to run command: /usr/bin/image2pnm --infile C_20230804_084042_E_0000302D.VIS.bin_01_01.fits --uncompressed-outfile /tmp/tmp.uncompressed.nIwRWo --outfile /tmp/tmp.ppm.gGsamv --ppm --mydir /usr/bin/so
lve-field
ioutils.c:568:run_command_get_outputs Command failed: return value 255

Dustin Lang

unread,
Nov 2, 2023, 9:08:59 AM11/2/23
to astrometry
Hi,

Try adding the "solve-field --extension <int>" argument to read an image from a FITS extension (eg, probably "--extension 1" through "--extension 144" for your image).

Hmm, 144 chips of 4kx4k, this wouldn't happen to be Euclid, would it?  I have been working with Jean-Charles Cuillandre on the ERO Euclid data and he has a bunch of tricks worked out.  Some custom index files will probably be required; the 2x2-arcmin chip quadrants are quite small & challenging with the standard data products.

cheers,
dustin

Koen Looijmans

unread,
Nov 3, 2023, 11:23:06 AM11/3/23
to astrometry
Dear Dustin,

Thank you for the reply, adding the extension argument seems to work! At least upto the solving part, but baby steps.
And your guess is correct, it is indeed Euclid data, if there's any news I'd love to know of course :)

Kind regards,
Koen
Op donderdag 2 november 2023 om 14:08:59 UTC+1 schreef dstn...@gmail.com:

Dustin Lang

unread,
Nov 4, 2023, 10:58:30 AM11/4/23
to astrometry
Hi Koen,

For Jean-Charles' ERO work, I tried producing a variety of custom Astrometry.net index files, using unWISE, Pan-STARRS, Gaia, and Legacy Surveys catalogs.  I still need to figure out with him which ones were most effective.  I also need to find out which index scales worked best -- I think I made scales -2, -1, and 0; zero is the smallest scale in the "stock" 5200-series Gaia-based index files.

Apparently the charge-injection structure introduces the equivalent of a chip gap through the middle of the CCDs, so we dealt with them as 144 quadrants, rather than 36 CCDs.  Presumably that gap should be calibratable in pixels, so that one could combine 4 quadrants into 1 CCD, which would then be large enough in angular scale that the regular Gaia-based index files should work.

So basically it's a work in progress to get astrometry.net working on Euclid images out-of-the-box.

cheers,
dustin
Reply all
Reply to author
Forward
0 new messages