Printable Version of Topic

Posted by: Bjorn Jonsson Feb 16 2008, 02:04 PM

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.

Posted by: Bjorn Jonsson Jun 7 2009, 12:53 AM

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

Posted by: djellison Dec 11 2009, 02:34 PM

Another data set, another IMG2PNG challenge

http://hirise-pds.lpl.arizona.edu/PDS/DTM/PSP/ORB_002600_002699/PSP_002620_1410_PSP_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.

Posted by: Bjorn Jonsson Dec 12 2009, 12:41 AM

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).

Posted by: siravan Dec 12 2009, 02:19 AM

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.

Posted by: djellison Dec 12 2009, 02:09 PM

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.

Posted by: mhoward Dec 12 2009, 03:35 PM

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

Posted by: imipak Dec 12 2009, 07:12 PM

Posted by: mhoward Dec 12 2009, 07:26 PM

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?

Posted by: Phil Stooke Dec 12 2009, 08:30 PM

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

Phil

Posted by: elakdawalla Dec 12 2009, 09:18 PM

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

Posted by: siravan Dec 12 2009, 10:03 PM

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.

Posted by: Phil Stooke Dec 12 2009, 11:17 PM

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

Posted by: JohnVV Dec 13 2009, 02:42 AM

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

i used raw2isis to open it

Posted by: mhoward Dec 13 2009, 03:09 AM

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

Posted by: siravan Dec 13 2009, 05:28 AM

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.

Posted by: djellison Dec 20 2009, 02:31 PM

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

Posted by: knight Jan 21 2010, 09:46 PM

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

Cheers.
Ali.

Posted by: knight Jan 21 2010, 10:34 PM

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

Posted by: Bjorn Jonsson Jan 25 2010, 12:14 AM

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

Posted by: knight Jan 25 2010, 12:26 AM

Awesome !

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

Cheers,
~a

Posted by: Bjorn Jonsson Jan 26 2010, 12:59 AM

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.

Posted by: elakdawalla Jan 26 2010, 02:19 AM

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.

Posted by: S_Walker Mar 15 2010, 04:24 PM

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.

Posted by: Bjorn Jonsson Mar 15 2010, 08:11 PM

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.

Posted by: S_Walker Mar 16 2010, 12:02 PM

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

Posted by: M@! Mar 16 2010, 11:03 PM

Do you have local administrator rights on your workstation? Is it possible that you need to http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/regsvr32.mspx?mfr=true?

Posted by: S_Walker Mar 17 2010, 01:05 AM

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

Posted by: Sajid May 2 2010, 05:33 AM

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?

Posted by: JohnVV May 3 2010, 12:12 AM

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

Posted by: Bjorn Jonsson May 3 2010, 01:27 AM

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.

Posted by: JohnVV May 3 2010, 02:18 AM

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

Posted by: Sajid May 3 2010, 08:00 AM

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.

Posted by: Sajid May 3 2010, 08:02 AM

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.

Posted by: ugordan May 3 2010, 03:54 PM

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.

Posted by: Sajid May 3 2010, 04:13 PM

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.

Posted by: Ian R Oct 16 2010, 01:44 AM

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/search.html#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:

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!

Posted by: djellison Nov 30 2010, 12:27 AM

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

Posted by: Bjorn Jonsson Dec 1 2010, 11:30 PM

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.

Posted by: Bjorn Jonsson Feb 8 2011, 12:38 AM

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.

Posted by: machi Feb 10 2011, 03:07 PM

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.

Posted by: elakdawalla Feb 10 2011, 05:29 PM

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!!!

Posted by: Bjorn Jonsson Feb 11 2011, 12:50 AM

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):

Posted by: Bjorn Jonsson Feb 20 2011, 09:55 PM

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?

Posted by: machi Feb 21 2011, 11:27 AM

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).

Posted by: Bjorn Jonsson Feb 21 2011, 10:46 PM

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.

Posted by: elakdawalla Feb 21 2011, 10:55 PM

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.

Posted by: Bjorn Jonsson Feb 21 2011, 11:10 PM

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.

