Nikos,<br><br>You can use the VRT format [1] in GDAL to perform this. The ComplexSource elements can have an LUT element. It can be used to specify your lookup table. The values in between are interpolated linearly.<br><br>
[1]: <a href="http://www.gdal.org/gdal_vrttut.html">http://www.gdal.org/gdal_vrttut.html</a><br><br><div class="gmail_quote">On Fri, Jun 10, 2011 at 10:19 PM, Nikolaos Hatzopoulos <span dir="ltr"><<a href="mailto:nhatzop@gmail.com">nhatzop@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Rapid response for true color has this:<br><br>;- Rapid Response default enhancement: 0,0, 30,110, 60,160, 120,210, 190,240, 255,255<br>
x = byte([0, 30, 60, 120, 190, 255])<br>y = byte([0, 110, 160, 210, 240, 255])<br><br>
;- Rapid Response cloud enhancement: 0,0, 25,90, 55,140, 100,175, 255,255<br>if keyword_set(cloud) then begin<br> x = byte([0, 25, 55, 100, 255])<br> y = byte([0, 90, 140, 175, 255])<br>endif<br><br><br>how it can be programmed in gdal language?<br>
<br>--Nikos<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Thu, Jun 9, 2011 at 8:42 PM, Brian Case <span dir="ltr"><<a href="mailto:rush@winkey.org" target="_blank">rush@winkey.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Nikos<br>
<br>
143, and 721<br>
<font color="#888888"><br>
Brian<br>
</font><div><div></div><div><br>
On Thu, 2011-06-09 at 16:49 -0700, Nikolaos Hatzopoulos wrote:<br>
> for modis truecolor images?<br>
><br>
> --Nikos<br>
><br>
> On Thu, Jun 9, 2011 at 4:44 PM, Brian Case <<a href="mailto:rush@winkey.org" target="_blank">rush@winkey.org</a>> wrote:<br>
> Jonathan<br>
><br>
> I don't know about worldview, but with modis I wound up using<br>
> multiple<br>
> ranges<br>
><br>
> 0:0,750:110,1500:160,3000:210,4750:240,6375:255<br>
><br>
> see <lut> in the vrt tutorial<br>
><br>
> Brian<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Thu, 2011-06-09 at 12:39 -0700, Jonathan Greenberg wrote:<br>
> > Brian:<br>
> ><br>
> ><br>
> > Thanks! Great solution, definitely saved me some time. The<br>
> main<br>
> > issue (in terms of doing this entirely within GDAL) is<br>
> getting the<br>
> > right scaling to make the image look good. I was able to<br>
> figure out<br>
> > the correct scale range within ENVI, and then apply the<br>
> scales as you<br>
> > suggested below. Nikos' suggestion to use rgb2pct makes me<br>
> wonder if<br>
> > there is some way to figure out the optimal scale (which,<br>
> AFAIK, is<br>
> > part of how rgb2pct is functioning) to apply to this image.<br>
> ><br>
> ><br>
> > Incidentally, what I'm trying to do is load Worldview-2 data<br>
> onto an<br>
> > iPad 2 for use with the GISRoam mobile mapping app.<br>
> Worldview-2 is<br>
> > 16-bit per band, 8 band data, with a very high dynamic range<br>
> (we have<br>
> > snow in our image, so we have lots of VERY bright pixels<br>
> which throw<br>
> > off the adjustment if using -scale without any parameters).<br>
> 99%<br>
> > (100%?) of mobile mapping applications need 3-band data,<br>
> usually with<br>
> > only 8 bits per band.<br>
> ><br>
> ><br>
> > Pushing forward, but if someone knows how to figure out an<br>
> optimal set<br>
> > of scale values to use within GDAL, please post the<br>
> solution.<br>
> ><br>
> ><br>
> > --j<br>
> ><br>
> > On Wed, Jun 8, 2011 at 9:45 PM, Brian Case <<a href="mailto:rush@winkey.org" target="_blank">rush@winkey.org</a>><br>
> wrote:<br>
> > Jonathan<br>
> ><br>
> > you can do scaling on individual bands.<br>
> ><br>
> > gdal_translate -b 1 -scale 0 5000 -ot Byte -of VRT<br>
> infile<br>
> > outfile1.vrt<br>
> > gdal_translate -b 2 -scale 0 4000 -ot Byte -of VRT<br>
> infile<br>
> > outfile2.vrt<br>
> > gdal_translate -b 3 -scale 0 3000 -ot Byte -of VRT<br>
> infile<br>
> > outfile3.vrt<br>
> ><br>
> > gdalbuildvrt -separate output.vrt outfile1.vrt<br>
> outfile2.vrt<br>
> > 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<br>
> 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>
> ><br>
> > Brian<br>
> ><br>
> ><br>
> > On Wed, 2011-06-08 at 19:31 -0700, Jonathan<br>
> Greenberg wrote:<br>
> > > Nikos and GDALers:<br>
> > ><br>
> > ><br>
> > > This is CLOSE to what I'm looking to do, but I'm<br>
> having a<br>
> > hard time<br>
> > > getting it working properly. Here's my input<br>
> dataset<br>
> > gdalinfo dump:<br>
> > ><br>
> > ><br>
> > > ***<br>
> > ><br>
> > ><br>
> > > Driver: ENVI/ENVI .hdr Labelled<br>
> > > Files:<br>
> ><br>
> 10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.envi<br>
> > ><br>
> ><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 =<br>
> (0.000004500000005,-0.000004500000005)<br>
> > > Image Structure Metadata:<br>
> > > INTERLEAVE=BAND<br>
> > > Corner Coordinates:<br>
> > > Upper Left (-120.0664800, 39.2715540) (120d<br>
> 3'59.33"W,<br>
> > > 39d16'17.59"N)<br>
> > > Lower Left (-120.0664800, 39.0388500) (120d<br>
> 3'59.33"W, 39d<br>
> > > 2'19.86"N)<br>
> > > Upper Right (-119.8763325, 39.2715540)<br>
> (119d52'34.80"W,<br>
> > > 39d16'17.59"N)<br>
> > > Lower Right (-119.8763325, 39.0388500)<br>
> (119d52'34.80"W, 39d<br>
> > > 2'19.86"N)<br>
> > > Center (-119.9714062, 39.1552020)<br>
> (119d58'17.06"W, 39d<br>
> > > 9'18.73"N)<br>
> > > Band 1 Block=42255x1 Type=UInt16,<br>
> ColorInterp=Undefined<br>
> > > Band 2 Block=42255x1 Type=UInt16,<br>
> ColorInterp=Undefined<br>
> > > Band 3 Block=42255x1 Type=UInt16,<br>
> ColorInterp=Undefined<br>
> > ><br>
> > ><br>
> > > ***<br>
> > ><br>
> > ><br>
> > > I need to end up with a Byte TIF image with good<br>
> color<br>
> > balance from<br>
> > > this input. Running rgb2pct.py on this dataset<br>
> just<br>
> > outputted a<br>
> > > "blank" (grey) image. Running gdal_translate -of<br>
> GTiff -ot<br>
> > Byte<br>
> > > -scale [min] [max] worked somewhat, but its near<br>
> impossible<br>
> > to get<br>
> > > this looking right, since the scaling I want to do<br>
> differs<br>
> > from band<br>
> > > to band (e.g. if there any way to use -scale to<br>
> adjust each<br>
> > band<br>
> > > separately)? Alternatively, how would I get<br>
> rgb2pct.py<br>
> > 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<br>
> Hatzopoulos<br>
> > > <<a href="mailto:nhatzop@gmail.com" target="_blank">nhatzop@gmail.com</a>> wrote:<br>
> > > why you don't try rgb2pct<br>
> > <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<br>
> Greenberg<br>
> > > <<a href="mailto:greenberg@ucdavis.edu" target="_blank">greenberg@ucdavis.edu</a>> wrote:<br>
> > ><br>
> > ><br>
> > > Folks:<br>
> > ><br>
> > ><br>
> > > I am using a piece of software<br>
> which is<br>
> > relying on an<br>
> > > older version of GDAL that doesn't<br>
> have the<br>
> > "fix" to<br>
> > > deal with > 8 bit geotiffs (it is<br>
> trying to<br>
> > make a<br>
> > > jpeg overlay but can't from a 16<br>
> bit image.<br>
> > I think<br>
> > > this is the issue:<br>
> > ><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<br>
> Byte) the<br>
> > output<br>
> > > image looks really washed out.<br>
> Any hints<br>
> > for getting<br>
> > > the best quality output from a 16<br>
> bit to to<br>
> > 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<br>
> and Remote<br>
> > Sensing<br>
> > > (CSTARS)<br>
> > > Department of Land, Air and Water<br>
> Resources<br>
> > > University of California, Davis<br>
> > > One Shields Avenue<br>
> > > Davis, CA 95616<br>
> > > Phone: <a href="tel:415-763-5476" value="+14157635476" target="_blank">415-763-5476</a><br>
> > > AIM: jgrn307, MSN:<br>
> <a href="mailto:jgrn307@hotmail.com" target="_blank">jgrn307@hotmail.com</a>,<br>
> > Gchat: jgrn307<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > _______________________________________________<br>
> > > gdal-dev mailing list<br>
> > > <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
> > ><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<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" target="_blank">415-763-5476</a><br>
> > > AIM: jgrn307, MSN: <a href="mailto:jgrn307@hotmail.com" target="_blank">jgrn307@hotmail.com</a>, Gchat:<br>
> jgrn307<br>
> > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > gdal-dev mailing list<br>
> > > <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">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>
> ><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" target="_blank">415-763-5476</a><br>
> > AIM: jgrn307, MSN: <a href="mailto:jgrn307@hotmail.com" target="_blank">jgrn307@hotmail.com</a>, Gchat: jgrn307<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > gdal-dev mailing list<br>
> > <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">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>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">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>
</div></div></blockquote></div><br>
</div></div><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></blockquote></div><br><br clear="all"><br>-- <br>Best regards,<br>Chaitanya kumar CH.<br>
/tʃaɪθənjə/ /kʊmɑr/ <br>+91-9494447584<br>17.2416N 80.1426E<br>