I decided to create a special thread for this topic. Previously information on IMG2PNG was scattered across various threads here.

I new version of IMG2PNG is now available. For those that don't know, this is a command line uitility that can convert various PDS formatted files to PNGs (8 or 16 bits per pixel depending on the input files).

This utility should work for lots of different PDS files, e.g. MER, Pathfinder, Voyager, Galileo, Cassini, Stardust, various Mars orbiters, Mariner 9/10 (!), Viking Orbiter, Viking Lander, Magellan, Clementine, Messenger, New Horizons etc.

The major new feature in the new version is the ability to convert FITS files.

IMG2PNG can be downloaded by visiting http://www.mmedia.is/bjj/utils/img2png

Any information on possible bugs welcome.

I just uploaded a new version of IMG2PNG. This version is important for those of you that use it to calibrate Cassini images as I corrected a nasty bug that resulted in incorrect brightness of the images. For example, this manifested itself in blue images that became too dark relative to the red and green ones. This messed up RGB composites.

There are no changes that affect images from other spacecraft.

As before this can be downloaded at http://www.mmedia.is/bjj/utils/img2png

Another data set, another IMG2PNG challenge

http://hirise-pds.lpl.arizona.edu/PDS/DTM/...SP_002686_1410/

I THING they're 32 bit IMG's - any chance of a tweak and recompile - IMG2PNG goes "Errm - excuse me, these are more than 16bit" and happily produces a 16 bit PNG anyway - which does have the image data in there, but it's stuck right down at the bottom of the histogram and stretching it to get some sensible displacement, I can see that it's got stair-stepping much like using 8 bit displacement maps.

I'll take a look at this sometime in the next several days. In the meantime it might work to do "img2png -sNNN..." where NNN is some "big" number. This might scale the output intensity to something that makes sense (I haven't tested this yet so I'm not completely sure).

I've written a utility program fitsfromimg32.exe, which converts 32 bits IMG files to FITS format. It seems to be doing a good job on these files. If anyone is interested, please send me a message, so that I can email the exe file or the C++ source files.

sNNNN worked in brightening up the resultant 16 bit PNG - but it's got stair stepping in there, where I wouldn't expect it to be.
In an ideal world - I'd have a 16bit PNG that goes from black (low) to white (high) and a text file telling me the actual altitude range between top and bottom so I can scale them appropriately. DAMN - I should have been a code monkey.

It's doable via ISIS3 I think - but ISIS is playing hardball with me today and not even letting me do USGS DEM isis2raw processing. Grrrrr.

I must be missing something here. Why do the files in that directory have .jp2 extensions?

I guess I need to be more clear. Above, we're talking about these files (?) as if they're IMG files. IMG file does not equal JPEG 2000 file, as far as I know.

What am I missing here?

Stepping around that wee problem for a second, the Kaguya released images, when unzipped, are 32 bit IMGs, are they not?

Phil

One of the files in that directory has an IMG extension...

I've attached a portion of DTEEC_002620_1410_002686_1410_A01.IMG. It is converted into 16 bit gray scale and shrunk 4 times. Note that it is a DEM, showing elevation at the edge of a crater with gullies cutting into the slopes.

Ah, now it's starting to make sense... two HiRISE images making a stereo pair (each with a full image and a color strip), and a DEM. That's quite a useful dataset...

Phil

from ghex the LALT_GGT_MAP.IMG is a 32 bit 4byte_float

i used raw2isis to open it

Ah, ok. I completely missed that somehow. Thanks.

The first image is the middle portion of the data in calibrated 16-bit gray scale (0=-366 m, 65535=+1794 m above the datum; 1/10 scaling). The second image is 8-bit contrast enhanced to bring out the features.

FWIW - Using ISIS3 I've now got these converting fine. PDS2ISIS, ISIS2RAW, then import to Photoshop as mentioned in the HiRISE DEM thread.

I was wondering if the 32 bit version of this is now available or if your fitsfromimg32 can be downloaded anywhere.

Cheers.
Ali.