Posted by: elakdawalla Feb 22 2011, 01:37 AM

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

Posted by: Bjorn Jonsson Mar 21 2011, 06:52 PM

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.php?showtopic=4979&view=findpost&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.php?showtopic=4979&view=findpost&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.

Posted by: S_Walker May 24 2011, 04:10 PM

Sorry if this is a newbie question, but is the IMG files on the latest PDS release 8 or 16-bit? I try using IMG2PNG with all the cassini calibration files in place, yet running N1652854565_1.IMG through IMG2PNG produces an 8-bit PNG file that is still loaded with cosmic ray hits and banding... I must be doing something wrong. I also downloaded N1652854565_1.LBL, but am unsure what to do with it.

Again, sorry for the noob questions...

Posted by: Juramike May 24 2011, 05:12 PM

If you use OPUS, are those already "scrubbed" and recalibrated?

Posted by: S_Walker May 24 2011, 05:46 PM

What is OPUS? But perhaps you are right, they could be already calibrated. I was hoping to get the raw 16-bit data; is there somewhere else besides here that I should look?:
http://pds-imaging.jpl.nasa.gov/search/search.html#Results

Posted by: ugordan May 24 2011, 05:55 PM

No online data archive that I know of keeps calibrated Cassini imagery. If there were, the data certainly wouldn't be stored in 8 bit format.

You're probably just getting a PNG dump of the uncalibrated raw data that was stored in 8bit LUT format in the IMG (file size about 1MB).

Posted by: S_Walker May 24 2011, 06:02 PM

Ok, that makes sense; N1652854565_1.IMG is definitely 1 MB. So am I simply looking in the wrong place? I'd love to have a go at the raw data for Enceladus and Titan. Really can't do much with the 8-bit data. I downloaded the data here:
http://pds-imaging.jpl.nasa.gov/data/cassini/cassini_orbiter/coiss_2062/data/1652827815_1652951881/

Sorry for the thread-jack.

Posted by: Bjorn Jonsson May 24 2011, 06:08 PM

Calibrated Cassini PNG image files output by IMG2PNG are always 16 bit regardless of the bit depth of the source images. Do you get any warning about not finding the Cassini calibration files when you start IMG2PNG?

Posted by: S_Walker May 24 2011, 06:15 PM

Not sure; I can only run the program by dragging and dropping the file directly into IMG2PNG. It opens and closes far too fast for me to read what it's doing. If I simply double-click img2png.exe (or img2png_new.exe) it opens and closes in a fraction of a second on my win7 machine. Any suggestions on how to open it so I can type commands?

Posted by: machi May 24 2011, 07:29 PM

It's possible via start menu, possibly (I don't know exactly, because I have czech version) in this order: start menu -> all programs -> accessories
Then you must find this icon

Posted by: elakdawalla May 24 2011, 07:47 PM

IMG2PNG is a command-line program. You have to run it from a command prompt window (Start > All Programs > Accessories > Command Prompt) in order to access its various switches and do calibration. There's limited documentation on Bjorn's website -- go to http://www.mmedia.is/bjj/utils/img2png/ and skip down to the heading that says "How to use". To calibrate Cassini images, you'll need to follow the instructions in the section just above that. I was able to figure out how to do this from Bjorn's instructions on that page. I know Bjorn has it in his head to eventually write more thorough documentation, but that is one of the least fun things for a programmer to do, especially if English is not your first language!

By the way, calibration will never fix cosmic ray hits. It will only fix systematic, predictable issues like dark current, flat field, etc.

Posted by: Bjorn Jonsson May 24 2011, 07:54 PM

I have 'moved' this discussion to private email correspondence and will probably be posting a summary here once the issue is resolved.

As Emily mentioned, the plan is to improve the documentation but yes, it's not exactly fun and also I was too busy finishing the Voyager 1 Jupiter approach movie (and now I'm working on a global DEM of Enceladus that is more fun too than writing manuals ;-).

Posted by: S_Walker May 24 2011, 09:26 PM

Thanks everyone for the help. It seems the images in question are indeed 8-bit png, if I'm reading the actions correctly.

