IMG2PNG, PDS/FITS to PNG conversion Options

[Bjorn Jonsson]

A new version of IMG2PNG is now available that incorparates several bug fixes from the past several weeks/months (some of these bug fixes were available in 'interim' versions of IMG2PNG). The bugs were mainly in the conversion of IMG files containing floating point data. In particular the bugs affected the conversion of Messenger orbital data (fixed several months ago), Rosetta Osiris data (fixed a few months ago) and LROC and HiRise DTMs (fixed recently). More files containing floating point data were probably affected. There is also a new command line parameter, -fstretch (actually it was added several months ago when I made some Rosetta-related fixes).

As usual, IMG2PNG is available here.

[Bjorn Jonsson]

A new version of IMG2PNG is now available. There are several fairly minor bug fixes and some Dawn-related improvements but there are also a few new features. The biggest one is the ability to automatically remove reseau marks from Voyager, Viking and Mariner 9 & 10 images. This should make these images a bit easier to process. The new features are:

(1) Reseau marks can be removed using a new command line switch, -remres
(2) By default IMG2PNG now always flips the image horizontally and/or vertically if this is necessary to get a correctly oriented image and if IMG2PNG knows that this is necessary. This affects the conversion of Dawn and Rosetta images. This behavior can be disabled using the -noflip switch.
(3) -fnameflip can be used to add information on if/how it flips the image to the output filename.

As usual, IMG2PNG is available here.

If you already have IMG2PNG and only want to download what has changed you can download this small ZIP file which only includes what has changed.

[Bjorn Jonsson]

A new version of IMG2PNG is now available. This is a very important upgrade if you have been using IMG2PNG to convert files in FITS format. There was a bug in the old version that caused the resulting PNGs to be mirror-flipped up-down but this has now been fixed. Relatively few of the planetary imaging data sets are in FITS format but e.g. the NEAR and New Horizons images are (luckily this bug was discovered before the Pluto flyby!). Conversion from PDS (.IMG) files worked correctly.

There is also one minor new feature in this new version: If you generate thumbnail images in addtition to full size images it is now possible to specify the thumbnail size. This is done by adding an optional number to the -t or -thumbn command line parameter. For example, "-t10" or "-thumbn10" generates thumbnails 1/10 the size of the original images. If the number is omitted a value of 4 is used.

Some minor bugs have also been fixed. In particular, converting Clementine images should now work in all cases.

As usual, IMG2PNG is available here.

If you already have IMG2PNG and only want to download what has changed you can download this small ZIP file which only includes what has changed.

[Bjorn Jonsson]

A new version of IMG2PNG is now available. This is an important upgrade if you have been using IMG2PNG to convert Curiosity images. In many cases the conversion fails in the old version with an error message, often because many of the Curiosity files contain "ODL_VERSION_ID = ODL3" at the top instead of the more usual "PDS_VERSION_ID = PDS3". This and other problems could occur when converting various 'types' of Curiosity images (Hazcam/Navcam/Mastcam).

This really is an 'interim' release of IMG2PNG since I'm also going to make some minor additional improvements but I wanted to get this version out ASAP because the old version has problems with lots of Curiosity images.

As usual, IMG2PNG is available here.

[Bjorn Jonsson]

A new version of IMG2PNG is now available. There are several changes but only the first three (or possibly four) are real functional changes and/or bug fixes.

(1) Fixed a bug which made it impossible to convert files unless you opened a command prompt in the directory containing the files. Doing something like "img2png c:\foo\*.img" from a different directory didn't work, you had to open the command prompt in the c:\foo directory and then do "img2png *.img". The resulting PNG files are written to the directory containing the original files so in the example above they get written to the c:\foo directory. I'm a bit surprised that almost no one has complained because of this bug which had been present for a long time.

(2) If the input file contains exactly three bands, IMG2PNG now outputs a color image. Previously the output image was 'tiled' with the first band at the top and the last one at bottom.

(3) MGS, LRO and Kaguya DEMs from Map-a-Planet are now correctly converted. In older versions negative altitudes were incorrectly handled since IMG2PNG didn't 'know' that the input file was a DEM and not an image.

(4) The most recent version of CFITSIO is now used when converting FITS images.

(5) I recently upgraded to a more recent version of Visual Studio. As a result, the img2png.exe file is now considerably bigger than it used to be but there shouldn't be any functional changes because of this.

(6) Not a real change but: I now no longer test IMG2PNG in Windows XP, mainly because Microsoft stopped supporting Windows XP a few weeks ago. This new version should work in Windows XP but I no longer 'guarantee' that IMG2PNG works there. It should work in all 32 and 64 bit versions of Windows after XP, including Windows Vista, Windows 7 and Windows 8.x.

As usual, IMG2PNG is available here.

[sjones]

Hi, I am having a few issues with converting some files.

First of, I am trying to get some LRO NAC images to convert, when doing so it says that the LROC Index file is corrupt or out of date, the issue here is I have just downloaded the index that was released on June 2014 and a NAC .img that was made on August 2013
http://lroc.sese.asu.edu/data/LRO-L-LROC-5...OI/APOLBASNHIA/ (NAC_ROI_APOLBASNHIA_E370S2061_20M)
http://lroc.sese.asu.edu/data/LRO-L-LROC-5...LRC_2001/INDEX/ (CUMINDEX.TAB)

The second set of images I am having an issue with is the LRO Diviner Lunar Radiometer Reduced Data Archive, as usual these come with the .lbl file however once converted it comes out as black.
http://pds-geosciences.wustl.edu/lro/lro-l...ylindrical/img/ ( dgdr_ra_avg_cyl_128_img.img & dgdr_ra_avg_cyl_128_img.lbl )

Any help on these would be very much appreciated.
using the latest version of img2png & windows 7

[JohnVV]

well "NAC_ROI_APOLBASNHIA_E370S2061_20M" is a normal everyday pds IMG
there would be no need for that "CUMINDEX.TAB" all that is is a listing of the files in the archive

use img2png or G'Mic
http://gmic.sourceforge.net
I use ISIS3 myself and not img2png

now from the lable on the IMG file( some pds images have DETACHED headers others like this one DO NOT)

CODE

PDS_VERSION_ID            = PDS3

/* The source image data definition. */
RECORD_TYPE   = FIXED_LENGTH
RECORD_BYTES  = 7192
FILE_RECORDS  = 2152
LABEL_RECORDS = 1
^IMAGE        = 2

OBJECT = IMAGE
    DESCRIPTION                = "High-resolution uncontrolled NAC mosaics
                                 created in support of high-priority regions
                                 of interest"

    LINES                      = 2151
    LINE_SAMPLES               = 1798
    SAMPLE_TYPE                = PC_REAL
    SAMPLE_BITS                = 32
    SAMPLE_BIT_MASK            = 2#11111111111111111111111111111111#
    CORE_NULL                  = 16#FF7FFFFB#
    CORE_LOW_REPR_SATURATION   = 16#FF7FFFFC#
    CORE_LOW_INSTR_SATURATION  = 16#FF7FFFFD#
    CORE_HIGH_REPR_SATURATION  = 16#FF7FFFFF#
    CORE_HIGH_INSTR_SATURATION = 16#FF7FFFFE#

    

END_OBJECT = IMAGE
END

it is 1798px wide and 2151px tall
32bit lsb image with a offset of 7192 (RECORD_BYTES = 7192)

for the 32bit imaging terminal (on windows you use cmd.exe to run the program) program Gmic
http://gmic.sourceforge.net/
( NOT the 8 bit image plugin for "The Gimp" , but the TERMINAL version )

CODE

gmic NAC_ROI_APOLBASNHIA_E370S2061_20M.IMG.raw,1798,2151,1,1,+7192 -o NAC_ROI_APOLBASNHIA_E370S2061_20M.tiff

converts it to a 32 bit tiff image
the free program "Nip2"
http://www.vips.ecs.soton.ac.uk/index.php?title=VIPS
( runs on Windows7 )
can open it
( it handles 32bit floating point images )
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
now the NEXT one

The 1.54 Gig "dgdr_ra_avg_cyl_128_img.img"

the lable file (dgdr_ra_avg_cyl_128_img.lbl) has

CODE

OBJECT                   = IMAGE
  NAME                    = "ROCK ABUNDANCE"
  LINES                   = 17920
  LINE_SAMPLES            = 46080
  SAMPLE_TYPE             = LSB_INTEGER
  SAMPLE_BITS             = 16
  UNIT                    = NONE
  SCALING_FACTOR          = 0.001
  OFFSET                  = 0.0
  DERIVED_MINIMUM              = 0
  DERIVED_MAXIMUM              = 1.15946257114
  MISSING_CONSTANT        = -32768
END_OBJECT               = IMAGE

now this "image" really is NOT a photograph it is just a data set
from the label file the description

Each sample represents the areal fraction of the surface
covered by rock fragments as estimated using the technique
described in Bandfield et al. (2011). Values are
scaled by the value of SCALING_FACTOR. Conversion
from Digital Number (DN) to average is given by the
equation:

tihs using gmic will convert it to a 32 bit tiff image

CODE

gmic -type short dgdr_ra_avg_cyl_128_img.raw,46080,17920 -type float -o dgdr_ra_avg_cyl_128.tiff

BUT
this is a normal everyday pds image with a detached label
only that it is 1.54 Gig in size

[elakdawalla]

Although I can't help with the specific problems, the reason that IMG2PNG wants to have the index file is because of the problem explained in this post where half of LROC images are mirrored but you need the index file or SPICE data to find out which half.

[JohnVV]

A lot of people treat the pds images as "raw" files
some have a text header on the binary image
others are just binary images with detached headers

most good text editors can READ ONLY the text headers in them
by "good" i mean REAL editors like emacs ,vi, gedit,kate
or on windows
SciTE or the scite based one " Notepad++"

or a "hex" editor
like hexedit or hxd
http://mh-nexus.de/en/hxd/

now most of the data in the PDS archives is in 32bit floating point
older files might be 16bit singed lsb or msb

so you need software that can work with 32bit floating point
photoshop works with 16 bit images( and 8 bit) , not 32 bit

as above there are some programs that WILL also run on windows
Nip2/vips and Gmic

Imagemagick Q16 will open 16 bit on windows and linux and apple .
but not 32 bit images

[sjones]

Thanks for the info, I have taken a look into gmic and had an issue and was wondering if you could help me out some more, while trying to use gmic I get the error failed to open #file# with mode 'rb' im not that much of an expert at this and I couldn't find any answers using google.

however photoshop (CS5 and probably 6, possibly others) has the option to create 32 bit files, while the color pallet doesn't change it can handle these images even if you cant really edit them in that scale (same as 16 bit as each channel is still only 255 each no matter the bit depth)

Also the reason I used the index file for the NAC image is because of what was written on the img2png website regarding the NAC files, that it has its own ini file to edit with the location and file name of the index file that it then uses. as I am not experienced or knowledgeable with such things I have to rely upon these instructions.

[JohnVV]

while trying to use gmic I get the error failed to open #file# with mode 'rb'

This is just a guess , but i mostly assume that windows users have really never used the terminal or used "regedit.exe"
( post win98 users that is )

xp,vista had a POS ( the not nice meaning of those three letters) thing they called a terminal
cmd.exe

now in win7 they added a second terminal program that is more like a real one but for Gmic the windows " cmd.exe" will do just fine

BUT you have to open the terminal has to be in the SAME folder as the image

now win7 has a nice option to open a terminal in the folder you are in
it is on the r-click menu
BUT
you have to hit and HOLD the " shift " button and r-click it ,to see it on the menu.
( for XP you had to hack the system registry to do this)

Gmic you want "gmic_1.6.0.0_beta_win32.zip"
http://sourceforge.net/projects/gmic/files/windows/

for install instructions read the README text file

you want to use "gmic.exe"
the one called " gmic_gimp" is the gimp plugin

for the terminal "gmic.exe"
copy it and all the *.dll files to
c:\\windows

[sjones]

Thanks for the help.

the img2jpg is similar as I have to use the same command prompt to use that too. I have tried the beta version with the same issue, however the second image "gmic -type short dgdr_ra_avg_cyl_128_img.raw,46080,17920 -type float -o dgdr_ra_avg_cyl_128.tiff" it gave an error saying that -short command was not available (or something to that end)

When using the gmic_1.5.9.3_win64.zip version I unzipped it to the same folder as the image and then with that folder run a command prompt there with the 2 lines of commands provided to get the problem, putting the exe and the .dll's in C:\\windows didnt make any difference either, please find the cmd print screen attached

