<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I see -- you're right about QGIS.<br>
<br>
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.<br>
<br>
Thanks all for your help!<br>
<pre class="moz-signature" cols="72">Michael Corey
</pre>
<br>
On 7/8/11 6:59 PM, Marius Jigmond wrote:
<blockquote cite="mid:BLU0-SMTP126A93950AD9F1824FB97C8B2430@phx.gbl"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="GENERATOR" content="GtkHTML/3.32.2">
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:<br>
gdalwarp -crop_to_cutline -cutline mask.shp -dstnodata "0 0 0"
source.tif dest.tif<br>
this should output a RGBA tif with NoData=0 (black) and maybe
Photoshop can interpret the NoData tag.<br>
<br>
You might also want to try nearblack:<br>
<a moz-do-not-send="true"
href="http://www.gdal.org/nearblack.html">http://www.gdal.org/nearblack.html</a><br>
<br>
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.<br>
<br>
-marius<br>
<br>
On Fri, 2011-07-08 at 18:24 -0700, Michael Corey wrote:<br>
<blockquote type="CITE"> 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?<br>
<br>
Also, I did find a workaround that at least improves the
situation for me.<br>
<br>
First I translate the source images:<br>
<br>
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<br>
<br>
Then use warp to do my merging and clipping:<br>
<br>
gdalwarp -crop_to_cutline -cutline
~/Documents/GIS/usa/California/doq/diablo-fullzoom-cutout.shp
source1-noalpha.tif source2-noalpha.tif fullzoom-clipped.tif<br>
<br>
I still have to use Photoshop to get rid of the nodata section,
but at least my transparency isn't affected.<br>
<br>
Any ideas how to get rid of the black and have transparent
pixels instead, anyone?<br>
<br>
Thanks again,
<pre>Michael Corey
</pre>
<br>
On 7/8/11 6:12 PM, Marius Jigmond wrote: <br>
<blockquote type="CITE"> 1.8 compiled from source<br>
<br>
-marius<br>
<br>
On Fri, 2011-07-08 at 18:02 -0700, Michael Corey wrote:<br>
<blockquote type="CITE"> That certainly could be. I'm running
GDAL 1.8 from the kyngchaos site. Which version are you
running?<br>
<br>
Thanks,
<pre>Michael Corey
</pre>
<br>
On 7/8/11 5:56 PM, Marius Jigmond wrote: <br>
<blockquote type="CITE"> <br>
<br>
On Fri, 2011-07-08 at 08:14 -0700, Michael Corey wrote:
<blockquote type="CITE">
<pre>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:
<a moz-do-not-send="true" href="http://mikejcorey.com/spatial/diablo-orig-5pct.tif">http://mikejcorey.com/spatial/diablo-orig-5pct.tif</a>
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:
<a moz-do-not-send="true" href="http://mikejcorey.com/spatial/diablo-cutline-5pct.tif">http://mikejcorey.com/spatial/diablo-cutline-5pct.tif</a>
This comes out as an RGB image with no alpha channel, with each channel
being semi-transparent.
</pre>
</blockquote>
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:<br>
<a moz-do-not-send="true"
href="http://ubuntuone.com/p/13WR/">http://ubuntuone.com/p/13WR/</a><br>
<br>
the output of gdalinfo:<br>
<a moz-do-not-send="true" href="mailto:marius@mobi">marius@mobi</a>:~/Downloads$
gdalinfo diablo_cutl.tif <br>
Driver: GTiff/GeoTIFF<br>
Files: diablo_cutl.tif<br>
Size is 266, 224<br>
Coordinate System is:<br>
PROJCS["NAD83 / UTM zone 10N",<br>
GEOGCS["NAD83",<br>
DATUM["North_American_Datum_1983",<br>
SPHEROID["GRS 1980",6378137,298.2572221010002,<br>
AUTHORITY["EPSG","7019"]],<br>
AUTHORITY["EPSG","6269"]],<br>
PRIMEM["Greenwich",0],<br>
UNIT["degree",0.0174532925199433],<br>
AUTHORITY["EPSG","4269"]],<br>
PROJECTION["Transverse_Mercator"],<br>
PARAMETER["latitude_of_origin",0],<br>
PARAMETER["central_meridian",-123],<br>
PARAMETER["scale_factor",0.9996],<br>
PARAMETER["false_easting",500000],<br>
PARAMETER["false_northing",0],<br>
UNIT["metre",1,<br>
AUTHORITY["EPSG","9001"]],<br>
AUTHORITY["EPSG","26910"]]<br>
Origin = (693798.721929854014888,3902305.751849883235991)<br>
Pixel Size = (20.022668877344305,-20.040546259961307)<br>
Metadata:<br>
AREA_OR_POINT=Area<br>
Image Structure Metadata:<br>
INTERLEAVE=PIXEL<br>
Corner Coordinates:<br>
Upper Left ( 693798.722, 3902305.752) (120d52'12.04"W,
35d14'42.43"N)<br>
Lower Left ( 693798.722, 3897816.669) (120d52'15.84"W,
35d12'16.81"N)<br>
Upper Right ( 699124.752, 3902305.752) (120d48'41.44"W,
35d14'38.67"N)<br>
Lower Right ( 699124.752, 3897816.669) (120d48'45.35"W,
35d12'13.05"N)<br>
Center ( 696461.737, 3900061.211) (120d50'28.67"W,
35d13'27.75"N)<br>
Band 1 Block=266x7 Type=Byte, ColorInterp=Red<br>
Mask Flags: PER_DATASET ALPHA <br>
Band 2 Block=266x7 Type=Byte, ColorInterp=Green<br>
Mask Flags: PER_DATASET ALPHA <br>
Band 3 Block=266x7 Type=Byte, ColorInterp=Blue<br>
Mask Flags: PER_DATASET ALPHA <br>
Band 4 Block=266x7 Type=Byte, ColorInterp=Alpha<br>
<br>
-marius<br>
<br>
<blockquote type="CITE">
<pre>However, if I do this:
gdalwarp -dstalpha -crop_to_cutline -cutline cutout.shp sourceimage.tif
diablo-dstalpha-cutline.tif
I get this:
<a moz-do-not-send="true" href="http://mikejcorey.com/spatial/diablo-dstalpha-cutline-5pct.tif">http://mikejcorey.com/spatial/diablo-dstalpha-cutline-5pct.tif</a>
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<<a moz-do-not-send="true" href="mailto:4E14FF42.50903@cironline.org">4E14FF42.50903@cironline.org</a>>, Michael
> Corey<<a moz-do-not-send="true" href="mailto:mcorey@cironline.org">mcorey@cironline.org</a>> wrote:
>> Sure, I've uploaded samples here.
>>
>> <a moz-do-not-send="true" href="http://www.mikejcorey.com/spatial/diablo-box-sample.tif">http://www.mikejcorey.com/spatial/diablo-box-sample.tif</a>
>> <a moz-do-not-send="true" href="http://www.mikejcorey.com/spatial/diablo-cutout-sample.tif">http://www.mikejcorey.com/spatial/diablo-cutout-sample.tif</a>
> 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, <a moz-do-not-send="true" href="http://gdal.org/gdalwarp.html">http://gdal.org/gdalwarp.html</a> :
>
> -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<<a moz-do-not-send="true" href="mailto:mcorey@cironline.org">mcorey@cironline.org</a>
>>> <<a moz-do-not-send="true" href="mailto:mcorey@cironline.org">mailto:mcorey@cironline.org</a>>> 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
>>> <a moz-do-not-send="true" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><<a moz-do-not-send="true" href="mailto:gdal-dev@lists.osgeo.org">mailto:gdal-dev@lists.osgeo.org</a>>
>>> <a moz-do-not-send="true" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Chaitanya kumar CH.
>>> /t?a???nj?/ /k?m?r/
>>> +91-9494447584
>>> 17.2416N 80.1426E
_______________________________________________
gdal-dev mailing list
<a moz-do-not-send="true" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a moz-do-not-send="true" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
</blockquote>
<pre>_______________________________________________
gdal-dev mailing list
<a moz-do-not-send="true" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a moz-do-not-send="true" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>