IMG2PNG, PDS/FITS to PNG conversion Options

[Bjorn Jonsson]

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.

[Bjorn Jonsson]

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

[djellison]

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.

[Bjorn Jonsson]

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

[siravan]

Another data set, another IMG2PNG challenge

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

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.

[djellison]

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.

Attached thumbnail(s)

 

[mhoward]

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

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

[imipak]

CODE

[imipak@localhost] $ file ~/Download/DT2EC_002620_1410_002686_1410_A01.JP2
../Download/DT2EC_002620_1410_002686_1410_A01.JP2: JPEG 2000 image data

[mhoward]

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?

[Phil Stooke]

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

Phil

[elakdawalla]

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

[siravan]

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.

Attached thumbnail(s)

 

[Phil Stooke]

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

[JohnVV]

the Kaguya released images, when unzipped, are 32 bit IMGs, are they not?

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

i used raw2isis to open it

[mhoward]

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

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

[siravan]

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.

Attached thumbnail(s)

 

[djellison]

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

[knight]

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.

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

Cheers.
Ali.

[knight]

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

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

[Bjorn Jonsson]

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

[knight]

Awesome !

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

Cheers,
~a

[Bjorn Jonsson]

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.

[elakdawalla]

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.

[S_Walker]

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.

[Bjorn Jonsson]

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.

[S_Walker]

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

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.

[M@!]

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

[S_Walker]

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

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

[Sajid]

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?

[JohnVV]

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

[Bjorn Jonsson]

Does IMG2PNG produce 32-bit floating PNGs or does it scale them to 16-bit unsigned integers?

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

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 )

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

[JohnVV]

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

[Sajid]

(although it would be possible to store the floating point values in the 48 bit RGB values if that was of interest).

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.

[Sajid]

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

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.

[ugordan]

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.

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.

[Sajid]

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.

[Ian R]

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:



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!

[djellison]

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

[Bjorn Jonsson]

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.

[Bjorn Jonsson]

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.

[machi]

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.

[elakdawalla]

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

[Bjorn Jonsson]

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

[Bjorn Jonsson]

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.

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.

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?

[machi]

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

[Bjorn Jonsson]

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

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.

[elakdawalla]

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.

[Bjorn Jonsson]

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.

[elakdawalla]

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

[Bjorn Jonsson]

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.

[S_Walker]

Speaking of which, that data is now public (part of the last PDS release) and is much better in that format than the raw JPEG format, but no one has yet stepped forward to redo that awesome group effort version of the image....

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

[Juramike]

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

[S_Walker]

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

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

[ugordan]

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

[S_Walker]

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

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/cassi...815_1652951881/

Sorry for the thread-jack.

[Bjorn Jonsson]

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

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?

[S_Walker]

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?

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?

[machi]

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

Attached image(s)

 

[elakdawalla]

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?

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.

[Bjorn Jonsson]

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

[S_Walker]

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

[Bjorn Jonsson]

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

[machi]

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

[S_Walker]

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.

[ugordan]

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.

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.

[Bjorn Jonsson]

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

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

[Juramike]

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)

[Juramike]

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.

[Bjorn Jonsson]

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 this message for details.

[Juramike]

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

[machi]

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

Here it is.

Attached thumbnail(s)

 

[Bjorn Jonsson]

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.

[Juramike]

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

[machi]

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

[Bjorn Jonsson]

The IMG2PNG beta version discussed in recent messages (in particular here) 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.

[Bjorn Jonsson]

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

As usual, IMG2PNG is available here.

[Bjorn Jonsson]

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

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

As usual, IMG2PNG is available here.

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

[Bjorn Jonsson]

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

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

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

As usual, IMG2PNG is available here.

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

[Bjorn Jonsson]

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

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

As usual, IMG2PNG is available here.

[Bjorn Jonsson]

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

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

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

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

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

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

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

As usual, IMG2PNG is available here.

[sjones]

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

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

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

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

[JohnVV]

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

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

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

CODE

PDS_VERSION_ID            = PDS3

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

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

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

    

END_OBJECT = IMAGE
END

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

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

CODE

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

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

The 1.54 Gig "dgdr_ra_avg_cyl_128_img.img"

the lable file (dgdr_ra_avg_cyl_128_img.lbl) has

CODE

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

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

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

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

CODE

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

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

[elakdawalla]

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

[JohnVV]

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

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

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

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

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

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

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

[sjones]

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

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

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

[JohnVV]

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

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

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

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

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

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

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

for install instructions read the README text file

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

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

[sjones]

Thanks for the help.

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

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

Attached thumbnail(s)

 

[Bjorn Jonsson]

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

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

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

As usual, IMG2PNG is available here.

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

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

[elakdawalla]

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

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

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

Thanks.

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

CODE

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

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

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

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

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

[Ian R]

Here is the command line I used for the conversion:

CODE

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

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

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

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

CODE

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

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

[volcanopele]

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

[Ian R]

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

[Ian R]

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

[elakdawalla]

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

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

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

[Bjorn Jonsson]

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

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

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

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

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

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

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

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

[ugordan]

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

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

[Marc]

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

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

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

Thank you for your great work

[Bjorn Jonsson]

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

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

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

There are also several new command line options:

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

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

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

IMG2PNG is available here:

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

[machi]

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

[open768]

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

CODE

$ img2png 0710MR0030160040402522*IMG

IMG2PNG v2.3 20160113

Warning: c:\calib\ does not exist

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

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


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