<div dir="ltr">Even,<div>Thanks for your quick response.</div><div><br></div><div>I believe I understand that three options you presented me.  I believe option 1 is viable but like you mentioned will only work with GDAL software.  Options 2 and 3 are good but, especially with option 3, the resulting tifs are too large.  </div>

<div><br></div><div>I have 20 .tif  which are 3MB a piece.  Together, they form trackline of a sensor data.  I would like to load this information into a WMS server for display in Google Earth or Arc Explorer.  Currently I am using Geoserver.</div>

<div><br></div><div>Anyways, I must mosaic these 20 .tifs together.  These tifs are indexed images with a colormap.  Here is my current algorithm:</div><div style>1. Expand images to RGBA using gdal_translate</div><div style>

2. Rotate images north up using gdal_warp</div><div style>3. Mosiac images using gdal_merge with -co COMPRESS=LZW -co PREDICTOR=1 -ot Byte -co TILED=YES -n 0</div><div style>At this point, I now have an RGBA image that is huge (300MB).  With all the tile collections I must process, 300MB is too big.  I was thinking the total would be around (20 tiles)*(3MB per tile) = 60MB.  300 is simply unacceptable.</div>

<div style>4. Run the gdal_retile to make image pyramid.  This will yeild a size that is roughly twice that of my mosiac.</div><div style><br></div><div style>Is there any way I can make the RGBA file in step 3 smaller in size specifically to match the theoretical size of 60MB?</div>

<div style><br></div><div style>Thanks again,</div><div style>Isaac</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 16, 2013 at 2:21 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le mercredi 16 janvier 2013 20:03:14, Isaac Gerg a écrit :<br>
<div><div class="h5">> Hi All,<br>
><br>
> I have a tiff in which each pixel is a single byte (0-255) which references<br>
> a colortable.  Each element of the colortable has 4 values (RGBA).<br>
><br>
> I would like to convert my "black" color (entry 1 in the color table<br>
> (0,0,0,255)) to be transparent (new colortable entry is (0,0,0,0))<br>
><br>
> Another way to say it is, how do I create a tiff with an indexed colormap<br>
> but also have it contain an alpha channel?<br>
<br>
</div></div>TIFF color palette are only RGB, not RGBA. What you can do, however, is assign<br>
a nodata value (note this is a GDAL specific TIFF tag that will only be<br>
understood by GDAL based software)<br>
<br>
gdal_translate src.tif src_with_nodata.tif -a_nodata 0<br>
<br>
You can create a TIFF with an indexed colormap and an alpha channel with the<br>
following extra steps :<br>
<br>
gdal_translate src_with_nodata.tif mask.tif -b mask<br>
gdalbuildvrt tmp.vrt src.tif mask.tif -separate<br>
gdal_translate src.tif src.vrt -of VRT<br>
<br>
the with a text editor copy the lines that look line the following ones from<br>
src.vrt<br>
<br>
    <ColorInterp>Palette</ColorInterp><br>
    <ColorTable><br>
      <Entry c1="112" c2="120" c3="56" c4="255" /><br>
[...]<br>
      <Entry c1="204" c2="208" c3="164" c4="255" /><br>
    </ColorTable><br>
<br>
and paste them just below <VRTRasterBand dataType="Byte" band="1"> in tmp.vrt<br>
<br>
Finally :<br>
<br>
gdal_translate tmp.vrt pct_with_alpha.tif -co ALPHA=YES<br>
<br>
That's it. But I'm not sure that this will be properly displayed by viewers.<br>
<br>
A safest alternative would be to build a RGBA TIFF :<br>
<br>
gdal_translate -expand rgb src.tif rgb.tif<br>
gdal_translate -b 1 rgb.tif r.tif<br>
gdal_translate -b 2 rgb.tif g.tif<br>
gdal_translate -b 3 rgb.tif b.tif<br>
gdalbuildvrt rgba.vrt r.tif g.tif b.tif mask.tif -separate<br>
gdal_translate rgba.vrt rgba.tif  -co ALPHA=YES<br>
<br>
><br>
> Thanks in advance,<br>
> Isaac<br>
</blockquote></div><br></div>