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