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

2011-07-09 Thread 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

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

2011-07-08 Thread 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

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

2011-07-08 Thread 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,

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

2011-07-08 Thread 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

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

2011-07-07 Thread 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

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

2011-07-07 Thread Eli Adam
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

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

2011-07-07 Thread 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

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

2011-07-07 Thread 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

[gdal-dev] Unwanted partial transparency when clipping

2011-07-06 Thread 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.

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

2011-07-06 Thread 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

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

2011-07-06 Thread 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 --