Re: [gdal-dev] lossless jpeg crop in gdal?

Matt, Le 16/03/2021 à 21:45, matt.wil...@yukon.ca a écrit : I recently learned that *jpegtran* from the JPEG library has the ability to crop and save a new jpeg losslessly:  [...] Can GDAL take advantage of this for jpeg-in-geotiff images? to some limited extent, yes. I thought this was do

[gdal-dev] lossless jpeg crop in gdal?

I recently learned that jpegtran from the JPEG library has the ability to crop and save a new jpeg losslessly: These transformations are each completely lossless and reversible. The transformations on the image data comprise: · eliminate non-standard application-specific data inserted by

Re: [gdal-dev] nearblack on multi GB images very slow

mhw-at-yg wrote > I have a lot of multi GB images that are unfortunately jpeg-in-geotiff > encoded before nodata was properly defined. As a result they all suffer > from > the jagged edges problem. > ; > > I've defined a method for addin

Re: [gdal-dev] ZSTD compression level 17 smaller than 18+?

Am 15.03.2021 um 05:04 schrieb matt.wil...@yukon.ca: >> Here's my results: I'm also using zstd for lots of stuff. It's really performing very well. But it often behaves totally unpredictably. For example, I get a better compression ratio with SQL files in level 1 than with level 3. And level

Re: [gdal-dev] gdal_retile: output isn't georeferenced?

> Is the "main" or "image" file geo-referenced ? > It may be that the .tif.msk mask files are assumed to be the same as the > matching .tif file. Ahh yes that's it. The tile main image is georeferenced and it's just the mask on it's own which is not. Thanks for pointing that out. -Matt ___

Re: [gdal-dev] ZSTD compression level 17 smaller than 18+?

Oh that’s so weird. Well that puts my take-away as: just use Level=17 and forget the rest exist! -Matt From: Daniel Evans Sent: March 15, 2021 2:36 AM To: Matt.Wilkie ; gdal-dev@lists.osgeo.org Subject: RE: ZSTD compression level 17 smaller than 18+? *** External email: Do not click on links

Re: [gdal-dev] libgdal depends on two libprojs, what's going on?

Le 16/03/2021 à 15:53, Ari Jolma a écrit : Even Rouault kirjoitti 16.3.2021 klo 16.49: Ari, Maybe it's because libgdal seems to use two libprojs: ldd /usr/lib/libgdal.so.28.0.1 | grep libproj     libproj.so.19 => /usr/lib/x86_64-linux-gnu/libproj.so.19 (0x7f70d3343000)     libproj.so.15

Re: [gdal-dev] libgdal depends on two libprojs, what's going on?

Ari Jolma kirjoitti 16.3.2021 klo 16.53: Even Rouault kirjoitti 16.3.2021 klo 16.49: Ari, Maybe it's because libgdal seems to use two libprojs: ldd /usr/lib/libgdal.so.28.0.1 | grep libproj     libproj.so.19 => /usr/lib/x86_64-linux-gnu/libproj.so.19 (0x7f70d3343000)     libproj.so.15 =>

Re: [gdal-dev] libgdal depends on two libprojs, what's going on?

Even Rouault kirjoitti 16.3.2021 klo 16.49: Ari, Maybe it's because libgdal seems to use two libprojs: ldd /usr/lib/libgdal.so.28.0.1 | grep libproj     libproj.so.19 => /usr/lib/x86_64-linux-gnu/libproj.so.19 (0x7f70d3343000)     libproj.so.15 => /usr/lib/x86_64-linux-gnu/libproj.so.15 (

Re: [gdal-dev] libgdal depends on two libprojs, what's going on?

Ari, Maybe it's because libgdal seems to use two libprojs: ldd /usr/lib/libgdal.so.28.0.1 | grep libproj     libproj.so.19 => /usr/lib/x86_64-linux-gnu/libproj.so.19 (0x7f70d3343000)     libproj.so.15 => /usr/lib/x86_64-linux-gnu/libproj.so.15 (0x7f70cef6f000) Is there anything I can

[gdal-dev] libgdal depends on two libprojs, what's going on?

I needed later libgdal so I added ubuntugi-unstable and installed libgdal-dev. Now I have both libgdal26 and libgdal28. But I assume something is wrong because I get from trying to use the libgdal28 (gdb) bt #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1  0x7ff

[gdal-dev] Motion: RFC 78: gdal-utils package

Hi all, Having heard no further comments regarding RFC78 . Motion: Adopt RFC 78: gdal-utils package (formatted version). *A pers