IPB

Welcome Guest ( Log In | Register )

8 Pages V  « < 5 6 7 8 >  
Reply to this topicStart new topic
IMG2PNG, PDS/FITS to PNG conversion
volcanopele
post Jun 5 2015, 04:03 PM
Post #91


Senior Member
****

Group: Moderator
Posts: 2963
Joined: 11-February 04
From: Tucson, AZ
Member No.: 23



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.


--------------------
&@^^!% Jim! I'm a geologist, not a physicist!
The Gish Bar Times - A Blog all about Jupiter's Moon Io
Go to the top of the page
 
+Quote Post
Ian R
post Jun 5 2015, 04:48 PM
Post #92


Member
***

Group: Members
Posts: 756
Joined: 18-July 05
From: Plymouth, UK
Member No.: 437



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


--------------------
Go to the top of the page
 
+Quote Post
Ian R
post Jun 5 2015, 05:26 PM
Post #93


Member
***

Group: Members
Posts: 756
Joined: 18-July 05
From: Plymouth, UK
Member No.: 437



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


--------------------
Go to the top of the page
 
+Quote Post
elakdawalla
post Jun 5 2015, 05:58 PM
Post #94


Administrator
****

Group: Admin
Posts: 5029
Joined: 4-August 05
From: Pasadena, CA, USA, Earth
Member No.: 454



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


--------------------
My blog - @elakdawalla on Twitter - Please support unmannedspaceflight.com by donating here.
Go to the top of the page
 
+Quote Post
Bjorn Jonsson
post Jun 6 2015, 12:44 PM
Post #95


IMG to PNG GOD
****

Group: Moderator
Posts: 1897
Joined: 19-February 04
From: Near fire and ice
Member No.: 38



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.

QUOTE (Ian R @ Jun 5 2015, 04:13 AM) *
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.
Go to the top of the page
 
+Quote Post
ugordan
post Jun 6 2015, 04:05 PM
Post #96


Senior Member
****

Group: Members
Posts: 3628
Joined: 1-October 05
From: Croatia
Member No.: 523



QUOTE (elakdawalla @ Jun 4 2015, 10:34 PM) *
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):

Attached Image




--------------------
Go to the top of the page
 
+Quote Post
Marc
post Jul 16 2015, 12:49 PM
Post #97


Newbie
*

Group: Members
Posts: 7
Joined: 13-April 09
Member No.: 4730



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.

QUOTE
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
Go to the top of the page
 
+Quote Post
Bjorn Jonsson
post Jan 15 2016, 09:20 PM
Post #98


IMG to PNG GOD
****

Group: Moderator
Posts: 1897
Joined: 19-February 04
From: Near fire and ice
Member No.: 38



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
Go to the top of the page
 
+Quote Post
machi
post Jan 15 2016, 10:00 PM
Post #99


Member
***

Group: Members
Posts: 779
Joined: 27-February 08
From: Heart of Europe
Member No.: 4057



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


--------------------
Go to the top of the page
 
+Quote Post
open768
post Jan 30 2016, 11:02 AM
Post #100


Newbie
*

Group: Members
Posts: 4
Joined: 8-August 14
Member No.: 7235



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


QUOTE (Bjorn Jonsson @ Jan 15 2016, 10: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:


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

Go to the top of the page
 
+Quote Post
elakdawalla
post Jan 30 2016, 05:39 PM
Post #101


Administrator
****

Group: Admin
Posts: 5029
Joined: 4-August 05
From: Pasadena, CA, USA, Earth
Member No.: 454



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


--------------------
My blog - @elakdawalla on Twitter - Please support unmannedspaceflight.com by donating here.
Go to the top of the page
 
+Quote Post
Ian R
post Jan 30 2016, 08:41 PM
Post #102


Member
***

Group: Members
Posts: 756
Joined: 18-July 05
From: Plymouth, UK
Member No.: 437



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.

smile.gif


--------------------
Go to the top of the page
 
+Quote Post
JohnVV
post Jan 30 2016, 10:17 PM
Post #103


Member
***

Group: Members
Posts: 819
Joined: 18-November 08
Member No.: 4489



QUOTE (open768 @ Jan 30 2016, 06: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

CODE

$ img2png 0710MR0030160040402522*IMG

IMG2PNG v2.3 20160113

Warning: c:\calib\ does not exist

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


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

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

you really need both the image and the label
Go to the top of the page
 
+Quote Post
Bjorn Jonsson
post Mar 15 2016, 10:05 PM
Post #104


IMG to PNG GOD
****

Group: Moderator
Posts: 1897
Joined: 19-February 04
From: Near fire and ice
Member No.: 38



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

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

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

-debayer
-debayer_ash
-debayer_exp

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

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

See the IMG2PNG webpage for more details.
Go to the top of the page
 
+Quote Post
Bjorn Jonsson
post Oct 8 2016, 01:03 PM
Post #105


IMG to PNG GOD
****

Group: Moderator
Posts: 1897
Joined: 19-February 04
From: Near fire and ice
Member No.: 38



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.
Go to the top of the page
 
+Quote Post

8 Pages V  « < 5 6 7 8 >
Reply to this topicStart new topic

 



RSS Lo-Fi Version Time is now: 18th August 2017 - 08:44 AM
RULES AND GUIDELINES
Please read the Forum Rules and Guidelines before posting.

IMAGE COPYRIGHT
Images posted on UnmannedSpaceflight.com may be copyrighted. Do not reproduce without permission. Read here for further information on space images and copyright.

OPINIONS AND MODERATION
Opinions expressed on UnmannedSpaceflight.com are those of the individual posters and do not necessarily reflect the opinions of UnmannedSpaceflight.com or The Planetary Society. The all-volunteer UnmannedSpaceflight.com moderation team is wholly independent of The Planetary Society. The Planetary Society has no influence over decisions made by the UnmannedSpaceflight.com moderators.
SUPPORT THE FORUM
Unmannedspaceflight.com is a project of the Planetary Society and is funded by donations from visitors and members. Help keep this forum up and running by contributing here.