Posted by: Bjorn Jonsson May 24 2011, 10:14 PM

Correct, the input images are 8 bit. But there's one important thing I forgot to mention, "-r". You need to include this when running img2png to get it to calibrate the input files. Like this:

img2png *.img -r

Posted by: machi May 24 2011, 10:25 PM

Original image from Cassini's ISS can be 8-bit, but if you use img2png with calibration, than output is 16 bit png. Without calibration procedure is output 8 bit png when original is 8 bit image, or 16 bit png, when original is 12 bit image.

BTW, I tried new user-specified calibration procedure on old Voyager images.
It looks, that img2png accept well my calibration files, but new version can't read and convert imq files (old version has no problems with them).

Posted by: S_Walker May 25 2011, 01:39 PM

Thanks everyone for the help. Works great now.
Emily, I realize cosmic ray hits wouldn't go away with calibration; I'm so used to my own deep-sky imaging where multiple sub exposures are combined to both increase the signal, as well as average out CR hits; same goes for my own planetary images taken with my camera and telescope. Not as used to putting planet images together with single exposures.
I was hoping the faint "venetian blind" artifacts would be removed with calibration (horizontal bands that are barely above the background counts), but alas, it's not to be.

Posted by: ugordan May 25 2011, 01:44 PM

Yeah, the 2Hz banding is hard to remove as it's not predictable. I don't think even the imaging team has a good solution to this. Basically involves advanced filtering of the image (helps if you have "black" areas around targets of interest) and is therefore not part of the standard calibration procedure.

Posted by: Bjorn Jonsson May 26 2011, 12:57 AM

That's weird, converting imq files works perfectly on my end, both with and without a calibration file. Are you using the most recent beta version? If yes (or if the most recent version does not work either) please post the error messages (if any) that appear plus a screenshot similar the the one posted by S_Walker at the top of this page (or, using copy-paste, the text from the command prompt window).

Posted by: Juramike May 26 2011, 02:32 AM

OK so...

New img2png programs unzipped - check
Cassini calib "Index of /volumes/COISS_0011/CALIB" calib.tar.gz unzipped and put in C:\\ directory - check (did I need to use the V2 version instead?)
moved mottlemap_hack.img into c:\calib\dustring folder - check
put img file and lbl file in same folder as img2png_new.exe - check
command script run - looks same as above - check (using -r option):

but png file is jet black (N1652854565_1.IMG):


Ran on another file (W1652951881_1.IMG) got noisy picture:


Did run OK on Galileo image.

Did I mess up the Cassini calibration files somehow?
(These are both coming out as 16-bit PNG's)

Posted by: Juramike May 26 2011, 11:13 AM

Part II:

Looked at log files. Needed to download instead the "2011_v2" volume instead. Did that. Modified the ".ini" file to point to the nested calibration files".
Tried it again, got same result as above.

Screenshot of log files show that the "c:\coiss_0011_v2\calib\offset\nacfm_so_p5.img" filesize is wrong (also WAC version)? The files show in my c:coiss_011_v2\calib\offset" directory as an 8K file.

Posted by: Bjorn Jonsson May 26 2011, 12:15 PM

I wonder if the calibration volume didn't get decompressed correctly. If you use WinZip to decompress you have to be careful (I don't think this has changed in recent WinZip versions). I don't know about different decompression programs. See http://www.unmannedspaceflight.com/index.php?showtopic=1214&st=0&p=17929&#entry17929 for details.

Posted by: Juramike May 26 2011, 01:49 PM

Thanks! I'll try that this evening! I used the WinZip defaults when I unpacked the calibration data.

(To turn off the TAR file smart CR/LF conversion it is in the WinZip "Options/configuration/Miscellaneous/other" box.)

-Mike

Posted by: machi May 26 2011, 01:57 PM

Here it is.

Posted by: Bjorn Jonsson May 26 2011, 06:11 PM

The issue with the IMQ files has now been fixed and I have uploaded a new version.

