Re: [gdal-dev] Convert alpha to nodata?

[Even Rouault via gdal-dev]

Rob,

https://github.com/OSGeo/gdal/pull/9128 should do what you wish. As 
usual, the hardest part is the naming of options...


Even

Le 19/01/2024 à 18:32, Even Rouault via gdal-dev a écrit :

Hi Rob,

I can't think an easy way of doing what you want.

Well, you can definitely do that using a VRT Python pixel function, 
that would essentially do your --calc expression


Cf 
https://gdal.org/drivers/raster/vrt.html#using-derived-bands-with-pixel-functions-in-python


The example of 
https://gdal.org/drivers/raster/vrt.html#vrt-that-adds-2-or-more-rasters 
is probably the closest starting point. (you can add  to 
the 's to specify bands 1 and 4)


A nice exercice for (Pythonist) contributors would be to add a -f VRT 
capability to gdal_calc.py that would essentially automate the writing 
of such VRT using Python pixel functions. Just saying...


Even

Le 19/01/2024 à 17:40, Robert Coup via gdal-dev a écrit :

Maybe it's just Friday, but I could use a pointer here :-)

My input raster is a RGBA byte image, where the alpha channel value 
is 0 or 255 (ie: effectively a mask). The output is ideally a VRT 
file, RGB with Int16 data type, using nodata=-1.


So I want to convert the alpha channel to a nodata value.

The alpha/nodata/mask/band options to translate/warp haven't got me 
very far, neither has hand-crafting various UseMaskBand/MaskBand 
elements in a VRT.


I can do it to concrete tif files with something like this, 
repeating for R,G,B and merge the output bands together, but it's a 
lot of processing.


  gdal_calc.py -A src.tif -B src.tif \
    --outfile out_b1.tif --co TILED=YES --type=Int16 --NoDataValue=-1 \
    --A_band=1 --B_band=4 --calc="where(B >= 128, A, -1)"

I feel like I'm probably missing a simpler path? (Which I will 
definitely add to an Examples section somewhere)


Thanks,

Rob :)

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev



--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] units=km not working

[Rahkonen Jukka via gdal-dev]

Hi,

Because the units mean the units of the projected coordinates. An example:
https://epsg.io/map#srs=3067-1149=295545.168414=6836388.322477=4=streets
Here x and y are in meters: "+proj=utm +zone=35 +ellps=GRS80 
+towgs84=0,0,0,0,0,0,0 +units=m +no_defs +type=crs".

By changing the the units into kilometers the x value would change into 
295.545168414 any y into 6836.388322477 but that does not change the size of 
the Earth.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Wilco K via 
gdal-dev
Lähetetty: tiistai 23. tammikuuta 2024 21.57
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] units=km not working

Hi,

why is units=km not working?

gdaltransform -s_srs EPSG:4326 -t_srs "+proj=stere +lat_0=90 +lon_0=0 
+lat_ts=60 +a=6378.14 +b=6356.75 +x_0=0 +y_0=0 +units=km"

The following error is returned:
ERROR 1: PROJ: proj_create_operations: Source and target ellipsoid do not 
belong to the same celestial body

Converting +a and +b to meters and it does works:
gdaltransform -s_srs EPSG:4326 -t_srs "+proj=stere +lat_0=90 +lon_0=0 
+lat_ts=60 +a=6378140 +b=6356750 +x_0=0 +y_0=0"

Any ideas?

Wilco



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] units=km not working

[Even Rouault via gdal-dev]

Le 23/01/2024 à 20:56, Wilco K via gdal-dev a écrit :

Hi,

why is *units=km* not working?
*
*
*gdaltransform -s_srs EPSG:4326 -t_srs "+proj=stere +lat_0=90 +lon_0=0 
+lat_ts=60 +a=6378.14 +b=6356.75 +x_0=0 +y_0=0 **+units=km" *


The following error is returned:
ERROR 1: PROJ: proj_create_operations: Source and target ellipsoid do 
not belong to the same celestial body



Converting +a and +b to meters and it does works:
*gdaltransform -s_srs EPSG:4326 -t_srs "+proj=stere +lat_0=90 +lon_0=0 
+lat_ts=60 +a=6378140 +b=6356750 +x_0=0 +y_0=0"*



