sounds good, +1
thanks,
TB
Le lun. 6 janv. 2025, 18:44, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> a écrit :
> Hi,
>
> Given that communication with Adobe in recent years has been similar to
> expecting to receive a signal from a black hole from outside its event
> horizon, up to now
Hi Jukka,
Yes, you should definitely be using tiled tiff with jxl. The actual tile
size (256,512 or 1024) did not seem to make much difference in file size
from what I have experienced, so you can choose that value depending on how
you plan to use the tifs later on.
In production use here, we use "
I also see that you have a tiledb driver registration happening only on
your conda version, exactly at the time of your lag. you should also try to
remove/rename your gdal_tiledb.so plugin file to check the issue isn't
coming from there.
Le ven. 13 sept. 2024, 18:22, thomas bonfort a
écrit :
> J
Javier,
3.9 is probably doing parallel reads, which will cause a noticeable lag in
requests on a slow connection (the overall processing time should not be
slower anyhow). There's a gtiff open option documented that can disable
this behavior, that you can try to use to see if it changes your timing
I'm not sure that providing a fix to work around this very broken behavior
is the best way of action to make them fix their server...
On Tue, Sep 10, 2024 at 5:07 PM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
>
> Le 10/09/2024 à 16:10, Rahkonen Jukka via gdal-dev a écrit :
>
> H
For COG format, you should use -co RESAMPLING=mode. gdalwarp's -r switch
only applies to the full resolution warper resampling, not the overviews.
TB
Le mer. 21 août 2024, 18:09, Justin Terry via gdal-dev <
gdal-dev@lists.osgeo.org> a écrit :
> Hi,
>
>
>
> I'm experiencing a strange issue I've ne
Merci Even,
I can confirm that the workaround you suggested works correctly.
>From the performance I was getting beforehand, I strongly believe that the
mixup happening on the overview levels was causing my hat/lr dataset to
never be used at all.
Thank you for the quick response,
Thomas
On Mon, Ju
Hi list,
I'm experimenting with the GTI driver and hitting an issue when trying to
add overviews.
I'm compiling a large number of adjacent non-overlapping tiles, each of
which has is own bundled overviews:
gdalinfo /*snip*/tile-1377-471.tif
Size is 32768, 32768
Origin = (3.057607090103000,48.4207
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 E
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 i
> 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
htt
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 b
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 enha
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
VSISi
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 b
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 conve
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 followi
17 matches
Mail list logo