The problem was that the IMQ files have at least two different header 'variants' and I hadn't noticed this. The new version checks the headers more carefully than the old version does (this is to avoid misidentifying some files). It didn't recognize the Voyager Neptune headers but in contrast, e.g. Voyager Jupiter was OK. I don't think there are more variants of the IMQ file headers but cannot rule it out completely.

Posted by: Juramike May 27 2011, 02:32 AM

Awesome! It now works for me! Whoo-hoo!
(Bwa-ha-ha!)

Posted by: machi May 27 2011, 05:19 PM

It looks, that it's now working fine. Thank you Björn!

Posted by: Bjorn Jonsson Jun 18 2011, 12:39 AM

The IMG2PNG beta version discussed in recent messages (in particular http://www.unmannedspaceflight.com/index.php?showtopic=4979&view=findpost&p=171759) has now become an 'official' version. There are no significant changes from recent versions of the beta so it may not be necessary to upgrade it. In contrast, I recommend this new version of img2png for anyone using the old version, especially if there have been any hints of problems.

See http://www.mmedia.is/bjj/utils/img2png for more information.

Posted by: Bjorn Jonsson Mar 16 2012, 11:40 AM

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 http://www.mmedia.is/bjj/utils/img2png.

Posted by: Bjorn Jonsson Dec 16 2012, 07:50 PM

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 http://www.mmedia.is/bjj/utils/img2png.

If you already have IMG2PNG and only want to download what has changed you can download http://www.mmedia.is/bjj/utils/img2png/img2png_exe.zip which only includes what has changed.

Posted by: Bjorn Jonsson Apr 30 2013, 10:55 AM

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 http://www.mmedia.is/bjj/utils/img2png.

If you already have IMG2PNG and only want to download what has changed you can download http://www.mmedia.is/bjj/utils/img2png/img2png_exe.zip which only includes what has changed.

Posted by: Bjorn Jonsson Apr 10 2014, 12:00 AM

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 http://www.mmedia.is/bjj/utils/img2png.

Posted by: Bjorn Jonsson May 3 2014, 07:31 PM

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 http://www.mmedia.is/bjj/utils/img2png.

Posted by: sjones Aug 12 2014, 11:34 AM

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-RDR-V1.0/LROLRC_2001/DATA/BDR/NAC_ROI/APOLBASNHIA/ (NAC_ROI_APOLBASNHIA_E370S2061_20M)
http://lroc.sese.asu.edu/data/LRO-L-LROC-5-RDR-V1.0/LROLRC_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-dlre-4-rdr-v1/lrodlr_1001/data/gdr_l3/cylindrical/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

Posted by: JohnVV Aug 13 2014, 01:30 AM

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)

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 )


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



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


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


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

Posted by: elakdawalla Aug 13 2014, 02:59 AM

Although I can't help with the specific problems, the reason that IMG2PNG wants to have the index file is because of http://www.planetary.org/blogs/emily-lakdawalla/2010/2422.html.

Posted by: JohnVV Aug 14 2014, 05:15 AM

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

Posted by: sjones Aug 14 2014, 01:33 PM

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.

Posted by: JohnVV Aug 18 2014, 12:13 AM

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

Posted by: sjones Aug 18 2014, 12:54 AM

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

Posted by: Bjorn Jonsson Mar 14 2015, 01:50 AM

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 http://www.mmedia.is/bjj/utils/img2png.

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.

Posted by: elakdawalla Jun 4 2015, 08:34 PM

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:

-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.

Posted by: Ian R Jun 5 2015, 04:13 AM

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:



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

Posted by: volcanopele Jun 5 2015, 04:03 PM

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.

Posted by: Ian R Jun 5 2015, 04:48 PM

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 ... ?

Posted by: Ian R Jun 5 2015, 05:26 PM

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).

Posted by: elakdawalla Jun 5 2015, 05:58 PM

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....

Posted by: Bjorn Jonsson Jun 6 2015, 12:44 PM

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.

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.

Posted by: ugordan Jun 6 2015, 04:05 PM

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):

Posted by: Marc Jul 16 2015, 12:49 PM

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.

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

Thank you for your great work

