IMG2PNG, PDS/FITS to PNG conversion Options

[volcanopele]

I've just started to play around with IMG2PNG again. I think the way you are doing things is fine for previously uncalibrated ISS data. I just gave it a try with the new Hyperion images and it works just fine (pro-tip for next April, use -s3 for CLR, -s4 for color filter images...). I can't seem to get -fstretch to work at all so I guess it only works if you are not also calibrating the images.

[Ian R]

Thanks for the feedback Jason. I prefer to calibrate images with IMG2PNG as the scaling factor (-s) doesn't appear to work with calibrated data taken straight from the PDS. Is there a reason for that, I wonder ... ?

[Ian R]

I've got it cracked (I think): the -fstretch command works only on calibrated ISS data (those with the _CALIB.IMG suffix), while the -s scaling factor only bears fruit when calibrating data inside IMG2PNG, and therefore must be used in conjunction with the radiometric correction option (-r).

[elakdawalla]

That's right, you don't need to use -r when you are working with the _CALIB images, and the -fstretch switch is only necessary for 32-bit (floating point) data; it takes the place of what -s does for 16-bit data.

I'm not sure why you're not getting 16-bit images out of IMG2PNG, though. Any Cassini image that starts out as 2MB should come out of IMG2PNG as a 16-bit PNG.

We should probably move this discussion to an IMG2PNG thread...don't have time at the moment....

[Bjorn Jonsson]

To clarify things a bit (much of this has appeared above in posts from Emily):

If you are using IMG2PNG to convert calibrated Cassini images (these files have "_CALIB" in the filename), use -fstretch and not -r and/or -s.

If you are using IMG2PNG to convert uncalibrated Cassini images, do not use -fstretch, regardless if whether you are calibrating them or not. If you want to calibrate the images, use -r and optionally -s as well (and if your are not calibrating you can use -s but you omit -r).

-fstretch is only applicable for an input file containing floating point imaging data. If it doesn't contain floating point data, IMG2PNG ignores -fstretch. The calibrated Cassini ISS files available at the PDS Rings Node contain floating point data so you *must* use -fstretch when converting these if you want to be able to make correct color composites. If you don't use -fstretch you'll get strange color. The reason you must use -fstretch in this case is that otherwise IMG2PNG maps the lowest and highest floating point values from the input data to 0 and 65535, respectively in the output PNG file. The lowest and highest floating point values are different in different input files and therefore -fstretch is necessary to force IMG2PNG to use identical mapping to 0...65535 for all of the files.

As noted above, the calibrated Cassini ISS files have "_CALIB" in the filename whereas files that are not calibrated don't.
If you are not using calibrated input files and instead use IMG2PNG to calibrate, -fstretch is not applicable because these files contain integers (sometimes 8 bit and sometimes 16 bit). If you use -fstretch in this case, IMG2PNG ignores it.

Also, I never get 16-bit PNGs when converting with IMG2PNG

This is strange. If you are either using calibrated input files or using IMG2PNG to calibrate, you should always get 16 bit output files. If you are not calibrating, you only get 8 bit output if the input file contains 8 bit data. If you notice different behavior it is a bug and I would like to know more details (the exact image you are converting etc.). And now I realize that I should probably add an option to force IMG2PNG to convert 8 bit images to 16 bit images when the input images contain 8 bit data.

I should probably find the time to update the IMG2PNG instructions a bit as they were originally written when calibrated Cassini images where not available for download anywhere if I remember correctly.

[ugordan]

To my eye it looks more "yellow" than "red", but this is what a spectroscopist would call "red."

That might be because ISS green filter central wavelength is shifted toward yellow which, I'm guessing, you're not correcting for. I use spectral interpolation in my Cassini processing precisely because of that. End result for a body with a simple spectral curve is pretty indistinguishable from what you get with a more accurate VIMS color approach (sRGB gamma-correct version on the right):

[Marc]

Hello, when I try to calibrate the cassini images it gives me the following error. I've downloaded de calibration volume (v2) extracted it with winzip (smart option disabled) and copied the bottle_map_hack to dustring.

N1353756268_1.IMG
Error: Couldn't find f:\calib\dustring\nac_dustring_venus.img, flatfielding will be skipped
No appropriate slope file found so cannot do flat-field correction
Error: Couldn't open f:\calib\offset\nacfm_so_p5.img, not dividing by exposure time
Error: Couldn't open spectrum file f:\calib\efficiency\solarflux.tab
Error: Can't open f:\calib\correction\correctionfactors_qecorr.tab, not dividing by correction fudge factor

also this warning screen http://gyazo.com/87a062005d95a08c870a2151924578cb

Thank you for your great work

[Bjorn Jonsson]

A new IMG2PNG version is now available. This is a fairly big update due to the addition of several new command line options. There are also a few changes to how IMG2PNG converts some images. The most significant change is probably that the converted Rosetta OSIRIS NAC/WAC and NAVCAM images now have correct orientation. By default, IMG2PNG does this when converting these images:

OSIRIS NAC: Flip vertically
OSIRIS WAC: Rotate by 180° (equivalent to flipping horizontally and vertically)
NAVCAM: Flip horizontally

Earlier versions flipped all of these horizontally, resulting in mirror-flipped WAC images. Flipping NAC vertically (instead of horizontally as in earlier versions) results in an orientation that is consistent with the value of NORTH_AZIMUTH in the image headers.

There are also several new command line options:

-force_byteswap
-force_nobyteswap
-allow_fneg
-force_hflip
-force_vflip
-metadata_table

-allow_fneg is significant and has to do with how floating point input images are converted. If the input image contains floating point data it must be mapped to 0-65535 in the output image. In earlier versions of IMG2PNG, if the lowest floating point value was <0.0, that value got mapped to 0 in the output image and 0.0 was mapped to >=0, usually slightly bigger than 0. In this new version, everything up to and including 0.0 is mapped to 0. I made this change because values less than 0.0 are fairly common in the black background space in calibrated images. I think this new behavior makes more sense but it can be disabled (in effect reverting back to the behavior in earlier versions) with the new -allow_fneg command line option. The change to the output images is usually negligible or even none. I had some doubts when making this change but eventually decided that the new behavior should usually make more sense. Note: This change is only of significance when you are not using -fstretch. Floating point data is common in calibrated image files from e.g. Cassini, Rosetta etc.

The other new command line options are described on the IMG2PNG webpage.

IMG2PNG is available here:

http://bjj.mmedia.is/utils/img2png/index.html

[machi]

I seriously miss the "like" or "appreciate" buttons for posts like this one!
Thank you Björn!

[open768]

Hi a bit of a newbie question - what do I need to do to make img2png work for MSL PDS files - eg
Thanks

CODE

$ img2png 0710MR0030160040402522*IMG

IMG2PNG v2.3 20160113

Warning: c:\calib\ does not exist

Converting 0710MR0030160040402522C00_DRCL.IMG
Attempting to detect the format of 0710MR0030160040402522C00_DRCL.IMG, length=8191
Can't detect the format of file 0710MR0030160040402522C00_DRCL.IMG
Couldn't convert 0710MR0030160040402522C00_DRCL.IMG

A new IMG2PNG version is now available. This is a fairly big update due to the addition of several new command line options. There are also a few changes to how IMG2PNG converts some images. The most significant change is probably that the converted Rosetta OSIRIS NAC/WAC and NAVCAM images now have correct orientation. By default, IMG2PNG does this when converting these images:


http://bjj.mmedia.is/utils/img2png/index.html

[elakdawalla]

You need to download the label (*.LBL) as well as the image files, then it should work.

[Ian R]

Bjorn,

I can't thank you enough for not only making this utility available in the first place, but also for constant upgrades and bug-fixes.

[JohnVV]

Hi a bit of a newbie question - what do I need to do to make img2png work for MSL PDS files - eg
Thanks

CODE

$ img2png 0710MR0030160040402522*IMG

IMG2PNG v2.3 20160113

Warning: c:\calib\ does not exist

Converting 0710MR0030160040402522C00_DRCL.IMG
Attempting to detect the format of 0710MR0030160040402522C00_DRCL.IMG, length=8191
Can't detect the format of file 0710MR0030160040402522C00_DRCL.IMG
Couldn't convert 0710MR0030160040402522C00_DRCL.IMG

mind you that this image "0710MR0030160040402522C00_DRCL.IMG" is a teeny tiny thumbnail
http://pds-imaging.jpl.nasa.gov/data/msl/M...R/SURFACE/0710/
it is only 67 K in size

the "red green blue " images are the
" 0710MR0030160040402522E01_DRXX.IMG"
" 0710MR0030160040402522E01_DRXX.LBL"

you really need both the image and the label

[Bjorn Jonsson]

A new IMG2PNG version is now available at the usual site:

http://bjj.mmedia.is/utils/img2png/index.html

The biggest change in this version is that it is now possible to debayer (also known as demosaicking) the input images. This is applicable for images from e.g. Chang'e 3. There are three new command line options associated with this:

-debayer
-debayer_ash
-debayer_exp

-debayer is used to debayer the input images using a default algorithm (Adaptive Smooth Hue) and -debayer_ash can be used to explicitly select this algorithm. This is the same algorithm as the one that can be selected in the "Debayer Image" ImageJ plugin; it has been used by Damia to process Curiosity images with great results (see e.g. here). -debayer_exp is used for experimental stuff, currently the Directionally Weighted Gradient Based Interpolation algorithm where I have been experimenting with post-processing the debayered images to suppress color artifacts (currently this involves selectively median filtering the hue using a 3x3 neighborhood for each pixel - this may change in future versions). -debayer_exp seems to work slightly better than -debayer_ash for some of the Chang'e 3 images but it is likely to work worse than debayer_ash for some images too (if anyone finds images where this is the case I'd like to know).
The color filter arrangement can be specified, e.g. -debayer:RGGB (which is the default arrangement and the one used by Chang'e 3).

Some bugs have also been fixed, mainly in the conversion of Chang'e 3 and LROC images and I also fixed some nasty bugs in the thumbnail generation code (for one thing, the automatic contrast stretch was far too severe). Also the header was sometimes missing from the metadata table that can be created with -metadata_table and there is now a Chang'e 3-specific version of this table.

See the IMG2PNG webpage for more details.

[Bjorn Jonsson]

A new IMG2PNG version is now available at the usual site:

http://bjj.mmedia.is/utils/img2png/index.html

The only changes from the previous version are that the new version correctly converts images from India's Mars Orbiter Mission (MOM). The previous version usually didn't convert these images and instead reported an error when converting.

When applicable, the MOM images can be demosaicked (debayered) using the debayer/debayer_ash/debayer_exp command line parameters as described in the above post.