Re: [gdal-dev] Compression Artifacts After Merging Imagery

2017-09-28 Thread Even Rouault
> On a different topic altogether, how would I go about contributing to > the doxygen-created documentation? In playing around with gdal_rasterize > I discovered that it's not clear in the current docs what options > trigger creation of a new raster instead of overwriting an existing > raster. My C

Re: [gdal-dev] Compression Artifacts After Merging Imagery

2017-09-28 Thread Jacob Adams
Evan, Thanks for your help. Adjusting the nearblack parameters and using -setalpha instead of -setmask got the mask working as expected. I'd normally agree with you on mid-process compression, and if I were using the data for any kind of analysis I would do as little compression as possible. How

Re: [gdal-dev] Compression Artifacts After Merging Imagery

2017-09-25 Thread Even Rouault
On lundi 25 septembre 2017 16:16:26 CEST Jacob Adams wrote: > Oh ye great minds of the GDAL world, I've run into a problem that I've not > been able to solve. > > I have aerial imagery comprised of about 1500 jpegs that I am trying to > merge together into three large (~18gb) jpeg-compressed geoti

[gdal-dev] Compression Artifacts After Merging Imagery

2017-09-25 Thread Jacob Adams
Oh ye great minds of the GDAL world, I've run into a problem that I've not been able to solve. I have aerial imagery comprised of about 1500 jpegs that I am trying to merge together into three large (~18gb) jpeg-compressed geotiffs to be served by Geoserver. The images are tiled such that they

Re: [gdal-dev] Compression artifacts

2012-12-27 Thread Jan Hartmann
Thanks Trent, I tried it out: original: 3.886.894.126b compressed DEFLATE:266.046.034b compressed LZW: 372.085.756b compressed JPEG: 90.055.344b Although DEFLATE and LZW give very good results, JPEG compression is so much better that I need t

Re: [gdal-dev] Compression artifacts

2012-12-27 Thread Hare, Trent
Jan, Jpeg is a lossy compression and thus the collar will not be maintained perfectly as black (or 0). You will not get as much compression, but you can try a lossless method like LZW or Packbits. If you are getting close to the 4GB limit you might need to add "-co bigtiff=if_safer". Good luck,

Re: [gdal-dev] Compression artifacts

2012-12-27 Thread Even Rouault
Le jeudi 27 décembre 2012 15:35:25, Jan Hartmann a écrit : > On 12/27/2012 03:11 PM, Even Rouault wrote: > > Le jeudi 27 décembre 2012 15:11:23, Jan Hartmann a écrit : > >> On 12/27/2012 02:41 PM, Even Rouault wrote: > >>> I've just pushed a fix since building overviews with "--config > >>> COMPRES

Re: [gdal-dev] Compression artifacts

2012-12-27 Thread Jan Hartmann
On 12/27/2012 03:11 PM, Even Rouault wrote: Le jeudi 27 décembre 2012 15:11:23, Jan Hartmann a écrit : On 12/27/2012 02:41 PM, Even Rouault wrote: I've just pushed a fix since building overviews with "--config COMPRESS_OVERVIEW JPEG -- config PHOTOMETRIC_OVERVIEW YCBCR" when there's a .msk did

Re: [gdal-dev] Compression artifacts

2012-12-27 Thread Even Rouault
Le jeudi 27 décembre 2012 15:11:23, Jan Hartmann a écrit : > On 12/27/2012 02:41 PM, Even Rouault wrote: > > I've just pushed a fix since building overviews with "--config > > COMPRESS_OVERVIEW JPEG -- config PHOTOMETRIC_OVERVIEW > > YCBCR" when there's a .msk didn't work. > > > >> OK Even, thanks

Re: [gdal-dev] Compression artifacts

2012-12-27 Thread Jan Hartmann
On 12/27/2012 02:41 PM, Even Rouault wrote: I've just pushed a fix since building overviews with "--config COMPRESS_OVERVIEW JPEG -- config PHOTOMETRIC_OVERVIEW YCBCR" when there's a .msk didn't work. OK Even, thanks. This means that I should use gdal-svn? Not necessarily. I think you can wo

Re: [gdal-dev] Compression artifacts

2012-12-27 Thread Even Rouault
Le jeudi 27 décembre 2012 14:37:49, Jan Hartmann a écrit : > On 12/27/2012 02:27 PM, Even Rouault wrote: > > The artifacts are due to the lossy characteristics of JPEG compression > > that are particularly visible on borders between nodata pixel and valid > > pixels. An option would be to use nearb

Re: [gdal-dev] Compression artifacts

2012-12-27 Thread Jan Hartmann
On 12/27/2012 02:27 PM, Even Rouault wrote: The artifacts are due to the lossy characteristics of JPEG compression that are particularly visible on borders between nodata pixel and valid pixels. An option would be to use nearblack to create a .msk mask file : nearblack -setmask -o big_with_mask

Re: [gdal-dev] Compression artifacts

2012-12-27 Thread Even Rouault
Le jeudi 27 décembre 2012 13:38:50, Jan Hartmann a écrit : > Can anyone tell me wath is happening here? I have a large three-band > raster (3.8G) looking like this: > > http://mapserver.sara.nl/map2a.png > > I compress it (from information from this list a few days ago) with: > > gdal_translate

Re: [gdal-dev] Compression artifacts

2012-12-27 Thread Jan Hartmann
That would be an option. Am I right that the datasource of the -cutline option is a closed polygon, and that everything outside the polygon will be clipped? However, I would prefer not to add extra steps. These are large maps and there are lots of them (about 17.000 for the whole of the Nether

Re: [gdal-dev] Compression artifacts

2012-12-27 Thread Dmitry Baryshnikov
Hi Jan, You can cut result raster with the geometry (shape file) using gdalwarp with cutline option (http://gdal.org/gdalwarp.html). Best regards, Dmitry 27.12.2012 16:38, Jan Hartmann ?: Can anyone tell me wath is happening here? I have a large three-band raster (3.8G) looking like

[gdal-dev] Compression artifacts

2012-12-27 Thread Jan Hartmann
Can anyone tell me wath is happening here? I have a large three-band raster (3.8G) looking like this: http://mapserver.sara.nl/map2a.png I compress it (from information from this list a few days ago) with: gdal_translate -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR big.tif small.tif gdaladdo --conf