Brian:<div><br></div><div>Thanks! Great solution, definitely saved me some time. The main issue (in terms of doing this entirely within GDAL) is getting the right scaling to make the image look good. I was able to figure out the correct scale range within ENVI, and then apply the scales as you suggested below. Nikos' suggestion to use rgb2pct makes me wonder if there is some way to figure out the optimal scale (which, AFAIK, is part of how rgb2pct is functioning) to apply to this image.</div>
<div><br></div><div>Incidentally, what I'm trying to do is load Worldview-2 data onto an iPad 2 for use with the GISRoam mobile mapping app. Worldview-2 is 16-bit per band, 8 band data, with a very high dynamic range (we have snow in our image, so we have lots of VERY bright pixels which throw off the adjustment if using -scale without any parameters). 99% (100%?) of mobile mapping applications need 3-band data, usually with only 8 bits per band.<br>
<br></div><div>Pushing forward, but if someone knows how to figure out an optimal set of scale values to use within GDAL, please post the solution. </div><div><br></div><div>--j</div><div><br><div class="gmail_quote">On Wed, Jun 8, 2011 at 9:45 PM, Brian Case <span dir="ltr"><<a href="mailto:rush@winkey.org">rush@winkey.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Jonathan<br>
<br>
you can do scaling on individual bands.<br>
<br>
gdal_translate -b 1 -scale 0 5000 -ot Byte -of VRT infile outfile1.vrt<br>
gdal_translate -b 2 -scale 0 4000 -ot Byte -of VRT infile outfile2.vrt<br>
gdal_translate -b 3 -scale 0 3000 -ot Byte -of VRT infile outfile3.vrt<br>
<br>
gdalbuildvrt -separate output.vrt outfile1.vrt outfile2.vrt outfile3.vrt<br>
<br>
gdal_translate -of gtiff output.vrt output.tif<br>
<br>
<br>
<br>
for more complicated scaling you may need to hand write a vrt<br>
<br>
<a href="http://www.gdal.org/gdal_vrttut.html" target="_blank">http://www.gdal.org/gdal_vrttut.html</a><br>
<font color="#888888"><br>
Brian<br>
</font><div><div></div><div class="h5"><br>
On Wed, 2011-06-08 at 19:31 -0700, Jonathan Greenberg wrote:<br>
> Nikos and GDALers:<br>
><br>
><br>
> This is CLOSE to what I'm looking to do, but I'm having a hard time<br>
> getting it working properly. Here's my input dataset gdalinfo dump:<br>
><br>
><br>
> ***<br>
><br>
><br>
> Driver: ENVI/ENVI .hdr Labelled<br>
> Files: 10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.envi<br>
> 10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.hdr<br>
> Size is 42255, 51712<br>
> Coordinate System is:<br>
> GEOGCS["WGS 84",<br>
> DATUM["WGS_1984",<br>
> SPHEROID["WGS 84",6378137,298.257223563,<br>
> AUTHORITY["EPSG","7030"]],<br>
> TOWGS84[0,0,0,0,0,0,0],<br>
> AUTHORITY["EPSG","6326"]],<br>
> PRIMEM["Greenwich",0,<br>
> AUTHORITY["EPSG","8901"]],<br>
> UNIT["degree",0.0174532925199433,<br>
> AUTHORITY["EPSG","9108"]],<br>
> AUTHORITY["EPSG","4326"]]<br>
> Origin = (-120.066479999999999,39.271554000000002)<br>
> Pixel Size = (0.000004500000005,-0.000004500000005)<br>
> Image Structure Metadata:<br>
> INTERLEAVE=BAND<br>
> Corner Coordinates:<br>
> Upper Left (-120.0664800, 39.2715540) (120d 3'59.33"W,<br>
> 39d16'17.59"N)<br>
> Lower Left (-120.0664800, 39.0388500) (120d 3'59.33"W, 39d<br>
> 2'19.86"N)<br>
> Upper Right (-119.8763325, 39.2715540) (119d52'34.80"W,<br>
> 39d16'17.59"N)<br>
> Lower Right (-119.8763325, 39.0388500) (119d52'34.80"W, 39d<br>
> 2'19.86"N)<br>
> Center (-119.9714062, 39.1552020) (119d58'17.06"W, 39d<br>
> 9'18.73"N)<br>
> Band 1 Block=42255x1 Type=UInt16, ColorInterp=Undefined<br>
> Band 2 Block=42255x1 Type=UInt16, ColorInterp=Undefined<br>
> Band 3 Block=42255x1 Type=UInt16, ColorInterp=Undefined<br>
><br>
><br>
> ***<br>
><br>
><br>
> I need to end up with a Byte TIF image with good color balance from<br>
> this input. Running rgb2pct.py on this dataset just outputted a<br>
> "blank" (grey) image. Running gdal_translate -of GTiff -ot Byte<br>
> -scale [min] [max] worked somewhat, but its near impossible to get<br>
> this looking right, since the scaling I want to do differs from band<br>
> to band (e.g. if there any way to use -scale to adjust each band<br>
> separately)? Alternatively, how would I get rgb2pct.py working on the<br>
> above image correctly? Thanks!<br>
><br>
><br>
> --j<br>
><br>
><br>
><br>
> On Wed, Jun 8, 2011 at 4:10 PM, Nikolaos Hatzopoulos<br>
> <<a href="mailto:nhatzop@gmail.com">nhatzop@gmail.com</a>> wrote:<br>
> why you don't try rgb2pct <a href="http://www.gdal.org/rgb2pct.html" target="_blank">http://www.gdal.org/rgb2pct.html</a>?<br>
><br>
> --Nikos Hatzopoulos<br>
><br>
><br>
> On Wed, Jun 8, 2011 at 2:20 PM, Jonathan Greenberg<br>
> <<a href="mailto:greenberg@ucdavis.edu">greenberg@ucdavis.edu</a>> wrote:<br>
><br>
><br>
> Folks:<br>
><br>
><br>
> I am using a piece of software which is relying on an<br>
> older version of GDAL that doesn't have the "fix" to<br>
> deal with > 8 bit geotiffs (it is trying to make a<br>
> jpeg overlay but can't from a 16 bit image. I think<br>
> this is the issue:<br>
> <a href="http://trac.osgeo.org/gdal/wiki/TIFF12BitJPEG" target="_blank">http://trac.osgeo.org/gdal/wiki/TIFF12BitJPEG</a>), but<br>
> when I do a straight convert (-ot Byte) the output<br>
> image looks really washed out. Any hints for getting<br>
> the best quality output from a 16 bit to to an 8 bit<br>
> conversion of a Geotiff?<br>
><br>
><br>
> --j<br>
><br>
> --<br>
> Jonathan A. Greenberg, PhD<br>
> Assistant Project Scientist<br>
> Center for Spatial Technologies and Remote Sensing<br>
> (CSTARS)<br>
> Department of Land, Air and Water Resources<br>
> University of California, Davis<br>
> One Shields Avenue<br>
> Davis, CA 95616<br>
> Phone: <a href="tel:415-763-5476" value="+14157635476">415-763-5476</a><br>
> AIM: jgrn307, MSN: <a href="mailto:jgrn307@hotmail.com">jgrn307@hotmail.com</a>, Gchat: jgrn307<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Jonathan A. Greenberg, PhD<br>
> Assistant Project Scientist<br>
> Center for Spatial Technologies and Remote Sensing (CSTARS)<br>
> Department of Land, Air and Water Resources<br>
> University of California, Davis<br>
> One Shields Avenue<br>
> Davis, CA 95616<br>
> Phone: <a href="tel:415-763-5476" value="+14157635476">415-763-5476</a><br>
> AIM: jgrn307, MSN: <a href="mailto:jgrn307@hotmail.com">jgrn307@hotmail.com</a>, Gchat: jgrn307<br>
><br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jonathan A. Greenberg, PhD<br>Assistant Project Scientist<br>Center for Spatial Technologies and Remote Sensing (CSTARS)<br>Department of Land, Air and Water Resources<br>
University of California, Davis<br>One Shields Avenue<br>Davis, CA 95616<br>Phone: 415-763-5476<br>AIM: jgrn307, MSN: <a href="mailto:jgrn307@hotmail.com" target="_blank">jgrn307@hotmail.com</a>, Gchat: jgrn307<br><br>
</div>