Re: [gdal-dev] gdaladdo slowness for VRTs

Lähetetty: keskiviikko 5. kesäkuuta 2024 4.36 Vastaanottaja: gdal dev Aihe: [gdal-dev] gdaladdo slowness for VRTs Hi, I spotted a slow calculation of overviews and I'm wondering what could be the reason. $ gdal_create in.tif -if 20240602_230818_SN26_RR_VISUAL_MS.vrt $ time gdaladdo -ro i

[gdal-dev] gdaladdo slowness for VRTs

Hi, I spotted a slow calculation of overviews and I'm wondering what could be the reason. $ gdal_create in.tif -if 20240602_230818_SN26_RR_VISUAL_MS.vrt $ time gdaladdo -ro in.tif gdaladdo -ro in.tif 4,25s user 6,23s system 34% cpu 30,623 total But on the file of the same size and num of bands

Re: [gdal-dev] Gdaladdo and external mask band

uault Lähetetty: keskiviikko 3. huhtikuuta 2024 17.18 Vastaanottaja: Rahkonen Jukka ; 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) Aihe: Re: [gdal-dev] Gdaladdo and external mask band Hi Jukka, I've realized this behaviour was actually documented in https://gdal.org/drive

Re: [gdal-dev] Gdaladdo and external mask band

Hi Jukka, I've realized this behaviour was actually documented in https://gdal.org/drivers/raster/gtiff.html#overviews-and-nodata-masks : "Internal overviews, external nodata mask: when running BuildOverviews() in update mode on the .tif file, only the overviews of the main bands will be gene

[gdal-dev] Gdaladdo and external mask band

Hi, I was making some tests with filegdb raster from Region 5 - State (usda.gov), file https://usfs-public.box.com/shared/static/q96eev9gnsa9hw5bwpmwpmxerbdat0vi.zip I converted the data into GeoTIFF, added overviews, and no

Re: [gdal-dev] gdaladdo does not "respect" GPKG tile matrix

Hi Even, This is great news ! I will check it out as soon as I can. Thanks Philippe On Mon, Jan 8, 2024 at 1:07 PM Even Rouault wrote: > Hi Philippe, > > I no longer reproduce the below issues nor > https://github.com/OSGeo/gdal/issues/3853 with gdaladdo without explicit > level with GDAL maste

Re: [gdal-dev] gdaladdo does not "respect" GPKG tile matrix

Hi Philippe, I no longer reproduce the below issues nor https://github.com/OSGeo/gdal/issues/3853 with gdaladdo without explicit level with GDAL master 3.9dev. This is due to improvement https://github.com/OSGeo/gdal/commit/d178b03e3db that reuse existing overview levels when they are declare

[gdal-dev] gdaladdo does not "respect" GPKG tile matrix

