[gdal-dev] Converting from 16 bit to 8 bit images (best
practices?)
Chaitanya kumar CH
chaitanya.ch at gmail.com
Fri Jun 10 13:23:55 EDT 2011
Nikos,
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.
[1]: http://www.gdal.org/gdal_vrttut.html
On Fri, Jun 10, 2011 at 10:19 PM, Nikolaos Hatzopoulos <nhatzop at gmail.com>wrote:
> Rapid response for true color has this:
>
> ;- Rapid Response default enhancement: 0,0, 30,110, 60,160, 120,210,
> 190,240, 255,255
> x = byte([0, 30, 60, 120, 190, 255])
> y = byte([0, 110, 160, 210, 240, 255])
>
> ;- Rapid Response cloud enhancement: 0,0, 25,90, 55,140, 100,175, 255,255
> if keyword_set(cloud) then begin
> x = byte([0, 25, 55, 100, 255])
> y = byte([0, 90, 140, 175, 255])
> endif
>
>
> how it can be programmed in gdal language?
>
> --Nikos
>
>
> On Thu, Jun 9, 2011 at 8:42 PM, Brian Case <rush at winkey.org> wrote:
>
>> Nikos
>>
>> 143, and 721
>>
>> Brian
>>
>> On Thu, 2011-06-09 at 16:49 -0700, Nikolaos Hatzopoulos wrote:
>> > for modis truecolor images?
>> >
>> > --Nikos
>> >
>> > On Thu, Jun 9, 2011 at 4:44 PM, Brian Case <rush at winkey.org> wrote:
>> > Jonathan
>> >
>> > I don't know about worldview, but with modis I wound up using
>> > multiple
>> > ranges
>> >
>> > 0:0,750:110,1500:160,3000:210,4750:240,6375:255
>> >
>> > see <lut> in the vrt tutorial
>> >
>> > Brian
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Thu, 2011-06-09 at 12:39 -0700, Jonathan Greenberg wrote:
>> > > Brian:
>> > >
>> > >
>> > > 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.
>> > >
>> > >
>> > > 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.
>> > >
>> > >
>> > > Pushing forward, but if someone knows how to figure out an
>> > optimal set
>> > > of scale values to use within GDAL, please post the
>> > solution.
>> > >
>> > >
>> > > --j
>> > >
>> > > On Wed, Jun 8, 2011 at 9:45 PM, Brian Case <rush at winkey.org>
>> > wrote:
>> > > Jonathan
>> > >
>> > > you can do scaling on individual bands.
>> > >
>> > > gdal_translate -b 1 -scale 0 5000 -ot Byte -of VRT
>> > infile
>> > > outfile1.vrt
>> > > gdal_translate -b 2 -scale 0 4000 -ot Byte -of VRT
>> > infile
>> > > outfile2.vrt
>> > > gdal_translate -b 3 -scale 0 3000 -ot Byte -of VRT
>> > infile
>> > > outfile3.vrt
>> > >
>> > > gdalbuildvrt -separate output.vrt outfile1.vrt
>> > outfile2.vrt
>> > > outfile3.vrt
>> > >
>> > > gdal_translate -of gtiff output.vrt output.tif
>> > >
>> > >
>> > >
>> > > for more complicated scaling you may need to hand
>> > write a vrt
>> > >
>> > > http://www.gdal.org/gdal_vrttut.html
>> > >
>> > > Brian
>> > >
>> > >
>> > > On Wed, 2011-06-08 at 19:31 -0700, Jonathan
>> > Greenberg wrote:
>> > > > Nikos and GDALers:
>> > > >
>> > > >
>> > > > This is CLOSE to what I'm looking to do, but I'm
>> > having a
>> > > hard time
>> > > > getting it working properly. Here's my input
>> > dataset
>> > > gdalinfo dump:
>> > > >
>> > > >
>> > > > ***
>> > > >
>> > > >
>> > > > Driver: ENVI/ENVI .hdr Labelled
>> > > > Files:
>> > >
>> > 10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.envi
>> > > >
>> > >
>> > 10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.hdr
>> > > > Size is 42255, 51712
>> > > > Coordinate System is:
>> > > > GEOGCS["WGS 84",
>> > > > DATUM["WGS_1984",
>> > > > SPHEROID["WGS 84",6378137,298.257223563,
>> > > > AUTHORITY["EPSG","7030"]],
>> > > > TOWGS84[0,0,0,0,0,0,0],
>> > > > AUTHORITY["EPSG","6326"]],
>> > > > PRIMEM["Greenwich",0,
>> > > > AUTHORITY["EPSG","8901"]],
>> > > > UNIT["degree",0.0174532925199433,
>> > > > AUTHORITY["EPSG","9108"]],
>> > > > AUTHORITY["EPSG","4326"]]
>> > > > Origin = (-120.066479999999999,39.271554000000002)
>> > > > Pixel Size =
>> > (0.000004500000005,-0.000004500000005)
>> > > > Image Structure Metadata:
>> > > > INTERLEAVE=BAND
>> > > > Corner Coordinates:
>> > > > Upper Left (-120.0664800, 39.2715540) (120d
>> > 3'59.33"W,
>> > > > 39d16'17.59"N)
>> > > > Lower Left (-120.0664800, 39.0388500) (120d
>> > 3'59.33"W, 39d
>> > > > 2'19.86"N)
>> > > > Upper Right (-119.8763325, 39.2715540)
>> > (119d52'34.80"W,
>> > > > 39d16'17.59"N)
>> > > > Lower Right (-119.8763325, 39.0388500)
>> > (119d52'34.80"W, 39d
>> > > > 2'19.86"N)
>> > > > Center (-119.9714062, 39.1552020)
>> > (119d58'17.06"W, 39d
>> > > > 9'18.73"N)
>> > > > Band 1 Block=42255x1 Type=UInt16,
>> > ColorInterp=Undefined
>> > > > Band 2 Block=42255x1 Type=UInt16,
>> > ColorInterp=Undefined
>> > > > Band 3 Block=42255x1 Type=UInt16,
>> > ColorInterp=Undefined
>> > > >
>> > > >
>> > > > ***
>> > > >
>> > > >
>> > > > I need to end up with a Byte TIF image with good
>> > color
>> > > balance from
>> > > > this input. Running rgb2pct.py on this dataset
>> > just
>> > > outputted a
>> > > > "blank" (grey) image. Running gdal_translate -of
>> > GTiff -ot
>> > > Byte
>> > > > -scale [min] [max] worked somewhat, but its near
>> > impossible
>> > > to get
>> > > > this looking right, since the scaling I want to do
>> > differs
>> > > from band
>> > > > to band (e.g. if there any way to use -scale to
>> > adjust each
>> > > band
>> > > > separately)? Alternatively, how would I get
>> > rgb2pct.py
>> > > working on the
>> > > > above image correctly? Thanks!
>> > > >
>> > > >
>> > > > --j
>> > > >
>> > > >
>> > > >
>> > > > On Wed, Jun 8, 2011 at 4:10 PM, Nikolaos
>> > Hatzopoulos
>> > > > <nhatzop at gmail.com> wrote:
>> > > > why you don't try rgb2pct
>> > > http://www.gdal.org/rgb2pct.html?
>> > > >
>> > > > --Nikos Hatzopoulos
>> > > >
>> > > >
>> > > > On Wed, Jun 8, 2011 at 2:20 PM, Jonathan
>> > Greenberg
>> > > > <greenberg at ucdavis.edu> wrote:
>> > > >
>> > > >
>> > > > Folks:
>> > > >
>> > > >
>> > > > I am using a piece of software
>> > which is
>> > > relying on an
>> > > > older version of GDAL that doesn't
>> > have the
>> > > "fix" to
>> > > > deal with > 8 bit geotiffs (it is
>> > trying to
>> > > make a
>> > > > jpeg overlay but can't from a 16
>> > bit image.
>> > > I think
>> > > > this is the issue:
>> > > >
>> > > http://trac.osgeo.org/gdal/wiki/TIFF12BitJPEG), but
>> > > > when I do a straight convert (-ot
>> > Byte) the
>> > > output
>> > > > image looks really washed out.
>> > Any hints
>> > > for getting
>> > > > the best quality output from a 16
>> > bit to to
>> > > an 8 bit
>> > > > conversion of a Geotiff?
>> > > >
>> > > >
>> > > > --j
>> > > >
>> > > > --
>> > > > Jonathan A. Greenberg, PhD
>> > > > Assistant Project Scientist
>> > > > Center for Spatial Technologies
>> > and Remote
>> > > Sensing
>> > > > (CSTARS)
>> > > > Department of Land, Air and Water
>> > Resources
>> > > > University of California, Davis
>> > > > One Shields Avenue
>> > > > Davis, CA 95616
>> > > > Phone: 415-763-5476
>> > > > AIM: jgrn307, MSN:
>> > jgrn307 at hotmail.com,
>> > > Gchat: jgrn307
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > _______________________________________________
>> > > > gdal-dev mailing list
>> > > > gdal-dev at lists.osgeo.org
>> > > >
>> > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Jonathan A. Greenberg, PhD
>> > > > Assistant Project Scientist
>> > > > Center for Spatial Technologies and Remote Sensing
>> > (CSTARS)
>> > > > Department of Land, Air and Water Resources
>> > > > University of California, Davis
>> > > > One Shields Avenue
>> > > > Davis, CA 95616
>> > > > Phone: 415-763-5476
>> > > > AIM: jgrn307, MSN: jgrn307 at hotmail.com, Gchat:
>> > jgrn307
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > gdal-dev mailing list
>> > > > gdal-dev at lists.osgeo.org
>> > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > Jonathan A. Greenberg, PhD
>> > > Assistant Project Scientist
>> > > Center for Spatial Technologies and Remote Sensing (CSTARS)
>> > > Department of Land, Air and Water Resources
>> > > University of California, Davis
>> > > One Shields Avenue
>> > > Davis, CA 95616
>> > > Phone: 415-763-5476
>> > > AIM: jgrn307, MSN: jgrn307 at hotmail.com, Gchat: jgrn307
>> > >
>> > >
>> > > _______________________________________________
>> > > gdal-dev mailing list
>> > > gdal-dev at lists.osgeo.org
>> > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>> >
>> >
>> > _______________________________________________
>> > gdal-dev mailing list
>> > gdal-dev at lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>> >
>> >
>>
>>
>>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
Best regards,
Chaitanya kumar CH.
/tʃaɪθənjə/ /kʊmɑr/
+91-9494447584
17.2416N 80.1426E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110610/4a67ba89/attachment-0001.html
More information about the gdal-dev
mailing list