could you share the output of "gdalinfo in.tif" please?
On Fri, Feb 9, 2024 at 3:32 PM Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS
AND APPLICATIONS INC] via gdal-dev wrote:
> We are trying to convert a 2 band int16 ZSTD compressed geotiff to JXL
> compression. However for each band the
JXL in tiff should support the 2 band case correctly. What is not supported
here is the int16 datatype. Only uint8, uint16 and float32 are supported.
TB
On Fri, Feb 9, 2024 at 3:32 PM Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS
AND APPLICATIONS INC] via gdal-dev wrote:
> We are trying to
doc update PR in https://github.com/OSGeo/gdal/pull/9220
On Fri, Feb 9, 2024 at 3:38 PM Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS
AND APPLICATIONS INC] wrote:
> We can work with the Uint16 case. These dtype limitations should be
> listed on the gtiff docs presumably.
>
>
>
> *From: *thomas
Hi Sean,
I believe/recall this is very driver dependent. Some drivers will look for
their sidecars in the provided sibling files list returned by
VSISiblingFiles, whereas others will unconditionally try to open well-known
sidecar names they will have computed from their own name. IIRC I added
Hi Even,
my number 1 requirement would be that the rewrite not cause any backwards
compatibility issues compared to today's argument handling. I suspect many
users are calling the gdal utilities through scripts and it would be a pain
to have to update those when upgrading gdal.
a nice to have
Le ven. 8 mars 2024, 17:42, Even Rouault a
écrit :
> Thomas,
> >
> > my number 1 requirement would be that the rewrite not cause any
> > backwards compatibility issues compared to today's argument handling.
> > I suspect many users are calling the gdal utilities through scripts
> > and it would
> I don't like that the behaviour of a command line depends on the
> configuration of the user (that is usually not aware of). So a command that
> works for me doesn't work for you. That is bad.
>
+1
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
I have a side-question concerning the update-in-place behavior of the gtiff
driver in this case: given that a compressed strile will nearly always be
smaller after this update (due to better compression ratios on the uniform
area), will libtiff overwrite the previous strile in place also, or will
All OK with https://github.com/airbusgeo/godal 's test suite, with changes
that did have to be made to account for the default gtiff mask band
handling (I believe this change should have been kept back until 4.0. I am
not asking for it to be reverted)
regards,
TB
On Mon, Apr 22, 2024 at 2:12 PM