Dear all, A while ago, I opened a ticket which is still opened ( https://github.com/OSGeo/gdal/issues/3853). I recently bumped into this bug with some new data, and I think I tracked the origin. *1) Generate a test image :* gdal_create -of GTIFF -co COMPRESS=LZW -a_srs epsg:4326 -a_ullr -180 90

[gdal-dev] gdaladdo enhancements for partial refresh of overviews

Hi, sitting in https://github.com/OSGeo/gdal/pull/8074, a few enhancements to gdaladdo to be able to selectively refresh only part of overviews. A typical use case is a VRT that mosaics a number of tiles, and where one updates just a few tiles after the initial .vrt.ovr has been created. Eve

Re: [gdal-dev] gdaladdo bigtiff err but --config BIGTIFF was used

cogger v0.0.5 now supports .ovr external overviews. It will automatically set the output cog to bigtiff if required, so your use-case should now be covered. Oh that’s great, thank you! ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osg

Re: [gdal-dev] gdaladdo bigtiff err but --config BIGTIFF was used

cogger v0.0.5 now supports .ovr external overviews. It will automatically set the output cog to bigtiff if required, so your use-case should now be covered. -- Thomas Le lun. 14 juin 2021 à 22:12, a écrit : > > You can create external overviews with the -ro switch > > Yeah, I have those. I was

Re: [gdal-dev] gdaladdo bigtiff err but --config BIGTIFF was used

On Mon, 14 Jun 2021, matt.wil...@yukon.ca wrote: Your initial test.tif file needs to be a bigtiff, i.e. have been created with -co "BIGTIFF=YES". you can then drop the bigtiff config arguments of your gdaladdo call. Ahh, thanks Thomas, that indeed is the problem. Unfortunately for me it means

Re: [gdal-dev] gdaladdo bigtiff err but --config BIGTIFF was used

> You can create external overviews with the -ro switch Yeah, I have those. I was trying to create internal ones instead in order to use cogger ;-) (And behind all of this, a weeping and wailing and gnashing of teeth at the upstream person or persons who decided that creating jpegs and throwing

Re: [gdal-dev] gdaladdo bigtiff err but --config BIGTIFF was used

Matt, You can create external overviews with the -ro switch Even Le 14/06/2021 à 21:12, matt.wil...@yukon.ca a écrit : Your initial test.tif file needs to be a bigtiff, i.e. have been created with -co "BIGTIFF=YES". you can then drop the bigtiff config arguments of your gdaladdo call. Ahh, th

Re: [gdal-dev] gdaladdo bigtiff err but --config BIGTIFF was used

> Your initial test.tif file needs to be a bigtiff, i.e. have been > created with -co "BIGTIFF=YES". you can then drop the bigtiff > config arguments of your gdaladdo call. Ahh, thanks Thomas, that indeed is the problem. Unfortunately for me it means in this case I'm stuck, as the original is

Re: [gdal-dev] gdaladdo bigtiff err but --config BIGTIFF was used

Your initial test.tif file needs to be a bigtiff, i.e. have been created with -co "BIGTIFF=YES". you can then drop the bigtiff config arguments of your gdaladdo call. -- thomas On Wed, Jun 9, 2021 at 5:39 PM wrote: > > I am getting tiff file size exceeded error but am using bigtiff creation > o

[gdal-dev] gdaladdo bigtiff err but --config BIGTIFF was used

I am getting tiff file size exceeded error but am using bigtiff creation options. ~~~ $ gdaladdo -r gauss ^ --config COMPRESS_OVERVIEW WEBP ^ --config PHOTOMETRIC_OVERVIEW YCBCR ^ --config INTERLEAVE_OVERVIEW PIXEL ^ --config QUALITY 87 ^ --config BIGTIFF YES ^ --config BIGTIFF_OVERVIEW YES ^ tes

[gdal-dev] gdaladdo zoom level not supported

I tried to add zoom levels to an mbtiles file using gdaladdo. The mbtiles file was constructed from a large geotiff using gdal_translate. When I ran gdaladdo, I got an error message about zoom levels: ERROR 6: zoom_level > 22 not supported A commenter on stack exchange GIS pointed out that I need

Re: [gdal-dev] gdaladdo zoom level not supported

> When I ran > gdaladdo, I got an error message about zoom levels: > ERROR 6: zoom_level > 22 not supported You will get it also when doing "gdalinfo TLTR.mbtiles". There is a limitation in the driver to zoom_level <= 22, because if the .mbtiles would have world coverage, the dimensions would ov

Re: [gdal-dev] gdaladdo zoom level not supported

The question in gis.stackexchange is this https://gis.stackexchange.com/questions/376827/gdaladdo-zoom-level-not-supported -Jukka Rahkonen- -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lis

Re: [gdal-dev] "gdaladdo: tif_dirwrite.c:2449: TIFFWriteDirectoryTagData: Assertion `datalength<0x80000000UL' failed."

Hi, Do I estimate right that you have about 125 terabytes image data as uncompressed , and the first level overview would make about 32 terabytes? As JPEG compressed it would still make about 3 terabyte .ovr file. That is not too much for BigTIFF that has a size limit at 18000 petabytes, but it ma

Re: [gdal-dev] "gdaladdo: tif_dirwrite.c:2449: TIFFWriteDirectoryTagData: Assertion `datalength<0x80000000UL' failed."

Mats, > I'm trying to build overviews on a large vrt file, but I'm getting the > following error message >"gdaladdo: tif_dirwrite.c:2449: TIFFWriteDirectoryTagData: Assertion > `datalength<0x8000UL' failed." Ouch, you hit a bug in libtiff. What you are trying to create is an absolutely lar

[gdal-dev] "gdaladdo: tif_dirwrite.c:2449: TIFFWriteDirectoryTagData: Assertion `datalength<0x80000000UL' failed."

Hi, I'm trying to build overviews on a large vrt file, but I'm getting the following error message "gdaladdo: tif_dirwrite.c:2449: TIFFWriteDirectoryTagData: Assertion `datalength<0x8000UL' failed." Operating system ubuntu server 18.04 256 Gb memory GDAL version 2.4 This is what I do: - cr

Re: [gdal-dev] gdaladdo taking very long time to build overviews for large extent mosaic.

On lundi 21 octobre 2019 07:28:15 CEST FelixH wrote: > Are there any plans to fix the context switching issues with libtiff? This has been fixed in libtiff and GDAL master in June. Even -- Spatialys - Geospatial professional services http://www.spatialys.com

Re: [gdal-dev] gdaladdo taking very long time to build overviews for large extent mosaic.

Are there any plans to fix the context switching issues with libtiff? This seems to be a quite important issue, given that the key feature of gdaladdo is only really usable with a workaround or by waiting for a very long time. Cheers, Felix -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL

Re: [gdal-dev] gdaladdo taking very long time to build overviews for large extent mosaic.

On mardi 6 novembre 2018 11:08:14 CET Pradeep kumar wrote: > Dear gdal-dev team, > > we have to build a mosaic for 350 aerial images. These images are gray > images and have an alpha band. The avg size of each images is 24000x24000. > The size of final mosaic would be 1676843x1441203. The coordi

[gdal-dev] gdaladdo taking very long time to build overviews for large extent mosaic.

Dear gdal-dev team, we have to build a mosaic for 350 aerial images. These images are gray images and have an alpha band. The avg size of each images is 24000x24000. The size of final mosaic would be 1676843x1441203. The coordinate system of input images and final mosaic is EPSG:25832 First app

Re: [gdal-dev] gdaladdo without explicit factors specified

On mercredi 28 juin 2017 14:10:17 CEST Even Rouault wrote: > Hi, > > I'm pretty sure this must have annoyed a lot of people. When you run > gdaladdo, you need to specify the appropriate overview levels. Generally > you use power-of-two factors, but the question is then: what is the last > relevant

Re: [gdal-dev] gdaladdo without explicit factors specified

-config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL" without going to http://www.gdal.org/gdaladdo.html or by re-using their old scripts? -Jukka Rahkonen- -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-gdaladdo-without-explicit-factors-specified-tp53258

Re: [gdal-dev] gdaladdo without explicit factors specified

On 2017-06-28 9:10 AM, Even Rouault wrote: Hi, I'm pretty sure this must have annoyed a lot of people. When you run gdaladdo, you need to specify the appropriate overview levels. Generally you use power-of-two factors, but the question is then: what is the last relevant factor given the dimen

Re: [gdal-dev] gdaladdo without explicit factors specified

On Wed, Jun 28, 2017 at 2:10 PM, Even Rouault wrote: > Thoughts ? > /me likes :-) -- Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito

[gdal-dev] gdaladdo without explicit factors specified

Hi, I'm pretty sure this must have annoyed a lot of people. When you run gdaladdo, you need to specify the appropriate overview levels. Generally you use power-of-two factors, but the question is then: what is the last relevant factor given the dimension of my file size ? I've a ready to co

[gdal-dev] gdaladdo pyramids with incorrect NULL values

Hi list We have an issue were the pyramids as created by gdaladdo is not correctly handling NULL values Create a 3 band tiff with proper null values (0 is null) - see https://www.dropbox.com/s/99rq1zflnuwah20/correctnulls.png?dl=0 gdalwarp -r cubic -s_srs epsg:32633 -srcnodata 0 -dstnodata

Re: [gdal-dev] gdaladdo -r max?

Christian, > I'm in need of "max" resampling in gdaladdo, to preserve the highest points > in elevation raster overviews. I've found that gdalwarp supports "-r max", > but gdaladdo doesn't. > > Can I achieve what I need (with prebuilt GDAL binaries)? (How?) You could do it possibly this way : g

[gdal-dev] gdaladdo -r max?

I'm in need of "max" resampling in gdaladdo, to preserve the highest points in elevation raster overviews. I've found that gdalwarp supports "-r max", but gdaladdo doesn't. Can I achieve what I need (with prebuilt GDAL binaries)? (How?) Will future versions of gdaladdo support "-r max"? (When?)