Any ideas?


Cf https://proj.org/en/9.3/usage/projections.html#units : "Horizontal 
coordinate system units can be specified using the |+units| keyword 
[...] Note that this does /not/ affect the units of linear parameters 
such as |+x_0| or |+y_0| which should always be specified in meters." .  
This also applies to the +a and +b parameters. Doc enhancement filed in 
https://github.com/OSGeo/PROJ/pull/4010



When you specify +units=km, it just means that you wish the output 
projected coordinates are expressed in km. But this doesn't affect the 
units of any linear parameters of the projection definition.


Even

--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] units=km not working

[Wilco K via gdal-dev]

Hi,

why is units=km not working?

gdaltransform -s_srs EPSG:4326 -t_srs "+proj=stere +lat_0=90 +lon_0=0 
+lat_ts=60 +a=6378.14 +b=6356.75 +x_0=0 +y_0=0 +units=km"

The following error is returned:
ERROR 1: PROJ: proj_create_operations: Source and target ellipsoid do not 
belong to the same celestial body


Converting +a and +b to meters and it does works:
gdaltransform -s_srs EPSG:4326 -t_srs "+proj=stere +lat_0=90 +lon_0=0 
+lat_ts=60 +a=6378140 +b=6356750 +x_0=0 +y_0=0"


Any ideas?

Wilco



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Layerstack multiple images, of different extents and variable number of bands

[Rahkonen Jukka via gdal-dev]

Hi,

I recommend to study gdalbuildvrt https://gdal.org/programs/gdalbuildvrt.html 
and consider if it might be good for you with the -separate option.

-Jukka Rahkonen-

Lähettäjä: lef...@gmail.com 
Lähetetty: tiistai 23. tammikuuta 2024 21.51
Vastaanottaja: Rahkonen Jukka 
Kopio: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] Layerstack multiple images, of different extents and 
variable number of bands

You've interpreted that correctly.

On Tue, Jan 23, 2024 at 12:13 PM Rahkonen Jukka 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 wrote:
Hi,

Please clarify what is the desired result.  A multiband image that covers the 
union of extents of all the input images, with a number of bands that is the 
sum of bands in all the inputs or what?

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta lefsky--- via gdal-dev
Lähetetty: tiistai 23. tammikuuta 2024 19.01
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Layerstack multiple images, of different extents and variable 
number of bands

I've been incorporating gdal into my processing pipelines and have a question 
about a feature.

I need to be able to layer stack multiple images with different extents and 
varying numbers of bands, usually exceeding 1. I haven't been able to find a 
single command to do this in gdal. Am I missing something? If there is no such 
feature, has anyone developed a script out there that can robustly do all of 
those things (i.e. with checking for violation of assumptions about files and 
error handling)?

Michael

--
Michael Lefsky (He/His)
Home Location: HVHF+GH
Cell: 970-980-9036
http://www.researcherid.com/rid/A-7224-2009

“for being prematurely, and worse, intuitively right — there’s a heavy price. 
But for being wrong — no, not so long as you’re wrong in a pack." Gary Brecher 
/ Portis

*I acknowledge that I live and work on stolen land. This is the land of the 
Cheyenne, Arapaho, Ute, and Ocheithi Sakowin people. To learn more about these 
nations, please visit;
http://www.utemountainutetribe.com/
http://www.cheyennenation.com/
https://cheyenneandarapaho-nsn.gov/
https://native-land.ca/



--
Michael Lefsky (He/His)
Home Location: HVHF+GH
Cell: 970-980-9036
http://www.researcherid.com/rid/A-7224-2009

“for being prematurely, and worse, intuitively right — there’s a heavy price. 
But for being wrong — no, not so long as you’re wrong in a pack." Gary Brecher 
/ Portis

*I acknowledge that I live and work on stolen land. This is the land of the 
Cheyenne, Arapaho, Ute, and Ocheithi Sakowin people. To learn more about these 
nations, please visit;
http://www.utemountainutetribe.com/
http://www.cheyennenation.com/
https://cheyenneandarapaho-nsn.gov/
https://native-land.ca/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Layerstack multiple images, of different extents and variable number of bands

