1.8 compiled from source -marius
On Fri, 2011-07-08 at 18:02 -0700, Michael Corey wrote: > That certainly could be. I'm running GDAL 1.8 from the kyngchaos site. > Which version are you running? > > Thanks, > > Michael Corey > > > On 7/8/11 5:56 PM, Marius Jigmond wrote: > > > > > > > On Fri, 2011-07-08 at 08:14 -0700, Michael Corey wrote: > > > > > OK, I did a little more work on this, and I've narrowed down what's > > > going on, but I could still use some help in figuring out how to solve it. > > > > > > Here's my original image: > > > > > > http://mikejcorey.com/spatial/diablo-orig-5pct.tif > > > > > > The original appears to have an RGBA setup (RGB channels and an alpha > > > channel). > > > When I run this: > > > > > > gdalwarp -crop_to_cutline -cutline cutout.shp sourceimage.tif > > > diablo-cutline.tif > > > > > > Here's what I get: > > > > > > http://mikejcorey.com/spatial/diablo-cutline-5pct.tif > > > > > > This comes out as an RGB image with no alpha channel, with each channel > > > being semi-transparent. > > > > > > > Not in my case. Could there be something wrong with your GDAL setup? > > I drew a shapefile mask and ran the above command but my result is > > RGBA, the alpha band is not lost. See mask and result here: > > http://ubuntuone.com/p/13WR/ > > > > the output of gdalinfo: > > marius@mobi:~/Downloads$ gdalinfo diablo_cutl.tif > > Driver: GTiff/GeoTIFF > > Files: diablo_cutl.tif > > Size is 266, 224 > > Coordinate System is: > > PROJCS["NAD83 / UTM zone 10N", > > GEOGCS["NAD83", > > DATUM["North_American_Datum_1983", > > SPHEROID["GRS 1980",6378137,298.2572221010002, > > AUTHORITY["EPSG","7019"]], > > AUTHORITY["EPSG","6269"]], > > PRIMEM["Greenwich",0], > > UNIT["degree",0.0174532925199433], > > AUTHORITY["EPSG","4269"]], > > PROJECTION["Transverse_Mercator"], > > PARAMETER["latitude_of_origin",0], > > PARAMETER["central_meridian",-123], > > PARAMETER["scale_factor",0.9996], > > PARAMETER["false_easting",500000], > > PARAMETER["false_northing",0], > > UNIT["metre",1, > > AUTHORITY["EPSG","9001"]], > > AUTHORITY["EPSG","26910"]] > > Origin = (693798.721929854014888,3902305.751849883235991) > > Pixel Size = (20.022668877344305,-20.040546259961307) > > Metadata: > > AREA_OR_POINT=Area > > Image Structure Metadata: > > INTERLEAVE=PIXEL > > Corner Coordinates: > > Upper Left ( 693798.722, 3902305.752) (120d52'12.04"W, > > 35d14'42.43"N) > > Lower Left ( 693798.722, 3897816.669) (120d52'15.84"W, > > 35d12'16.81"N) > > Upper Right ( 699124.752, 3902305.752) (120d48'41.44"W, > > 35d14'38.67"N) > > Lower Right ( 699124.752, 3897816.669) (120d48'45.35"W, > > 35d12'13.05"N) > > Center ( 696461.737, 3900061.211) (120d50'28.67"W, > > 35d13'27.75"N) > > Band 1 Block=266x7 Type=Byte, ColorInterp=Red > > Mask Flags: PER_DATASET ALPHA > > Band 2 Block=266x7 Type=Byte, ColorInterp=Green > > Mask Flags: PER_DATASET ALPHA > > Band 3 Block=266x7 Type=Byte, ColorInterp=Blue > > Mask Flags: PER_DATASET ALPHA > > Band 4 Block=266x7 Type=Byte, ColorInterp=Alpha > > > > -marius > > > > > > > However, if I do this: > > > > > > gdalwarp -dstalpha -crop_to_cutline -cutline cutout.shp sourceimage.tif > > > diablo-dstalpha-cutline.tif > > > > > > I get this: > > > > > > http://mikejcorey.com/spatial/diablo-dstalpha-cutline-5pct.tif > > > > > > This one is strange, because it appears to be a grayscale image. But > > > when I open it in Photoshop, I see that it actually has 4 alpha > > > channels. I suspect that those are just getting set incorrectly as alpha > > > and are in fact the RGB channels, but can someone explain that behavior > > > or how to fix it? > > > > > > What I want to end up with is a clipped RGB image (or RGBA) image where > > > nodata is transparent and the RGB isn't translucent. > > > > > > Thanks again! > > > > > > Michael Corey > > > > > > > > > > > > On 7/7/11 7:13 AM, Eli Adam wrote: > > > > Michael, > > > > > > > >>>> On 7/6/2011 at 5:35 PM, in message<4e14ff42.50...@cironline.org>, > > > >>>> Michael > > > > Corey<mco...@cironline.org> wrote: > > > >> Sure, I've uploaded samples here. > > > >> > > > >> http://www.mikejcorey.com/spatial/diablo-box-sample.tif > > > >> http://www.mikejcorey.com/spatial/diablo-cutout-sample.tif > > > > I don't notice the semi-transparency in these scaled down images. > > > > Perhaps it is the way your viewer reads the mask? > > > > > > > >> These are the same as the images created by the process I described > > > >> (but > > > >> scaled down). > > > >> > > > >> To your point about specifying size in the first step -- will that make > > > >> the process run faster, or does it do the scaling down after it builds > > > >> the full-resolution image? > > > >> > > > >> Also, I notice that my filesize always gets significantly bigger when I > > > >> do the cutout step, which seems counter-intuitive to me since in theory > > > >> shouldn't there be less information present once the cutout is done? > > > > -cutline does not 'discard' any data. The extent of the data remains > > > > the same unless you reset those extents. You can do that with > > > > -crop_to_cutline. Here are some details from the gdalwarp page, > > > > http://gdal.org/gdalwarp.html : > > > > > > > > -crop_to_cutline: > > > > (GDAL>= 1.8.0) Crop the extent of the target dataset to the extent > > > > of the cutline. > > > > > > > > Polygon cutlines may be used as a mask to restrict the area of the > > > > destination file that may be updated, including blending. If the OGR > > > > layer containing the cutline features has no explicit SRS, the cutline > > > > features must be in the georeferenced units of the destination file. > > > > When outputing to a not yet existing target dataset, its extent will be > > > > the one of the original raster unless -te or -crop_to_cutline are > > > > specified. > > > > > > > > Best Regards, Eli > > > > > > > >> Thanks for your help! > > > >> > > > >> Michael Corey > > > >> > > > >> > > > >> On 7/6/11 5:01 PM, Chaitanya kumar CH wrote: > > > >>> Michael, > > > >>> > > > >>> Can you provide screenshots of > > > >>> diablo-combined-center-utm10-70pct-box.tif and > > > >>> diablo-combined-center-utm10-70pct-cutout.tif for comparison? > > > >>> > > > >>> By the way, you can perform the actions of the two gdal_translate > > > >>> commands in the first step with the gdal_merge.py script itself unless > > > >>> you want to use a specific resampling algorithm. > > > >>> > > > >>> On Thu, Jul 7, 2011 at 4:28 AM, Michael Corey<mco...@cironline.org > > > >>> <mailto:mco...@cironline.org>> wrote: > > > >>> > > > >>> Hi all: > > > >>> > > > >>> I'm using a shapefile as a clipping mask to cut out the shoreline > > > >>> from some DOQ files that I have merged together. But when I do > > > >>> the > > > >>> clipping step, I end up with unwanted semitransparency in the > > > >>> non-clipped areas. > > > >>> > > > >>> I'm pretty sure the problem is only with my gdalwarp step at the > > > >>> end. > > > >>> > > > >>> Here's my process: > > > >>> > > > >>> gdal_merge.py -init "255" -o diablo-combined-center-utm10.tif > > > >>> file > > > >>> file file file > > > >>> > > > >>> gdal_translate -outsize 70% 70% diablo-combined-center-utm10.tif > > > >>> diablo-combined-center-utm10-70pct.tif > > > >>> > > > >>> ogrinfo -al ./diablo_canyon_detail_clipper.shp > > > >>> //Extent: (XXXX, YYYY) - (XXXX, YYYY) > > > >>> > > > >>> gdal_translate -projwin XXXX YYYY XXXX YYYY > > > >>> diablo-combined-center-utm10-70pct.tif > > > >>> diablo-combined-center-utm10-70pct-box.tif > > > >>> > > > >>> gdalwarp -co COMPRESS=DEFLATE -cutline > > > >>> ./diablo_canyon_detail_clipper.shp > > > >>> diablo-combined-center-utm10-70pct-box.tif > > > >>> diablo-combined-center-utm10-70pct-cutout.tif > > > >>> > > > >>> Can anyone help? > > > >>> > > > >>> Thanks! > > > >>> > > > >>> -- > > > >>> Michael Corey > > > >>> > > > >>> _______________________________________________ > > > >>> gdal-dev mailing list > > > >>> gdal-dev@lists.osgeo.org<mailto:gdal-dev@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 > > > _______________________________________________ > > > gdal-dev mailing list > > > gdal-dev@lists.osgeo.org > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