Re: [gdal-dev] gdaladdo problems with compression

Le lundi 14 septembre 2015 13:38:42, Stefan Ziegler a écrit : > Thanks Even. > > I was afraid that there will be no compression applied at all but this > behaviour is fine. > > The geotiff where I add the overviews is the result of a gdalwarp process > (tiled, deflate, preditor=2). When I gdal_tr

Re: [gdal-dev] gdaladdo problems with compression

Thanks Even. I was afraid that there will be no compression applied at all but this behaviour is fine. The geotiff where I add the overviews is the result of a gdalwarp process (tiled, deflate, preditor=2). When I gdal_translate this geotiff with the very same compression parameters I gain approx

Re: [gdal-dev] gdaladdo problems with compression

Le lundi 14 septembre 2015 11:46:45, Stefan Ziegler a écrit : > Hi > > we are facing problems with the compression of the overviews we are adding > with gdaladdo. The filesize does not differ whether we are using > compression parameters or not. The filesize of the input raster is approx. > 100 mb

[gdal-dev] gdaladdo problems with compression

Hi we are facing problems with the compression of the overviews we are adding with gdaladdo. The filesize does not differ whether we are using compression parameters or not. The filesize of the input raster is approx. 100 mb. The following both commands resulting in an identical filesize of approx

[gdal-dev] gdaladdo errors for overviews on vrt file

Hi all I'm trying to make overviews on a vrt file. Windows XP x32, dual opteron 4Gb RAM, Osgeo4W. This file is a virtual dataset, a mosaic of 993 tiff images 1bit b/w. gdalinfo for one of these tiff is: Driver: GTiff/GeoTIFF Files: 109021.tif

Re: [gdal-dev] gdaladdo very slow

Hello I must mosaic and compress many 1 bit images that should be used mainly by qgis users and ArcGIS users. After many attempts I have mosaicked them (983 images/998Mb) by this procedure 1) make a vrt mosaic gdalbuildvrt -hidenodata -srcnodata “0” -vrtnodata "0" test.vrt *.tif 2) make a geotiff

Re: [gdal-dev] gdaladdo don't seem to work..

Ok, I found the answer for the aux/rrd pyramid here http://lists.osgeo.org/pipermail/gdal-dev/2008-August/017850.html Now I'm trying Bie 2013/2/26 Pietro Rossin > Hello Jukka > thanks for your reply > The axe file I think isn't necessary. > If I delete it qgis can open and use pyramids... > I

Re: [gdal-dev] gdaladdo don't seem to work..

Hello Jukka thanks for your reply The axe file I think isn't necessary. If I delete it qgis can open and use pyramids... I got a good compromise between render and pyramid dimension with this command gdaladdo -r nearest --config COMPRESS_OVERVIEW deflate --config USE_RRD YES test.tif 4 16 32 64 I

Re: [gdal-dev] gdaladdo don't seem to work..

Pietro Rossin gmail.com> writes: > > > I was wrong, it was working slow.But at the end it leaves a big file with extension .axe. Is this necessary? > I know pyramids are inside the .aux file.. > Thank you > Pietro I guess that after exceeding some 2 GB or 4 GB limit the pyramids are actually i

Re: [gdal-dev] gdaladdo don't seem to work..

I was wrong, it was working slow. But at the end it leaves a big file with extension .axe. Is this necessary? I know pyramids are inside the .aux file.. Thank you Pietro 2013/2/25 Pietro Rossin > Hi all > I'll like to add overviews to a 1 bit geotiff > > the gdalinfo for this tiff is: > ***

[gdal-dev] gdaladdo don't seem to work..

Hi all I'll like to add overviews to a 1 bit geotiff the gdalinfo for this tiff is: *** Driver: GTiff/GeoTIFF Files: test.tif test.tfw test.aux Size is 292042, 284413 Coordinate System is `' Origin = (2311161.56486059590,5168752.55830754340

Re: [gdal-dev] gdaladdo bus errors for large, LZW-compressed GTiff

Le vendredi 05 octobre 2012 22:21:27, David Shean a écrit : > While the topic of gdaladdo resampling methods is active... > > I get bus errors when I use gdaladdo's gauss resampling method for large, > float32, LZW-compressed GTiff. This is repeatable. Repeatable on various large float32 LZW-com

[gdal-dev] gdaladdo bus errors for large, LZW-compressed GTiff

While the topic of gdaladdo resampling methods is active... I get bus errors when I use gdaladdo's gauss resampling method for large, float32, LZW-compressed GTiff. This is repeatable. Using a different gdaladdo resampling method (e.g., average) on the same LZW-compressed GTiff works. When I de

Re: [gdal-dev] Gdaladdo feels slow with Rasterlite

Even Rouault wrote: >> >> Feels pretty good but I have an odd problem with a multitable database. I >> can only create overviews for the table that was written first into the >> database. > Good point. There was indeed an issue with multitable database and overviews. > Fixed in http://trac.osgeo.

Re: [gdal-dev] Gdaladdo feels slow with Rasterlite

Le vendredi 06 juillet 2012 09:44:54, Rahkonen Jukka a écrit : > Even Rouault wrote: > >> One issue there is still. My original was a highly compressed (deflate) > >> tiff with a file size of 550 MB. Initial transform into Rasterlite with > >> png tiles yielded a 1.2 GB Rasterlite db. Condiderabl

Re: [gdal-dev] Gdaladdo feels slow with Rasterlite

Even Rouault wrote: >> One issue there is still. My original was a highly compressed (deflate) >> tiff with a file size of 550 MB. Initial transform into Rasterlite with >> png tiles yielded a 1.2 GB Rasterlite db. Condiderably bigger but still >> understandable. However, gdaladdo has no option

Re: [gdal-dev] Gdaladdo feels slow with Rasterlite

> One issue there is still. My original was a highly compressed (deflate) > tiff with a file size of 550 MB. Initial transform into Rasterlite with > png tiles yielded a 1.2 GB Rasterlite db. Condiderably bigger but still > understandable. However, gdaladdo has no option to compress internal >

Re: [gdal-dev] Gdaladdo feels slow with Rasterlite

Even Rouault wrote: > Le mercredi 04 juillet 2012 19:27:40, Jukka Rahkonen a écrit : >> Hi, >> >> I feel that gdaladdo is not working optimally with any bigger rasterlite >> tables. For example for my 153600x249600 pixel sized test image the >> initial write into rasterlite took 3 hours and 10 min

Re: [gdal-dev] Gdaladdo feels slow with Rasterlite

Le mercredi 04 juillet 2012 19:27:40, Jukka Rahkonen a écrit : > Hi, > > I feel that gdaladdo is not working optimally with any bigger rasterlite > tables. For example for my 153600x249600 pixel sized test image the > initial write into rasterlite took 3 hours and 10 minutes while adding > overvie

[gdal-dev] Gdaladdo feels slow with Rasterlite

Hi, I feel that gdaladdo is not working optimally with any bigger rasterlite tables. For example for my 153600x249600 pixel sized test image the initial write into rasterlite took 3 hours and 10 minutes while adding overviews with gdaladdo took 10 hours. Gdaladdo seems to use remarkable much time

Re: [gdal-dev] gdaladdo level values

On Thu, Apr 26, 2012 at 10:42 AM, Richard Nicoll wrote: > Hi guys > > I am new to using GDAL so apologies if this is a silly question! > > When using the gdaladdo to create GeoTIFF pyramid layers (overviews), > can the levels values be decimal values, or do they have to be > integers?  I have trie

[gdal-dev] gdaladdo level values

Hi guys I am new to using GDAL so apologies if this is a silly question! When using the gdaladdo to create GeoTIFF pyramid layers (overviews), can the levels values be decimal values, or do they have to be integers? I have tried using decimals (e.g. 4.3) since this will produce an overview at th

Re: [gdal-dev] Gdaladdo spoils rasterlite with multible raster tables

Le jeudi 15 mars 2012 15:26:08, Jukka Rahkonen a écrit : > Hi, > > I made some further tests with GDAL 1.9.0, gdal_translate and > gdaladdo and I start to be pretty sure that gdaladdo is poisoning > the rasterlite databases which contain several raster tables. > I can put the original sample image

[gdal-dev] Gdaladdo spoils rasterlite with multible raster tables

Hi, I made some further tests with GDAL 1.9.0, gdal_translate and gdaladdo and I start to be pretty sure that gdaladdo is poisoning the rasterlite databases which contain several raster tables. I can put the original sample images somewhere for download if requested. QGis shows all the rasters

Re: [gdal-dev] gdaladdo, overviews and NODATA

On 21/02/2012 22:36, Frank Warmerdam wrote: On Tue, Feb 21, 2012 at 1:17 PM, Armin Burger wrote: Then I tried to set the NODATA value to 0 using Gdal-Python, and afterwards they had Band 1 Block=3000x1 Type=Byte, ColorInterp=Red NoData Value=0 Band 2 Block=3000x1 Type=Byte, ColorInterp=Gre

Re: [gdal-dev] gdaladdo, overviews and NODATA

Hi Armin, you can work around with removing the nodata value first, build the overviews and setting the nodata value again with gdal_edit.py. The script can be found in source directory gdal/swig/python/samples. Gr Ralf On Dienstag 21 Februar 2012 21:36:19 Armin Burger wrote: > Hi all > > I

Re: [gdal-dev] gdaladdo, overviews and NODATA

On Tue, Feb 21, 2012 at 1:17 PM, Armin Burger wrote: > Then I tried to set the NODATA value to 0 using Gdal-Python, and afterwards > they had > > Band 1 Block=3000x1 Type=Byte, ColorInterp=Red >  NoData Value=0 > Band 2 Block=3000x1 Type=Byte, ColorInterp=Green >  NoData Value=0 > Band 3 Block=300

Re: [gdal-dev] gdaladdo, overviews and NODATA

Frank the original images showed ... Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL ... Band 1 Block=3000x1 Type=Byte, ColorInterp=Red Band 2 Block=3000x1 Type=Byte, ColorInterp=Green Band 3 Block=3000x1 Type=Byte, ColorInterp=Blue Then I tried to set the NODATA valu

Re: [gdal-dev] gdaladdo, overviews and NODATA

Armin, Reviewing the overview building code in gdal/gcore/overview.cpp it clearly tries to exclude nodata values from the averaging calculation. What does the gdalinfo report look like for the file before you run gdaladdo? Best regards, On Tue, Feb 21, 2012 at 12:36 PM, Armin Burger wrote: > Hi

[gdal-dev] gdaladdo, overviews and NODATA

Hi all I have a question regarding the gdaladdo tool and NODATA pixels: When using resampling like "average" it seems that along the border of DATA and NODATA pixels there happens an averaging also of some of the original NODATA pixels (looks like 1-2 pixel width). This way in the overviews t

Re: [gdal-dev] gdaladdo creates very large files in 1.8 but not trunk

>> I'm not aware of any recent change in the GTiff driver that could have >> "solved" >> the issue you've seen. This is a bit surprising. >> >> Could you also try with the -stable builds (based on 1.8 branch) from >> http://vbkto.dyndns.org/sdk/ to compare ? > > I am trying it with, > http:/

Re: [gdal-dev] gdaladdo creates very large files in 1.8 but not trunk

> I'm not aware of any recent change in the GTiff driver that could have > "solved" > the issue you've seen. This is a bit surprising. > > Could you also try with the -stable builds (based on 1.8 branch) from > http://vbkto.dyndns.org/sdk/ to compare ? I am trying it with, http://vbkto.dyndns

Re: [gdal-dev] gdaladdo creates very large files in 1.8 but not trunk

Le jeudi 14 avril 2011 17:02:36, Eli Adam a écrit : I'm not aware of any recent change in the GTiff driver that could have "solved" the issue you've seen. This is a bit surprising. Could you also try with the -stable builds (based on 1.8 branch) from http://vbkto.dyndns.org/sdk/ to compare ? >

[gdal-dev] gdaladdo creates very large files in 1.8 but not trunk

This is an informational report only, there are not problems in trunk. Using 1.8.0 from OSGeo4W on XP, I made a mosaic of about 1200 uncompressed tifs totally 80G. gdalbuildvrt mosaic.vrt *.tif Then gdal_translated that to a compressed tif of about 8G gdal_translate mosaic.vrt mosaic_ycbcr

Re: [gdal-dev] gdaladdo and cubic resampling

Armin, GDAL's resampling algorithms for overviews are a bit restricted. Your best bet is to smoothen the image with an image processing software. On Thu, Aug 5, 2010 at 11:00 PM, Armin Burger wrote: > Chaitanya > > I send the image just to you since it's not small any more. This is a > mosaic o

[gdal-dev] gdaladdo and cubic resampling

Hi all I have a question regarding the resampling modes for the gdaladdo utility. Since the overviews are used by Mapserver afterwards, I ran some tests with a map file referencing the Tiff image and the shp2img tool to output the results. I found the gauss resampling smoothening the image a b

Re: [Gdal-dev] gdaladdo for large RPF

Charles, sorry for the late answer. Given the dimension of the RPF dataset, 366028x 466944, the overview file should be around 57 GB ( the total size of the overviews of factor 1/2, 1/4, 1/8, 1/2^n is the size of the full resolution dataset divided by 3), which cannot fit into a tradition

Re: [Gdal-dev] gdaladdo for large RPF

Does anyone know about how to work with large RPF? Any help is appreciated. Thanks. Charles Chung wrote: > > When I try to build an overview of a.toc file that is associated with 10 > GB (38K files) NITF files, I get the following error message. > > c:\>gdaladdo --config COMPRESS_OVERVIEW DEF

[Gdal-dev] gdaladdo for large RPF

When I try to build an overview of a.toc file that is associated with 10 GB (38K files) NITF files, I get the following error message. c:\>gdaladdo --config COMPRESS_OVERVIEW DEFLATE NITF_TOC_ENTRY:CIB__1M_1_0:C:\aOI\rpf\a.toc 2 4 8 16 ERROR 1: TIFFFetchStripThing:Sanity check on size of "TileOff

RE: [gdal-dev] gdaladdo

: Dillabough, Craig Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] gdaladdo Just for curiosity, could you precise the version of external libtiff on your system and the dimensions of your TIFF image ? Le Friday 19 June 2009 18:05:30 Dillabough, Craig, vous avez écrit : > Hi Even, > > My

Re: [gdal-dev] gdaladdo

gt; From: Even Rouault [mailto:even.roua...@mines-paris.org] > Sent: Thursday, June 18, 2009 4:33 PM > To: Dillabough, Craig > Cc: gdal-dev@lists.osgeo.org > Subject: Re: [gdal-dev] gdaladdo > > > Look at TIFF_SETTING in GDALmake.opt. > > Le Thursday 18 June 2009 22:31:

RE: [gdal-dev] gdaladdo

Craig -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: Thursday, June 18, 2009 4:33 PM To: Dillabough, Craig Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] gdaladdo Look at TIFF_SETTING in GDALmake.opt. Le Thursday 18 June 2009 22:31:12 Dillabough, Craig,

Re: [gdal-dev] gdaladdo

e 18, 2009 4:18 PM > To: gdal-dev@lists.osgeo.org > Cc: Dillabough, Craig > Subject: Re: [gdal-dev] gdaladdo > > > Craig, > > This should work. > > Are you using an older GDAL version ? Are you using external libtiff ? > > If so, try again with newer GDAL and internal

Re: [gdal-dev] gdaladdo

Craig, This should work. Are you using an older GDAL version ? Are you using external libtiff ? If so, try again with newer GDAL and internal libtiff (although I wouldn't older GDAL to fail on a simple case like yours that doesn't involve TIFF compression) Le Thursday 18 June 2009 21:50:25 Di

[gdal-dev] gdaladdo

Hi, I am trying to tile and create overviews for a TIFF image dataset I have, but I keep getting strange errors when attempting to add overviews. 1st I created a copy of the original image (same format and all, but wanted to keep the original around in case I had problems). >gdal_translate -ot F

[gdal-dev] gdaladdo and huge files

Hello, gdaladdo is having issues with an ENVI file that is 45 GBytes big. I run the command: gdaladdo bigfile 2 4 8 16 32 64 128 256 512 1024 The following error message is produced: ERROR 1: TIFFAppendToStrip:Maximum TIFF file size exceeded Is gdaladdo supposed to work with files this big? BIG