[lefsky--- via gdal-dev]

You've interpreted that correctly.

On Tue, Jan 23, 2024 at 12:13 PM Rahkonen Jukka <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> Please clarify what is the desired result.  A multiband image that covers
> the union of extents of all the input images, with a number of bands that
> is the sum of bands in all the inputs or what?
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gdal-dev  *Puolesta *lefsky---
> via gdal-dev
> *Lähetetty:* tiistai 23. tammikuuta 2024 19.01
> *Vastaanottaja:* gdal-dev@lists.osgeo.org
> *Aihe:* [gdal-dev] Layerstack multiple images, of different extents and
> variable number of bands
>
>
>
> I've been incorporating gdal into my processing pipelines and have a
> question about a feature.
>
>
>
> I need to be able to layer stack multiple images with different extents
> and varying numbers of bands, usually exceeding 1. I haven't been able to
> find a single command to do this in gdal. Am I missing something? If there
> is no such feature, has anyone developed a script out there that can
> robustly do all of those things (i.e. with checking for violation of
> assumptions about files and error handling)?
>
>
>
> Michael
>
>
>
> --
>
> Michael Lefsky (He/His)
>
> Home Location: HVHF+GH
>
> Cell: 970-980-9036
>
> http://www.researcherid.com/rid/A-7224-2009
>
>
>
> *“for being prematurely, and worse, intuitively right — there’s a heavy
> price. But for being wrong — no, not so long as you’re wrong in a pack."
> Gary Brecher / Portis*
>
>
>
> *I acknowledge that I live and work on stolen land. This is the land of
> the Cheyenne, Arapaho, Ute, and Ocheithi Sakowin people. To learn more
> about these nations, please visit;
>
> http://www.utemountainutetribe.com/
>
> http://www.cheyennenation.com/
>
> https://cheyenneandarapaho-nsn.gov/
>
> https://native-land.ca/
>
>
>


-- 
Michael Lefsky (He/His)
Home Location: HVHF+GH
Cell: 970-980-9036
http://www.researcherid.com/rid/A-7224-2009

*“for being prematurely, and worse, intuitively right — there’s a heavy
price. But for being wrong — no, not so long as you’re wrong in a pack."
Gary Brecher / Portis*

*I acknowledge that I live and work on stolen land. This is the land of the
Cheyenne, Arapaho, Ute, and Ocheithi Sakowin people. To learn more about
these nations, please visit;
http://www.utemountainutetribe.com/
http://www.cheyennenation.com/
https://cheyenneandarapaho-nsn.gov/
https://native-land.ca/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Layerstack multiple images, of different extents and variable number of bands

[Rahkonen Jukka via gdal-dev]

Hi,

Please clarify what is the desired result.  A multiband image that covers the 
union of extents of all the input images, with a number of bands that is the 
sum of bands in all the inputs or what?

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta lefsky--- via 
gdal-dev
Lähetetty: tiistai 23. tammikuuta 2024 19.01
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Layerstack multiple images, of different extents and variable 
number of bands

I've been incorporating gdal into my processing pipelines and have a question 
about a feature.

I need to be able to layer stack multiple images with different extents and 
varying numbers of bands, usually exceeding 1. I haven't been able to find a 
single command to do this in gdal. Am I missing something? If there is no such 
feature, has anyone developed a script out there that can robustly do all of 
those things (i.e. with checking for violation of assumptions about files and 
error handling)?

Michael

--
Michael Lefsky (He/His)
Home Location: HVHF+GH
Cell: 970-980-9036
http://www.researcherid.com/rid/A-7224-2009

"for being prematurely, and worse, intuitively right - there's a heavy price. 
But for being wrong - no, not so long as you're wrong in a pack." Gary Brecher 
/ Portis

*I acknowledge that I live and work on stolen land. This is the land of the 
Cheyenne, Arapaho, Ute, and Ocheithi Sakowin people. To learn more about these 
nations, please visit;
http://www.utemountainutetribe.com/
http://www.cheyennenation.com/
https://cheyenneandarapaho-nsn.gov/
https://native-land.ca/

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Layerstack multiple images, of different extents and variable number of bands

[lefsky--- via gdal-dev]

