Re: [gdal-dev] Unwanted partial transparency when clipping

[Michael Corey]

I see -- you're right about QGIS.

I'm mostly using imagery for static or motion graphics, so my workflow 
ends up in graphics software like Photoshop, After Effects and other 
video, which all tend to handle imagery in roughly the same way. So I 
think I'll just have to do the translation to no alpha band before 
importing into those programs. I'm surprised they handle things that 
differently, but it's not an impossible thing to get around.


Thanks all for your help!

Michael Corey


On 7/8/11 6:59 PM, Marius Jigmond wrote:
I use QGIS which knows how to interpret the bands. I have no idea how 
Photoshop handles the alpha band. You can try specifying -dstnodata:
gdalwarp -crop_to_cutline -cutline mask.shp -dstnodata "0 0 0" 
source.tif dest.tif
this should output a RGBA tif with NoData=0 (black) and maybe 
Photoshop can interpret the NoData tag.


You might also want to try nearblack:
http://www.gdal.org/nearblack.html

I suppose it would be important to know what the final purpose of 
these images is because as far as GIS software goes just about all can 
read the cropped tif just fine with proper transparency.


-marius

On Fri, 2011-07-08 at 18:24 -0700, Michael Corey wrote:
Actually when I opened up your sample file in Photoshop I got the 
same results as I had earlier. What viewer are you using to look at 
your output files?


Also, I did find a workaround that at least improves the situation 
for me.


First I translate the source images:

gdal_translate source1.tif source1-noalpha.tif -b 1 -b 2 -b 3 -mask 4 
-co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR --config 
GDAL_TIFF_INTERNAL_MASK YES


Then use warp to do my merging and clipping:

gdalwarp -crop_to_cutline -cutline 
~/Documents/GIS/usa/California/doq/diablo-fullzoom-cutout.shp 
source1-noalpha.tif source2-noalpha.tif fullzoom-clipped.tif


I still have to use Photoshop to get rid of the nodata section, but 
at least my transparency isn't affected.


Any ideas how to get rid of the black and have transparent pixels 
instead, anyone?


Thanks again,
Michael Corey

On 7/8/11 6:12 PM, Marius Jigmond wrote:

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",50],
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 -cu

Re: [gdal-dev] Unwanted partial transparency when clipping

[Marius Jigmond]

I use QGIS which knows how to interpret the bands. I have no idea how
Photoshop handles the alpha band. You can try specifying -dstnodata:
gdalwarp -crop_to_cutline -cutline mask.shp -dstnodata "0 0 0"
source.tif dest.tif
this should output a RGBA tif with NoData=0 (black) and maybe Photoshop
can interpret the NoData tag.

You might also want to try nearblack:
http://www.gdal.org/nearblack.html

I suppose it would be important to know what the final purpose of these
images is because as far as GIS software goes just about all can read
the cropped tif just fine with proper transparency.

-marius

On Fri, 2011-07-08 at 18:24 -0700, Michael Corey wrote:

> Actually when I opened up your sample file in Photoshop I got the same
> results as I had earlier. What viewer are you using to look at your
> output files?
> 
> Also, I did find a workaround that at least improves the situation for
> me.
> 
> First I translate the source images:
> 
> gdal_translate source1.tif source1-noalpha.tif -b 1 -b 2 -b 3 -mask 4
> -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR --config
> GDAL_TIFF_INTERNAL_MASK YES
> 
> Then use warp to do my merging and clipping:
> 
> gdalwarp -crop_to_cutline -cutline
> ~/Documents/GIS/usa/California/doq/diablo-fullzoom-cutout.shp
> source1-noalpha.tif source2-noalpha.tif fullzoom-clipped.tif
> 
> I still have to use Photoshop to get rid of the nodata section, but at
> least my transparency isn't affected.
> 
> Any ideas how to get rid of the black and have transparent pixels
> instead, anyone?
> 
> Thanks again,
> 
> Michael Corey
> 
> 
> On 7/8/11 6:12 PM, Marius Jigmond wrote: 
> 
> > 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",50],
> > > > 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, Colo

Re: [gdal-dev] Unwanted partial transparency when clipping

[Marius Jigmond]

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",50],
> > 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  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 t

Re: [gdal-dev] Unwanted partial transparency when clipping

[Michael Corey]

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",50],
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
>  Coreymailto: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 geor

