New application request - "bit2bit"
Can we have an 'isis2std-stretch-options' application for converting
bit types within isis3....I'd like to convert from 32bit to 16bit and
the stretch options within isis2std are desirable......we have separate
apps that will achieve this, but one application to do this would be
efficient and helpful. right now I'll use 'percent' and pass on min/max
values to 'stretch' or 'cubeatt'....
maybe the isis2std-stretch-options functionality could simply be added
to one of these existing apps?
Sorry this took so long.
I think you have the answer, we should modify stretch to include some of isis2std's functionality. So far I'm thinking of adding:
LINEAR & PIECEWISE - Would use the MIN/MAXPERCENT
MANUAL - Would use the existing PAIRS
All the special pixel abilities would remain as is
How does this sound to you?
It sounds great, I'll look forward to it!!!
Most of the work is done. We need to make sure it is working correctly and get it into the system. I'm hoping it will be in by the end of May.
Not finished yet. Need to talk to you first. I will drop by.
A summary of discussion for this topic:
The recent modification to 'stretch' to allow a user to enter percentages for stretch pairs is a nice, user-friendly idea, but does not address the original request of this post.
- What is being asked is that a user be allowed to change the bit type of a file and be able to specify a minpercent/maxpercent for an output range as an option to actual dn values, and, retain the core base and multiplier to represent (nearly) the original dn values...
The current command to convert (change the attributes) from 32bit to 8bit would be as follows:
stretch from=input.cub to=output.cub+UnsignedByte+0.48:1.28
This command changes input.cub to an 8bit file with an "orange" of 0.48
(0.5% of input) and 1.28 (99.5% of input). This has mapped 0.48 to 1.0 and 1.28
to 254 in 8bit storage world. I had to run percent twice to get the min/max values of
my input file to determine the output range.
- It would be nice if 'percent' a) returned both a min and a max percent (or more), b) would take a list of files and return a percent min/max that represented all files (similar to what maptemplate does for lat/lon ranges), so that a consistent "orange" can be defined for a collection of images when modifying bit-type, or stretch...
3) cubeit allows a user to stack images with different core base and multipliers, it was not allowed in Isis2 for integrity reasons...but, flexibility is also a plus, just dangerous...cubeit currently propagates bit-type..it should probably default to real so that all input dn's can be represented.
I would like to vote for a bit2bit application also. The goal for me is to get to an 8bit cube without running percent twice and stretch and have the ability to choose linear/piecewise/manual. It really already exists but the file gets deleted - it would basically be isis2std but stop at the conversion from the temporary 8bit cub to external format!
BTW, the last time I ran export to PNG, the file size benefits of the PNG were not realized. The PNG was basically non-compressed. I ran ImageMagik "convert" on the ISIS (QT) created PNG and realized a 7X saving in file size in the output PNG. That kind of stinks - another reason to replace QT conversions (besides output type support and 2GB limits) Wink
Is there any progress on this tool? It is very much needed. Thanks.
I need to convert a large number of files to 16bit and remain in isis3....
...is there any kind of time line on this application??
Have concerns about this request been resolved yet??
I'm so sorry to bring this up to the surface again. I'm at a point in the Apollo Metric processing that will make a huge difference if I can "efficiently" convert a large number of large files from 32 to 16 bit...at a minimum, it would be helpful if the percent application could allowing an option for entering both a min/max percentage so it can be ran through just once....I'm trying to avoid writing a script due to my hours on the project, as well as the fact that there are others who have added to this request. If it can't be developed in the two weeks, please tell me and I will take the time to write a script.
Thank you much,
As per our conversations in the past few days, I've created a modified stretch called 'bit2bit'. This works nearly identically to stretch, with one exception. If you toggle USEPERCENTAGES=TRUE, the behavior of the stretch pairs is modified as follows.
The first half of the pair (input) is read as a percentage and is pulled from the histogram of the input cube. In addition (new behavior), the second half of a pair (output) is read as a percentage and is also pulled from the input cube histogram. Both percentages are from the cumulative percent of the histogram of the input cube. Basically, this allows you to base your output DN values on the cumulative percent values of the input image without running hist, percent, etc. to get those DN values. You will still be guessing about the best output percent for your images. Since stretch was already creating a histogram object, this change doesn't slow the "new" program.
Example of how to run:
~moses/src/isis/bit2bit/bit2bit from=AS15-M-0072_crop.cub to=AS15-M-0072_crop_16bit.cub+16bit use=true pairs="2.0:1.0 98:99"
In the example above, you create a linear stretch between 2.0% and 98% of the input image, stretching the DN values to the equivalent DN values of 1.0% (of the input image) to 99% (of the input image). So, assume you had an image with a cumulative 1% of 200, 2% of 300, 98% of 6000, and 99% of 6500. Your new output file would be identical to running:
stretch from=from=AS15-M-0072_crop.cub to=AS15-M-0072_crop_16bit.cub+16bit+200:6500 pairs="300:200 6000:6500"
but you wouldn't have to run percent, hist, or any other program to get those values. Of course, you'll be somewhat in the blind as to what your output DN values are, since you're providing input file percentages instead of output DN values.
Notice that the output cube attribute for bit2bit does not include the output minimum and maximum, which are 1.0% of the input cube and 99% of the output cube respectively (based on the pairs the user gives the program); the output minimum and maximum cube attributes are set within the program rather than by the user and are based on the minimum and maximum output halves of the pairs. I haven't done extensive testing with more than two pairs, but they should simply allow you further control over a piecewise linear stretch, identically to 'stretch'. To be fair, I haven't done extensive testing on any of this... Wink If anything is unclear, let me know what you need to have clarified.
I've put a statically built (against today's isis3nightly) bit2bit program in ~moses/src/isis/bit2bit/ (run it as ~moses/src/isis/bit2bit/bit2bit). It's there instead of the contrib/bin directory because of XML file location requirements. The static linking makes it immune to changes in the ISIS libraries, so it shouldn't be broken tomorrow. However, it also makes it unable to benefit from any improvements to the ISIS classes that it's using, so if there's a bug in any of the classes it is using, those will continue to be there even after fixes to the official ISIS classes are fixed.
You are a hero!!!! I will give it a try! Tammy
bit2bit worked great! Can this get checked into the system? I like the resulting dn's values that are reported in the results group. It would be nice to have a report on how many pixels get mapped to a special pixel value as a result of going from 32bit to 16 or 8bit, one of the boxfilters does this...noisefilter I think?....thank you so much!!!
Hey, Tammy. I'm glad it worked for you. I don't have CVS commit permissions, the code needs some documentation and error checking, and we should build some new unit tests for it... Maybe someone from the development team can take a look at the code and improve it?
bit2bit has been re-built against isis3.2.1. It still resides in ~moses/src/isis/bit2bit.