Posted by: Bjorn Jonsson Jan 15 2016, 09:20 PM

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

Posted by: machi Jan 15 2016, 10:00 PM

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

Posted by: open768 Jan 30 2016, 11:02 AM

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

Posted by: elakdawalla Jan 30 2016, 05:39 PM

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

Posted by: Ian R Jan 30 2016, 08:41 PM

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.

Posted by: JohnVV Jan 30 2016, 10:17 PM

mind you that this image "0710MR0030160040402522C00_DRCL.IMG" is a teeny tiny thumbnail
http://pds-imaging.jpl.nasa.gov/data/msl/MSLMST_0008/DATA/RDR/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

Posted by: Bjorn Jonsson Mar 15 2016, 10:05 PM

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. http://www.unmannedspaceflight.com/index.php?showtopic=7426&st=15&p=189837&#entry189837). -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 http://bjj.mmedia.is/utils/img2png/index.html for more details.

Posted by: Bjorn Jonsson Oct 8 2016, 01:03 PM

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.

Posted by: neo56 Oct 26 2016, 01:53 PM

Bjorn, are you developing or do you plan to develop a version of IMG2PNG for Mac ? That would be awesome.

Posted by: scalbers Dec 3 2016, 11:48 PM

I'm checking how well GDAL works on a Mac to convert IMG files, at least in a rudimentary manner. I am able to do this with some files from a USGS Earth topography database. I wonder if their IMG format is the same thing as in the PDS?

Posted by: Rick Ramirez Feb 23 2017, 02:49 AM

I've been having some trouble getting the results I expect from IMG2PNG. It's probably user error but I'm wondering if someone can help me. I'm trying to create a full 16-bit displacement map for the moon. The Tiff files available here (http://wms.lroc.asu.edu/lroc/view_rdr/WAC_GLD100) are only 8 bit. I've downloaded all of the .img PDS files to try and produce correct 16-bit images but I'm having no luck. Running the converter tells me that sample_bits=16 but the PNG file produced is severely clipped. The resulting PNGs have black and white data ranging from 0 to about 0.05. I've tried using -fneg and also playing around with -fStretch without much luck. These are processed LROC images so I didn't think I needed any kind of calibration files. Am I incorrect? If anyone has any clues, I would very much appreciate it.

Posted by: JohnVV Feb 23 2017, 06:22 AM

the pds img files are here
http://lroc.sese.asu.edu/data/LRO-L-LROC-5-RDR-V1.0/LROLRC_2001/DATA/SDP/WAC_GLD100/

the img is a 16 bit SIGNED integer
gdal can convert a img to a tiff ( geo tiff)
example :

a screenshot from Nip2 image editor
http://imgbox.com/bToaoMgL

a height map heeds to be at least 16 bit depth or 32 bit float

Posted by: elakdawalla Feb 23 2017, 06:22 PM

Have you tried the -s switch (like -s1024) to multiply all the pixels by a number?

Posted by: JohnVV Feb 23 2017, 08:30 PM

the clipping is do to the img file being a SIGNED!!! integer in meters above and BELOW!!! "sea level"

that is -8967 METERS to a + 10714 Meters

using a multiplier will NOT put this into a unsigned range

16 bit signed pixel values ( -32768 to +32767 )
16 bit UNsigned pixel values ( 0 to 65538 )

you can use math functions
SUBTRACT the negative minimal value ( or add the min. absolute value ) to the image
an example using the G'mic image lib

Posted by: elakdawalla Feb 23 2017, 09:03 PM

Ah, right. I don't know that IMG2PNG currently handles signed data. But Bjorn is always tinkering with it so it's possible it could do so in the future.

Posted by: Rick Ramirez Feb 24 2017, 05:50 PM

Thanks for the help. I didn't realize IMG2PNG could not handle negative values. I haven't used GDAL of GMIC but I'll check them out.

Posted by: Bjorn Jonsson Mar 6 2017, 11:14 PM

I took a look at this and it's a bug in IMG2PNG that should soon be fixed. The problem is that 'normal' images usually do not contain signed data (and therefore no negative values) but this is a DEM and DEMs obviously can contain negative values. IMG2PNG recognizes some files as DEMs and handles them correctly but this DEM is 'unknown' to IMG2PNG. I'll probably add a new command line parameter to make it possible to tell IMG2PNG that the input file is a DEM in case IMG2PNG doesn't correctly recognize it as a DEM.

Posted by: Bjorn Jonsson May 1 2017, 03:48 PM

This has now been fixed and a new IMG2PNG version is now available. I added a new command line option (-force_dem) which forces IMG2PNG to treat the input file(s) as a DEM if possible (the sample type must be signed which is the case for all of the DEMs I've seen).

IMG2PNG is available here:

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

Posted by: Bjorn Jonsson May 3 2017, 12:24 AM

It has come to my attention that for some reason the upload of the new IMG2PNG version mentioned in the preceding post didn't succeed - the old version did not get replaced. So if you have downloaded the new version above to get the improved DEM handling you need to do so again - I have verified that this time the upload succeeded. Sorry for the inconvenience.

The new version should output this when you run it:

IMG2PNG v2.35 20170501

Posted by: Suchandler96 Jul 3 2017, 04:32 AM

I am recently handling the viking orbiter raw images, and in some images there are so many vertical missing lines that they are almost unreadable. I have found a software which can be found at
http://petermasek.tripod.com/viking.html .
Not only can it eliminate the vertical missing lines, it also removes some white speckles that appear in some VO images and performs contrast stretch. But the software can only process one image at a time, which makes it extremely inconvenient.
I would love IMG2PNG to include some of these features of this software(if possible)!

Posted by: jhagen Jul 3 2017, 07:12 PM

I've struggled with converting IMG files on my MAC, too. In the course of my experimenting with HiRise files, I stumbled on the fact that I can load IMG files directly into FITS Liberator. For anyone not familiar with it, this is readily available freeware. I have been using it for years to do initial histogram stretch on my astro-photography FITS files. Turns out it does what I need for IMG conversion very smoothly. I convert the fairly large HiRise 32 bit DTM files into 16 or 32 bit TIF files to work with in other software. FITS Liberator has a variety of non-linear histogram stretch options. For DTMs I do a linear stretch using the black and white point samplers.

I'm not sure that this meets the needs folks are mentioning here, but it might be worth a try.

Posted by: Bjorn Jonsson Apr 4 2018, 10:06 PM

A new version of IMG2PNG is now available. This is a minor update that simplifies the conversion of IMG files containing JIRAM images and fixes a bug that could appear when converting floating point IMG files containing DEMs in particular.

IMG2PNG is available here:

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

Posted by: Bjorn Jonsson Mar 21 2020, 04:09 PM

This may be a strange time to announce a new version of IMG2PNG but nevertheless: A new version of IMG2PNG is now available. By far the biggest change is that IMG2PNG is now a 64 bit application - earlier versions were 32 bits. This change was necessary to make it possible to convert extremely big images, an example is 46080 x 23040 pixel LRO DEMs.

In addition to the change to 64 bits I fixed a bug that occurred in some cases when converting LROC images. In some cases information on whether to flip the output image wasn't correctly read from the LROC index files.

As usual, IMG2PNG is available here:

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

The 64 bit version is now the 'official' IMG2PNG version but a 32 bit version is still available (direct download: http://bjj.mmedia.is/utils/img2png/img2png_exe_32bit.zip ) for users with a 32 bit version of Windows. However, I suspect most IMG2PNG users are running a 64 bit Windows version.

Posted by: Bjorn Jonsson Apr 7 2020, 10:21 PM

Turns out there was a subtle bug in the new 64 bit version of IMG2PNG announced in the previous post. The error was caused by internal changes that were necessary for the 64 bit version to work when converting very large images. The bug affected the calibration of Cassini images. In special cases it could also mess up the conversion of image files containing floating point data. A new version is now available where this bug has been fixed.

As usual, IMG2PNG is available here:

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

If you downloaded the version announced in the previous post I strongly recommend upgrading to this new version (this applies not only to the 64 bit version - the 32 bit version mentioned in the previous post was also affected).

Posted by: Antdoghalo Jun 19 2020, 01:32 PM

Hi, I'm trying to convert Img files with this and it keeps saying "The Disk Image File is corrupted". I think I might be typing something wrong in cmd but I am not sure.
EDIT:I was typing it wrong but now it's not recognizing the command.

Posted by: Bjorn Jonsson Aug 1 2020, 09:39 PM

I recently fixed a bug in IMG2PNG that occurred when converting input files containing more than one band of floating point data where the number of bands is not 3. These files are not very common (or at least not many users of IMG2PNG have attempted to convert these files).

As usual, IMG2PNG is available here:

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

Posted by: stevesliva Aug 2 2020, 03:09 AM

Doug told me this was okay to post...

... for prior versions, obviously.

Posted by: nprev Aug 2 2020, 03:14 AM

I take it that five is right out, then...?

Posted by: RonCatwanson Mar 3 2021, 08:12 AM

Hi, Bjorn! Is it possible to get source files of img2png somehow? One of my friends, software developer, got challenge starving and want to try to recompile it for linux\macOS systems. img2pmg still one of the best apps to convert img\fits files, but it is always painful to install virtual machine to use only this one tiny program.

Posted by: JohnVV Mar 4 2021, 05:14 PM

img2png might be useful on linux
but seeing as ISIS3 and ISIS4 already are linux programs it might not be needed

"isis2std" already outputs to png,jpg, and tiff ( 16 and 8 bit)
and "cubeatt" will output to a 32bit raw image

Posted by: volcanopele Mar 4 2021, 10:10 PM

There are a few data sets that are not properly supported by ISIS4 that are with IMG2PNG, for example Juno JIRAM. Though in that case, I can bring the images into Photoshop, but IMG2PNG does provide quite browse products.

Posted by: djellison May 12 2022, 06:16 AM

I see in the release notes that Chang'e 3 data is supported complete with a debayer option added around the same time..

FWIW - I tried some recently downloaded Chang'e 5 data and got this error..

I went and checked - and CE3 PCAM images do process well - and I think the CE4 and CE5 images are largely the same.

Maybe something to consider for the next release!

Doug

Posted by: Antdoghalo Jun 5 2022, 04:34 AM

Are their plans to one day incorporate PDS4 conversion as those products grow in number?

Posted by: Bjorn Jonsson Jun 6 2022, 10:14 PM

Yes, I will be adding PDS4 support. This is a fairly big change though - finding the time to do it is the main problem since I'm currently working on some very large image processing projects that I want to finish first (or at least finish some of them).

In contrast to PDS4 this should be a trivial change. I'll probably add CE4 and CE5 conversion soon (hopefully this month).

Posted by: Bjorn Jonsson Jul 20 2023, 08:39 PM

A new version of IMG2PNG is now available. This is just a minor update and only of importance in a few rare cases. The only change is that files containing 64 bit floating point data can now be converted (example: Dawn Vesta gravity maps).

As usual, IMG2PNG is available here:

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

The reason for the error turned out to be that this is a PDS4 data set. I hadn't noticed this above when I replied that this problem with the Chang'e 5 data would be trivial to fix. Adding PDS4 support is a major change. I have started work on it but it is proceeding slowly due to various other projects.

Posted by: Bjorn Jonsson Jan 29 2024, 11:19 PM

A new version of IMG2PNG is now available. This fixes a bug that could result in IMG2PNG terminating (or even crashing) without converting all of the files it should convert. Also fixed a minor bug involving VICAR formatted files.

As usual, IMG2PNG is available here:

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

Posted by: Antdoghalo Apr 22 2024, 01:55 AM

Is there a possible ETA on a PDS4 compatibility? A lot of things are now PDS4 these days and conversion projects at PDS are rendering the tool increasingly obsolete.
Found these cool maps of Rhea and Dione but unable to convert them.
https://pdsimage2.wr.usgs.gov/Individual_Investigations/dione.rhea_cassini_vims_ir-mosaic_scipioni_2022/