IMG2PNG, PDS/FITS to PNG conversion |
IMG2PNG, PDS/FITS to PNG conversion |
May 3 2010, 01:27 AM
Post
#31
|
|
IMG to PNG GOD Group: Moderator Posts: 2254 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
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. |
|
|
May 3 2010, 02:18 AM
Post
#32
|
|
Member Group: Members Posts: 890 Joined: 18-November 08 Member No.: 4489 |
QUOTE 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 |
|
|
May 3 2010, 08:00 AM
Post
#33
|
|
Newbie Group: Members Posts: 9 Joined: 30-April 10 Member No.: 5339 |
(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. |
|
|
May 3 2010, 08:02 AM
Post
#34
|
|
Newbie Group: Members Posts: 9 Joined: 30-April 10 Member No.: 5339 |
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. |
|
|
May 3 2010, 03:54 PM
Post
#35
|
|
Senior Member Group: Members Posts: 3648 Joined: 1-October 05 From: Croatia Member No.: 523 |
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. -------------------- |
|
|
May 3 2010, 04:13 PM
Post
#36
|
|
Newbie Group: Members Posts: 9 Joined: 30-April 10 Member No.: 5339 |
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. |
|
|
Oct 16 2010, 01:44 AM
Post
#37
|
||
Lord Of The Uranian Rings Group: Members Posts: 798 Joined: 18-July 05 From: Plymouth, UK Member No.: 437 |
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! -------------------- |
|
|
||
Nov 30 2010, 12:27 AM
Post
#38
|
|
Founder Group: Chairman Posts: 14434 Joined: 8-February 04 Member No.: 1 |
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
|
|
|
Dec 1 2010, 11:30 PM
Post
#39
|
|
IMG to PNG GOD Group: Moderator Posts: 2254 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
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. |
|
|
Feb 8 2011, 12:38 AM
Post
#40
|
|
IMG to PNG GOD Group: Moderator Posts: 2254 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
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. |
|
|
Feb 10 2011, 03:07 PM
Post
#41
|
|
Member Group: Members Posts: 796 Joined: 27-February 08 From: Heart of Europe Member No.: 4057 |
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. -------------------- |
|
|
Feb 10 2011, 05:29 PM
Post
#42
|
|
Administrator Group: Admin Posts: 5172 Joined: 4-August 05 From: Pasadena, CA, USA, Earth Member No.: 454 |
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!!! -------------------- My website - My Patreon - @elakdawalla on Twitter - Please support unmannedspaceflight.com by donating here.
|
|
|
Feb 11 2011, 12:50 AM
Post
#43
|
||
IMG to PNG GOD Group: Moderator Posts: 2254 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
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): |
|
|
||
Feb 20 2011, 09:55 PM
Post
#44
|
|
IMG to PNG GOD Group: Moderator Posts: 2254 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
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? |
|
|
Feb 21 2011, 11:27 AM
Post
#45
|
|
Member Group: Members Posts: 796 Joined: 27-February 08 From: Heart of Europe Member No.: 4057 |
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).
-------------------- |
|
|
Lo-Fi Version | Time is now: 24th September 2024 - 11:45 AM |
RULES AND GUIDELINES Please read the Forum Rules and Guidelines before posting. IMAGE 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 funded by the Planetary Society. Please consider supporting our work and many other projects by donating to the Society or becoming a member. |