Hi there I am pretty new to this so excuse me if this is a bad observation.
I've noticed that the img2png only works with one of the IMG files I downloaded from the Mars DEM site at HiRise. with further investigation the only difference I found was that the Min and Max values for all the other (non working) IMG files were :
VALID_MINIMUM = -1954.39
VALID_MAXIMUM = -1833.56
in the negative range. and always resulted in a black .png file. (got this info from a pds2jpg converter I found which makes the 8 bit conversion.

The only IMG file that converted successfully had a positive min and max value :
VALID_MINIMUM = 782.07
VALID_MAXIMUM = 1300.01
I've tried using the -s option to multiply by a negatice number or the -ctcal_dep.txt to set up a file with the correct ranges but I get nothing.
my cal_dep.txt file is just :
-1954 -1800
(as I understood it it should only have one entry per file)

if I am getting any of this wrong I appologise and would appreciate any guidance in converting these files.

my aim is to convert the files into hieghtmaps and eventually to 3d models in a standard 3d format.

Cheers.
~a

I have now fixed the bug mentioned by knight (and by Doug several weeks ago - it's the same bug). IMG2PNG now correctly converts the HIRISE DEMs. Actually it should correctly convert all files containing 32 bit floating point data if the files also contain information on the valid minimum and valid maximum data values or if that information is in a detached label.

As before this can be downloaded at http://www.mmedia.is/bjj/utils/img2png

Awesome !

Thanks Bjorn, I will test this when I get to work !

Cheers,
~a

I just made another new version of IMG2PNG, this time to correctly handle the MGS MOLA files. For the conversion to work, the label files (.LBL) must be downloaded in addition to the image files (.IMG) since the image files contain no header. When converting, the constant 8208 is added to the data to get rid of negative values.

EDIT: Currently IMG2PNG may only work for the MOLA topographic data (the megt*.img files) - I still haven't tested other 'types' of MOLA data. However, that's the data that should be most interesting. I'll do a new version that should work for more MOLA files in a week or two.

Although the gridded topographic data is indeed likely the most interesting for folks interested in digital terrain maps, I just want to speak up for the PEDRs. I don't think very many people appreciate how much better the along-track resolution of the MOLA data is than it is represented in the gridded data. Anybody who's seriously using MOLA data to understand the shape of a Martian feature is missing the boat if they do not use the PEDRs as topographic cross-sections.

However, we don't need IMG2PNG to read PEDRs; they're best read as lat, lon, altitude triples in a table.

I can't seem to get IMG2PNG to work on my computer- downloaded the latest version, and I was hoping to explore some of the LROC data release. However, the exe file gets this error "This application has failed to start because cftisio.dll was not found. Re-installing the application may fix this problem." I kept the cftisio.dll file in the same folder. Any suggestions? Running on an XP system.

This is weird - IMG2PNG should work if cfitsio.dll is in the same directory as img2png.exe.

Putting cfitsio.dll into the directory where Windows resides (usually c:\windows) might fix the problem.

Nope, that didn't help at all... stupid windows!

Do you have local administrator rights on your workstation? Is it possible that you need to register the DLL?

I think thats the problem, I don't have admin rights on my work computer.

Hi guys,

I'm working on a real-time renderer for large data-sets, and i stumbled onto this website while trying to figure out how to read Mars data into my program. Fascinating website, and I am amazed to see the zeal/respect/love you guys have for outer-space!

Anyway, sticking to the topic of the thread: Does IMG2PNG produce 32-bit floating PNGs or does it scale them to 16-bit unsigned integers?

i am not sure but most of the mars data is 12 bit black & white
nasa-view out puts to 8 bit indexed gray
isis3 ( at the moment ) outputs to a 8 bit gray png and 8 bit tiff ( the tiff should be fixed soon )

i have been running Linux for YEARS and have not needed the MS Windows img2png.exe

It scales 32 bit floating point values to 16 bit unsigned integers. As far as I know there's no such thing as a 32 bit floating point PNG (although it would be possible to store the floating point values in the 48 bit RGB values if that was of interest).


Getting the full 16 bits makes a big difference in some cases though.

how true

the busted tiff in isis has not been a pain seeing as i use openev to export a cub to tiff

so the img2png will
if the img is 16 bit , export a 16 bit ( red & green) png ?
if the img is 8 bit export a 8 bit gray png

It would probably be too much work to unpack that back as a float perhaps? Maybe its asking for too much, but a 32-bit RAW or floating TIFF output would be great.

Depending on whether the source data is 32-bit, isnt the tiff output by OpenEV fully floating point? I tried loading it in Matlab and seems fine to me. In-fact, thats what I turned to yesterday after discovering IMG2PNG would only do 16-bit.

Why is 32 bits so important to you? Is it in order to forget about normalizing each image to 16 bits just to get the highest S/N or do you expect 32 bits will inherently be higher quality? If it's the latter, I personally doubt there's much to be gained by going from 16 to 32 bits, especially since many calibrated products were derived from 12 bit A/D converter data. Even worse if there was an 8-bit LUT involved.

To put things into context, I am working on a real-time renderer for large data sets. The hypothesis is that a point-based rendering algorithm can render extremely large data-sets directly from range-images or DTMs without polygonization, at native resolution, take less memory, and still be faster.

So far, its working for range-images, and we managed to get a poster at SIGGRAPH last year. Now I would like to test the renderer with the Mars DTMs. 32-bit precision is important because some of the recent HiRise DTMs are natively 32-bit. Any conversion to 16-bit will invalidate my claim that we are preserving 'native' data. In addition, although the original data may have been derived from a 12 bit A/D converter, the derivation of a DTM requires calculations that will generally be done in 32-bits, even if later truncated/rounded to 16-bits.

Bjorn,

I just want to make you aware of a possible bug in IMG2PNG that I've come across in the process of putting together my Voyager 1 Jupiter movie.

My preferred method of browsing and downloading the Voyager datasets is the Planetary Image Atlas:

http://pds-imaging.jpl.nasa.gov/search/sea...tml#QuickSearch

However, the Voyager images have a img (as opposed to a imq) file extension. When I run IMG2PNG on them, using the default syntax, I get the following result:

Click to view attachment

As you can see, something strange is happening to the right side of the image, resulting in the loss of data on the left side of the picture. Do you have any idea what might be causing this?

Despite this minor bugbear, thanks again for a wonderful program!

Thinking out-loud - http://www.unmannedspaceflight.com/index.p...0&start=100 - Any chance of a SMART 1 tweak to the reason I still love looking at a dos box

At last I have started rewriting my PDS file parsing code from scratch - this is something I have wanted to do for a long time. The core of the code in the current version of IMG2PNG is really ancient. It's one of the very first pieces of code I wrote in the C++ programming language back in 1993 or so. Because of this it isn't particularly well written. Since then I have also made countless changes and additions to it so it has become messy as hell and requires far more work to maintain than it should require (probably about 100 times (!) more than it should for the bug reported above by Ian). Almost nothing is trivial to fix. What this means is that the bugs/issues mentioned above by Ian and Doug will not be fixed until a version of IMG2PNG utilizing the new PDS file parsing code appears. There will also be some LRO-related fixes in that new version.

I'm not exactly sure when I will be able to release the new version of IMG2PNG because I'm working on lots of stuff in parallel - hopefully within two months though.

I now have an alpha version of a new IMG2PNG where the majority of it has been rewritten from scratch as indicated in my previous message. As I hoped it's far easier to maintain and modify than the old version.

This new version correctly converts the Smart-1 data mentioned above by Doug and it also correctly converts the Voyager images that Ian mentioned above (the old version didn't). Also it correctly flips the LRO NAC images if you have the new version of the index.tab (or cumindex.tab) files. Actually the new version is far more flexible than the old one when dealing with various 'variants' of PDS formatted files so it should already be more robust than the old version when dealing with most files containing single band 8 or 16 bit data.

Not all features in the old IMG2PNG have been implemented in the new alpha version. There is no calibration stuff yet (this impacts the conversion of MER and Cassini data) and files containing floating point data cannot be converted.

If anyone is interested in trying out the new alpha version (and maybe discovering some bugs ) send me a message. It should mainly be interesting if anyone is interested in Smart-1, LRO/NAC and maybe Voyager but others are generally better off using the old version unless it does something strange. In a few days I should have a version ready for testing.

Finally, if there is anything you have ever wanted IMG2PNG to do that it doesn't currently do this is the time to mention it. Needless to say I cannot promise to implement everything everyone suggests but I'm open to good ideas.

At first, I thank you for this excellent simple, but powerful program. It's standart part of all my private data DVDs (together with older NASAview and specific programs from Piotr Masek).
What new feature I want to see in IMG2PNG?
I think, that very useful can be more adaptive calibration procedure. Not only for Cassini or MERs, but for other missions.
Because I want to have some control about this procedure, I think that can be good idea using txt file with references to calibration files.
Something like that:

flat.txt

f=masterflat12345.png
d=masterdark12345.png
b=bias12345.png

Important thing is possibility of using only partial calibration (only flat, flat+dark....), because sometimes
full calibration procedure destroys subtle details (main reason - imperfect calibration files).
This is for example case of Stardust's Wild 2 images, when raw images are better than calibrated ones.
Another feature can be automatic stretch and saving as 8bit png, which is better format as full size browse file for classic viewers as Irfanview, ACDS and so on.

Here's something I would love IMG2PNG to be able to do: optionally append information from the image's label to its filename. For one example, for a Cassini image, I would love to be able to append OBSERVATION_ID and/or FILTER_NAME to the filename upon conversion, resulting in, for instance, "N1506393206_2_ISS_015HY_MORPHO003_PRIME_20_CL1UV3.png".

It would be cool if IMG2PNG could optionally correct every-other-line truncation in Cassini and Voyager images (any others?) by interpolation.

It would also be useful if IMG2PNG might generate a text-formatted table containing label information from all the images processed during a single run. It needn't contain all the information from the label, just selected information to summarize the data -- things like IMAGE_TIME or IMAGE_MID_TIME, FILTER_NAME, OBSERVATION_ID...but I don't know if this would be workable, since there are different "interesting" items from the label for each instrument.

A couple of data sets that I have tried to work with recently that have been challenging are the NEAR MSI images and the LCROSS images...but I can't tell you specifically right now what were the problems I was having. I will try to get back to those and let you know.

I second machi's request for the ability to optionally have more control over calibration.

And, as always, thank you for your work on this immensely valuable application!!!

These are all excellent ideas and some of them had not occurred to me. I expect to implement most of them - doing so probably doesn't require too much work.

IMG2PNG's handling of LCROSS images will be greatly improved.

Meanwhile, just for fun, here is a portion of a false color LRO wide angle image (WAC) composed from 605, 645 and 690 nm data. The new version of IMG2PNG is now very close to handling the WAC data correctly (this data is somewhat complicated to process because of the framelet stuff):

Click to view attachment

The new version of IMG2PNG now does almost everything the old version does (the main exception is Cassini calibration) and I have now started adding new features. I have already implemented some of the suggestions above. For example, black horizontal lines can now be fixed by interpolation and it will probably be possible to remove reseau marks as well.


When you mention 8 bit files, are you referring to the image thumbnails that IMG2PNG can automatically generate or do you want to have the option to convert 16 bit PDS files to 8 bit PNGs?

Stretching and converting 16 bit to 8 bit. When I make data DVD's, I always make full size preview (so it's not thumbnail), because original format (PDS) is somewhat unfriendly to common image viewers as IrfanView, Xnview etc. In some cases 8 bit preview png can be used as direct input for processing (when original pds image is 8 bit, e. g. MGS or Voyager raw images), in others I convert png to jpg (then it's only preview, unusable for processing).

The old version of IMG2PNG doesn't correctly convert the LCROSS data. I actually wasn't 100% sure if the images were distorted 'by design' (I hadn't taken a look at technical details on the LCROSS data set) or if it was a problem with IMG2PNG. Now that I have seen LCROSS images from the new version (which converts them correctly) I know the answer: The old version is buggy.

I haven't tried converting NEAR MSI images yet.

The NEAR MSI images have non-square pixels, which is a challenge. It would be lovely to have an option to output files that were resampled to the smaller pixel dimension and had square pixels, but I know that IMG2PNG is a file format conversion/calibration application, not a resampling one. As an alternative, it'd be helpful to have the pixel dimensions of each image written to the log file or to a file metadata summary table so that it's easy to look up the pixel dimensions of the converted images when I want to resize them myself.

Actually it's fairly trivial to add resampling code. I have it in another application already so it doesn't reqire a lot of new code. One of the goals when rewriting IMG2PNG was to make it fairly simple to add new processing steps so adding resampling isn't complicated.

Are you using NEAR images in FITS format or PDS format? When I looked at this data ages ago only FITS was available. I think I saw it in PDS format somewhere but I may be confusing it with something else.

It's FITS format: http://pdssbn.astro.umd.edu/NEARdb/msi/

I'm now very close to finishing the new version of IMG2PNG. A beta version is now available here:

http://www.mmedia.is/bjj/utils/img2png/img2png_new.zip

This is an 'unofficial' version so there's no mention of it yet on the IMG2PNG page.
There are lots of improvements and even though this is a beta version I'm pretty sure it has fewer bugs than the old version. With the exception of a few new command line options the new version has the same user interface as the old one.

Some improvements:

(1) LRO WAC and NAC data is now correctly converted. The WAC framelets are automatically 'rearranged'. However, the distortion described in Fig. 3 at http://www.moonposter.ie/waced-moon.htm is not corrected but I may add that correction in a future version. To automatically correct the orientation of the images (flip horizontally and/or vertically) you need to download a recent version of the cumindex.tab (or index.tab for a subset of the data) file that comes together with the LRO imaging data and add a line to img2png.ini telling IMG2PNG where to find it, for example this:

lroc_index_file=P:\lro\index\CUMINDEX.TAB

(2) LCROSS data is now correctly converted. Some of the LCROSS images are actually tricolor images. Since IMG2PNG always outputs only grayscale images the resulting PNG image contains three images with channel 1 at the top, channel 2 in the middle and channel 3 at bottom.

(3) Doug 'discovered' that SMART-1 images couldn't be converted in the old version (see http://www.unmannedspaceflight.com/index.p...t&p=167207). The new version correctly converts this data. The bug mentioned by Ian in the message above Doug's message is also absent in the new version.

(4) The new version correctly handles a far greater number of 'variants' of PDS files than the old version. In particular files containing 4 byte floating numbers frequently didn't get correctly converted in the old version. IMG2PNG doesn't handle all possible variants of PDS files though.

(5) The black horizontal stripes that are sometimes present in Cassini and Voyager images can now be removed using a new command line option, -destripe. They are removed using linear interpolation. Linear interpolation is not optimal; in a future version a better (and more complex) algorithm will probably be used.

(6) Images with non-square pixels can now be resampled to square pixels using the -resample command line option. At present the NEAR MSI images are the only images that get resampled (this is because at present these are the only images I know of with non-square pixels).

(7) The filter name(s) can now be included in the output filename using the -fnamefilter command line option and the observation id using the -fnameobs command line options.

(8) Calibration files can now be specified using the new command line option -calib. This is implemented as suggested in machi's post: http://www.unmannedspaceflight.com/index.p...st&p=170463
So if you have a file named flat.txt (as in machi's example) use "-calibflat.txt". If this option is used the bias and darkframe are subtracted from the image and the result then divided by the flatfield. Individual calibration files are optional so you can for example omit bias correction by omitting the "b=" line (or commenting it out by prefixing the line with ; or #). If the input image is 8 bit it is converted to 16 bits before calibrating.

(9) I corrected a very minor bug in the Cassini calibration. The effects of the bug were extremely small so I don't think this is of any importance for the the typical users of IMG2PNG.


And that's it.

But - as mentioned previously - this new version is far easier to maintain and modify than the old version. So I will probably be adding new features. In particular, in a future version it will be possible to remove reseau marks from Mariner 9/10, Viking and Voyager images and correction for geometric distortion in the Voyager images is something that may appear in a future version.