Re: [gdal-dev] Unwanted partial transparency when clipping

[Marius Jigmond]

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",50],
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  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 dat

Re: [gdal-dev] Unwanted partial transparency when clipping

[Michael Corey]

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.


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  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 Coreymailto: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: (, ) - (, )

 gdal_translate -projwin    
 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
 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

Re: [gdal-dev] Unwanted partial transparency when clipping

[Brian Case]

Michael,

another option is to use gdalwarp to merge images together.

Brian

On Thu, 2011-07-07 at 09:47 -0700, Michael Corey wrote:
> Thanks for your responses, Chaitanya and Eli. The semitransparency isn't 
> really noticeable until you put the image on top of something else (in 
> Photoshop or another program).
> 
> It looks like the problem is actually in my gdal_merge.py command. 
> That's where the semitransparency is getting introduced.
> 
> gdal_merge.py -init "255" -o diablo-combined-utm10.tif file file file
> 
> What I'm trying to get is a merged image where no data = transparent. 
> Would this be correct in that case?
> 
> gdal_merge.py -n "255" -ul_lr 380309.272908 4653610.244134 
> 1317796.950998 3614484.073320 -o test-combined.tif file file file
> 
> Michael Corey
> Digital Innovations Editor
> Center for Investigative Reporting
> 510.809.3178
> 
> 
> 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  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 >>> >  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: (, ) - (, )
> >>>
> >>>  gdal_translate -projwin    
> >>>  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
> >>>  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 m

Re: [gdal-dev] Unwanted partial transparency when clipping

[Michael Corey]

Thanks for your responses, Chaitanya and Eli. The semitransparency isn't 
really noticeable until you put the image on top of something else (in 
Photoshop or another program).


It looks like the problem is actually in my gdal_merge.py command. 
That's where the semitransparency is getting introduced.


gdal_merge.py -init "255" -o diablo-combined-utm10.tif file file file

What I'm trying to get is a merged image where no data = transparent. 
Would this be correct in that case?


gdal_merge.py -n "255" -ul_lr 380309.272908 4653610.244134 
1317796.950998 3614484.073320 -o test-combined.tif file file file


Michael Corey
Digital Innovations Editor
Center for Investigative Reporting
510.809.3178


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  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 Coreymailto: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: (, ) - (, )

 gdal_translate -projwin    
 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
 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

Re: [gdal-dev] Unwanted partial transparency when clipping

[Eli Adam]

Michael,

>>> On 7/6/2011 at 5:35 PM, in message <4e14ff42.50...@cironline.org>, Michael
Corey  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 > > 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: (, ) - (, )
>>
>> gdal_translate -projwin    
>> 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 
>> 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

Re: [gdal-dev] Unwanted partial transparency when clipping

[Chaitanya kumar CH]

Michael,

It looks like both the images have the transparency issue.
Please provide the gdalinfo outputs of the rasters.

Specifying the extents in gdal_merge.py will definitely speed things up.

Scaling time has many more variables. It is probably faster in
gdal_translate. Also, gdal_translate also has more options of resampling
methods.

File size not only depends on the information to to stored but also the
encoding. Your original image was compressed more than the output image. If
you want, you can specify the compression creation options to the GDAL
programs. For tiff formats you can see that options at GTiff driver page[1].

[1]: http://www.gdal.org/frmt_gtiff.html

On Thu, Jul 7, 2011 at 6:05 AM, Michael Corey  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
>
> 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?
>
> 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 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: (, ) - (, )
>>
>> gdal_translate -projwin    
>> 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
>> 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
>



-- 
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

Re: [gdal-dev] Unwanted partial transparency when clipping

[Michael Corey]

Sure, I've uploaded samples here.

http://www.mikejcorey.com/spatial/diablo-box-sample.tif
http://www.mikejcorey.com/spatial/diablo-cutout-sample.tif

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?


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 > 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: (, ) - (, )

gdal_translate -projwin    
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 
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

Re: [gdal-dev] Unwanted partial transparency when clipping

[Chaitanya kumar CH]

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  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: (, ) - (, )
>
> gdal_translate -projwin     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
> 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] Unwanted partial transparency when clipping

[Michael Corey]

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: (, ) - (, )

gdal_translate -projwin     
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
http://lists.osgeo.org/mailman/listinfo/gdal-dev