Attached thumbnail(s)

 

[Bjorn Jonsson]

A new version of IMG2PNG is now available. In this version two bugs have been fixed:

(1) Fixed a bug which caused the output image to be completely black when converting MEx HRSC DTM files.

(2) IMG2PNG now correctly converts input files containing processed LROC images created from the original, raw data. An example is mosaics of LROC NAC images. Earlier versions of IMG2PNG confused these images with the raw images, resulting in strange (and incorrect) output images.

As usual, IMG2PNG is available here.

The LRO bug fix addresses the issue mentioned above by sjones on August 12, 2014 (this has taken far too long for me to fix, especially since this turned out to be a trivial issue). A cumindex.tab file is now not needed to convert the file mentioned there since that file is a mosaic of LROC images and not a raw LROC image (where a cumindex.tab file is needed).

The LRO Diviner Lunar Radiometer Reduced Data file also mentioned by sjones actually is (and was) correctly converted. It's just that the output image is very dark but not completely black - the pixel values range from 0 to ~600 which is very dark in a 16 bit image where the maximum value is 65535.

[elakdawalla]

Hyperion is really dull reddish in colour, isn't it? RGB composites most people post look mostly gray because uncalibrated images are used, from the raw images archive. I'm looking forward to seeing these latest images in the PDS archive, where they will be properly adjusted. What is the time period before we'll see these images in PDS?

I've made some RGB composites from the older Hyperion images found at PDS, but some images come out distinctly reddish, while others are pale-yellowish, so I guess there's still some variation in the calibrated images.

When using the raw uncalibrated images and adjusting the resulting RGB composite to make Hyperion reddish, are there any specific settings you use in your graphics software, or is it purely arbitrary?

Thanks.

These images will be in the PDS release that comes out on April 1, 2016. You can calibrate them with IMG2PNG, but a week or two later, the Rings Node will post their own calibrated versions of the images, so in theory all you have to do is to convert them to PNG format and combine them together. You need to be careful, though, to tell IMG2PNG to do the floating point to 16 bit conversion consistently from image to image, or else the color combinations will look wonky. Here is the command line I used for the conversion:

CODE

IMG2PNG *.IMG -fnameobs -fnamefilter -fstretch0,1

-fnameobs and -fnamefilter just add some information to the filenames. -fstretch0,1 tells IMG2PNG to do the floating point conversion the same way to all the images.

Just for fun, here is a pair of Hyperion color combos made from calibrated images downloaded from the Rings Node and processed with IMG2PNG as above. The one on the left is an RGB composite. The one on the right is IRGUV, which is the way that most Hyperion images were actually taken. (I aligned and warped the R and B frames to the G one for the left composite, but didn't go to the trouble for the one on the right, so it has color fringes from rotation of Hyperion between frames.)

Here's the same pair of images with levels adjusted and a bit of gamma correction. I'm no expert on image calibration, but the color of Hyperion in the one on the left looks like the color that Gordan gets when he processes images, so the process seemed to work.

To my eye it looks more "yellow" than "red", but this is what a spectroscopist would call "red." Red, to a spectroscopist, simply means that the object is more reflective at long wavelengths than at short wavelengths.

[Ian R]

Here is the command line I used for the conversion:

CODE

IMG2PNG *.IMG -fnameobs -fnamefilter -fstretch0,1

As a long-time user of Bjorn's marvellous little program, your post really made me sit up and take notice, Emily. For one, I assumed that the -r option was pretty much mandatory for converting calibrated Cassini PDS images. Furthermore, the use of the -fstretch command is something that I have used for Cassini SAR data, but certainly not for ISS files ... Are there any benefits to this approach over the -s scaling option, which is my preferred method of ensuring the PNGs have a consistent and decent range of brightness values.

Also, I never get 16-bit PNGs when converting with IMG2PNG: when I need a 16-bit image with a wide dynamic range, I resort to converting the data with three different scaling (-s) values, then combine them in layers (100-50-33) to produce a 16-bit TIFF file.

Here's my code, which I typically package into a clickable *.BAT file for expediency:

CODE

img2png *.img -r -s13
img2png *.img -r -s14 -fnamefilter
img2png *.img -r -s15 -fnameobs

This allows me to produce images with a wide dynamic range, such as this: