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.roua...@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. >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
