Hi Even,
On Tue, 23 Jan 2024 at 14:59, Even Rouault
wrote:
> Perhaps due to a difference in the overview resampling method. The COG
> driver uses cubic by default. Perhaps try adding -co RESAMPLING=AVERAGE to
> compare compareable things.
>
using -co RESAMPLING=AVERAGE the total time is 30
-
Lähettäjä: gdal-dev Puolesta andy via
gdal-dev
Lähetetty: tiistai 23. tammikuuta 2024 15.45
Vastaanottaja: Even Rouault
Kopio: gdal dev
Aihe: Re: [gdal-dev] Non able to manage properly vitual file, warping and black
edges
Even,
the verbose process lasts 24 minutes, the COG process lasts 36
Perhaps due to a difference in the overview resampling method. The COG
driver uses cubic by default. Perhaps try adding -co RESAMPLING=AVERAGE
to compare compareable things.
Le 23/01/2024 à 14:45, andy a écrit :
Even,
the verbose process lasts 24 minutes, the COG process lasts 36 minutes.
Even,
the verbose process lasts 24 minutes, the COG process lasts 36 minutes.
There is a 50% difference.
Best regards
--
___
Andrea Borruso
website: https://medium.com/tantotanto
38° 7' 48" N, 13° 21' 9" E, EPSG:4326
___
"cercare e saper riconoscere chi e
Hi Even,
because it creates the overviews. You can disable creating them with -co
> OVERVIEWS=NO
>
Sorry, but I didn't write down my whole procedure.
After gdal_translate, I run
gdaladdo --config GDAL_NUM_THREADS ALL_CPUS --config BIGTIFF_OVERVIEW YES
--config INTERLEAVE_OVERVIEW PIXEL -r
Le 23/01/2024 à 13:38, andy a écrit :
Hi Even,
the COG is a much simpler command, it keeps everything in a little
bit, but it is much slower than the more verbose procedure I wrote.
So I ruled it out.
because it creates the overviews. You can disable creating them with -co
OVERVIEWS=NO
Hi Even,
the COG is a much simpler command, it keeps everything in a little bit, but
it is much slower than the more verbose procedure I wrote.
So I ruled it out.
Thank you very much for the information you gave me, valuable
--
___
Andrea Borruso
website:
But I need another piece of advice.
Using alpha transparency, with the 4 bands, I cannot use
PHOTOMETRIC=YCBCR, and I used PHOTOMETRIC=RGB.
This way the compression is a little less effective.
Is there anything comparable, in terms of compression effectiveness,
when using alpha
Hi Even
first of all, thank you very much.
I was tired yesterday. I realize this, because this morning I created a new
script starting from scratch and everything seems to be working.
Yesterday I was probably looking at the wrong output folder (I am stupid as
well as tired).
It this way it works:
Hi,
Could you add a small image to show how the result looks like? I fear my
imagination may be inaccurate.
-Jukka Rahkonen-
Lähettäjä: gdal-dev Puolesta andy via
gdal-dev
Lähetetty: maanantai 22. tammikuuta 2024 18.54
Vastaanottaja: gdal dev
Aihe: [gdal-dev] Non able to manage properly
ah I missed your sources were JPEG compressed. Do they have padding
around them? If so, you might need to use nearblack to compute a mask band
Le 22/01/2024 à 18:09, andy a écrit :
Hi Even,
and thank you, I have the same result.
Do I must remove jpeg compression in gdaladdo?
Best regards
Hi Even,
and thank you, I have the same result.
Do I must remove jpeg compression in gdaladdo?
Best regards
--
___
Andrea Borruso
website: https://medium.com/tantotanto
38° 7' 48" N, 13° 21' 9" E, EPSG:4326
___
"cercare e saper riconoscere chi e cosa,
in
Le 22/01/2024 à 17:53, andy via gdal-dev a écrit :
Hi,
I have four tif input files, these have 3 bands RGB and are JPEG
compressed.
No null data set.
My goal is to mosaic these and then warp the mosaic.
I start it with:
gdalbuildvrt mosaic.vrt file1.tif file2.tif file3.tif file4.tif
Try
Hi,
I have four tif input files, these have 3 bands RGB and are JPEG compressed.
No null data set.
My goal is to mosaic these and then warp the mosaic.
I start it with:
gdalbuildvrt mosaic.vrt file1.tif file2.tif file3.tif file4.tif
Then I warp the mosaic:
gdalwarp -dstalpha -of vrt
14 matches
Mail list logo
