[gdal-dev] Converting from 16 bit to 8 bit images (best
practices?)
Jonathan Greenberg
greenberg at ucdavis.edu
Thu Jun 9 15:39:37 EDT 2011
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110609/97e71454/attachment.html
More information about the gdal-dev
mailing list