I've been incorporating gdal into my processing pipelines and have a
question about a feature.

I need to be able to layer stack multiple images with different extents and
varying numbers of bands, usually exceeding 1. I haven't been able to find
a single command to do this in gdal. Am I missing something? If there is no
such feature, has anyone developed a script out there that can robustly do
all of those things (i.e. with checking for violation of assumptions about
files and error handling)?

Michael

-- 
Michael Lefsky (He/His)
Home Location: HVHF+GH
Cell: 970-980-9036
http://www.researcherid.com/rid/A-7224-2009

*“for being prematurely, and worse, intuitively right — there’s a heavy
price. But for being wrong — no, not so long as you’re wrong in a pack."
Gary Brecher / Portis*

*I acknowledge that I live and work on stolen land. This is the land of the
Cheyenne, Arapaho, Ute, and Ocheithi Sakowin people. To learn more about
these nations, please visit;
http://www.utemountainutetribe.com/
http://www.cheyennenation.com/
https://cheyenneandarapaho-nsn.gov/
https://native-land.ca/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Non able to manage properly vitual file, warping and black edges

[andy via gdal-dev]

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 minutes.

Jukka, in the next few days I will answer your question.


Thank you to all of you

-- 
___

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 mezzo all’inferno, non è inferno,
e farlo durare, e dargli spazio"

Italo Calvino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Non able to manage properly vitual file, warping and black edges

[Rahkonen Jukka via gdal-dev]

Hi,

Please try to imagine that you are a stranger that might volunteer to help by 
running similar commands with same kind of imagery. Imagine a list of 
information and commands that you would need to know before you can do that. 
Then please share that information with us.

-Jukka Rahkonen-

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 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 cosa,
 in mezzo all'inferno, non è inferno,
e farlo durare, e dargli spazio"

Italo Calvino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Non able to manage properly vitual file, warping and black edges

[Even Rouault via gdal-dev]

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.
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 cosa,
 in mezzo all’inferno, non è inferno,
e farlo durare, e dargli spazio"

Italo Calvino


--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Non able to manage properly vitual file, warping and black edges

[andy via gdal-dev]

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 cosa,
 in mezzo all’inferno, non è inferno,
e farlo durare, e dargli spazio"

Italo Calvino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Non able to manage properly vitual file, warping and black edges

[andy via gdal-dev]

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 average input.tif

And the time difference is huge.
Later I will write it down for you precisely.

Thank you

>

-- 
___

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 mezzo all’inferno, non è inferno,
e farlo durare, e dargli spazio"

Italo Calvino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Non able to manage properly vitual file, warping and black edges

[Even Rouault via gdal-dev]

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


Thank you very much for the information you gave me, valuable

--
___

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 mezzo all’inferno, non è inferno,
e farlo durare, e dargli spazio"

Italo Calvino


--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Non able to manage properly vitual file, warping and black edges

[andy via gdal-dev]

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: https://medium.com/tantotanto
38° 7' 48" N, 13° 21' 9" E, EPSG:4326
___

"cercare e saper riconoscere chi e cosa,
 in mezzo all’inferno, non è inferno,
e farlo durare, e dargli spazio"

Italo Calvino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Non able to manage properly vitual file, warping and black edges

[Even Rouault via gdal-dev]

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 transparency and JPEG compression?

Should I change the type of compression?


require to create a mask band from the 4th band of the input by changing 
-b 4 to -mask 4, removing -co ALPHA=YES, and then you can ask YCbCr


gdal_translate -b 1 -b 2 -b 3 -mask 4 -co BIGTIFF=YES -co COMPRESS=JPEG 
-co PHOTOMETRIC=YCBCR -co JPEG_QUALITY=75 -co TILED=YES -co 
NUM_THREADS=ALL_CPUS warp.vrt output.tif


Note: if you use the COG driver it will do that automatically for you:

gdal_translate -of COG -co BIGTIFF=YES -co COMPRESS=JPEG -co 
NUM_THREADS=ALL_CPUS warp.vrt output.tif




Thank you,

Andrea



--
___

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 mezzo all’inferno, non è inferno,
e farlo durare, e dargli spazio"

Italo Calvino


--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev