[gdal-dev] Giventiff with colortable, how do i assign one of the colors to be an alpha channel

[Isaac Gerg]

I mispoke.

rgb2pct.py will work but only on RGB images -- no colortables.  When I use
it on a RGBA image, the transparency is no longer preservered.

Isaac


On Wed, Jan 16, 2013 at 3:17 PM, Even Rouault
<even.rouault at mines-paris.org>wrote:

> Le mercredi 16 janvier 2013 20:58:51, Isaac Gerg a écrit :
> > Even,
> > Thanks for your quick response.
> >
> > 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.
> >
> > 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.
> >
> > Anyways, I must mosaic these 20 .tifs together.  These tifs are indexed
> > images with a colormap.  Here is my current algorithm:
> > 1. Expand images to RGBA using gdal_translate
> > 2. Rotate images north up using gdal_warp
> > 3. Mosiac images using gdal_merge with -co COMPRESS=LZW -co PREDICTOR=1
> -ot
> > Byte -co TILED=YES -n 0
> > 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.
> > 4. Run the gdal_retile to make image pyramid.  This will yeild a size
> that
> > is roughly twice that of my mosiac.
> >
> > Is there any way I can make the RGBA file in step 3 smaller in size
> > specifically to match the theoretical size of 60MB?
>
> You can try rgb2pct.py on the mosaic
>
> Or you can also try to gdal_translate -co COMPRESS=LZW on the mosaic, since
> I'm not sure how efficient the compression done by gdal_merge will be.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20130116/c5a4b120/attachment.html>