Re: [gdal-dev] gdalwarp alpha band resampling bug

2021-09-17 Thread Patrick Young 
One more data point; another colleague who is on a mac but built gdal
himself instead of using brew does not see the artifact, so I suppose the
lesson is, build your own gdal!

Best,
P

On Fri, Sep 17, 2021 at 8:51 PM Patrick Young <
patrick.mckendree.yo...@gmail.com> wrote:

> Hi Even,
>
> Thanks for checking!  I tried this in a docker container (osgeo/gdal) and
> sure enough, the output looks fine there.
>
> It reproduces for me with my brew installed gdal (3.3.2) and I was careful
> to do everything in a clean directory.  I tried a few other outputs as well
> (png, jpeg) and the toucan remains surrounded by white.  I also had a
> colleague check (he is also on a mac, using a brew installed GDAL 3.3.0)
> and he sees the same artifact that I see.
>
> I have no idea what could be causing it!  Interestingly, if the background
> raster is (255, 0, 0), you don't get the white everywhere, but instead you
> get solid red wherever the alpha is in [1,254].  I wonder what it could be!
>
> Best,
> Patrick
>
>
>
> On Fri, Sep 17, 2021 at 5:18 PM Even Rouault 
> wrote:
>
>> I can't reproduce the issue you describe. There's not a single white
>> pixel in the output image (the max of the green and blue bands is < 255).
>> But I suspect this could be related to a pre-existing composite-bl.tif file
>> you might have. gdalwarp doesn't overwrite by default the output image. It
>> blends into it. If you add -overwrite, you should get a reasonable output.
>> Le 18/09/2021 à 01:06, Patrick Young a écrit :
>>
>> Hello,
>>
>> I've found behavior in gdalwarp related to compositing an image with a
>> variable alpha band.  Under bilinear resampling, the alpha compositing in
>> areas where the alpha band is between 0 and 255 results in completely white
>> pixels.
>>
>> To reproduce, I've first grabbed a rgba image from the test suite, e.g.:
>>
>> wget
>> https://github.com/OSGeo/gdal/raw/a2db646d1c34905e47eb21657284b529b7478d66/autotest/gcore/data/stefan_full_rgba.tif
>>
>> Then,
>>
>> gdal_create -ot Byte -bands 3 -burn 71 147 240 -outsize 162 150 -a_srs
>> EPSG:3857 -a_ullr 0 162 150 0 background.tif
>> gdal_translate -a_srs EPSG:3857 -a_ullr 0 162 150 0 stefan_full_rgba.tif
>> foreground.tif
>> gdalwarp -r bilinear background.tif foreground.tif composite-bl.tif
>>
>> In this case, composite-bl.tif is white wherever the alpha is in [1,
>> 254].  Trying
>>
>> gdalwarp background.tif foreground.tif composite-nn.tif
>>
>> produces a reasonable image, although it is blocker than when I overlay
>> background.tif and foreground.tif in qgis.
>>
>> Thanks for any tips about what I'm seeing, happy to file a bug if it is
>> one!  I've tested this on gdal 3.2.2 on macos (from brew).
>> Patrick
>>
>> ___
>> gdal-dev mailing 
>> listgdal-dev@lists.osgeo.orghttps://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] gdalwarp alpha band resampling bug

2021-09-17 Thread Patrick Young 
Hi Even,

Thanks for checking!  I tried this in a docker container (osgeo/gdal) and
sure enough, the output looks fine there.

It reproduces for me with my brew installed gdal (3.3.2) and I was careful
to do everything in a clean directory.  I tried a few other outputs as well
(png, jpeg) and the toucan remains surrounded by white.  I also had a
colleague check (he is also on a mac, using a brew installed GDAL 3.3.0)
and he sees the same artifact that I see.

I have no idea what could be causing it!  Interestingly, if the background
raster is (255, 0, 0), you don't get the white everywhere, but instead you
get solid red wherever the alpha is in [1,254].  I wonder what it could be!

Best,
Patrick



On Fri, Sep 17, 2021 at 5:18 PM Even Rouault 
wrote:

> I can't reproduce the issue you describe. There's not a single white pixel
> in the output image (the max of the green and blue bands is < 255). But I
> suspect this could be related to a pre-existing composite-bl.tif file you
> might have. gdalwarp doesn't overwrite by default the output image. It
> blends into it. If you add -overwrite, you should get a reasonable output.
> Le 18/09/2021 à 01:06, Patrick Young a écrit :
>
> Hello,
>
> I've found behavior in gdalwarp related to compositing an image with a
> variable alpha band.  Under bilinear resampling, the alpha compositing in
> areas where the alpha band is between 0 and 255 results in completely white
> pixels.
>
> To reproduce, I've first grabbed a rgba image from the test suite, e.g.:
>
> wget
> https://github.com/OSGeo/gdal/raw/a2db646d1c34905e47eb21657284b529b7478d66/autotest/gcore/data/stefan_full_rgba.tif
>
> Then,
>
> gdal_create -ot Byte -bands 3 -burn 71 147 240 -outsize 162 150 -a_srs
> EPSG:3857 -a_ullr 0 162 150 0 background.tif
> gdal_translate -a_srs EPSG:3857 -a_ullr 0 162 150 0 stefan_full_rgba.tif
> foreground.tif
> gdalwarp -r bilinear background.tif foreground.tif composite-bl.tif
>
> In this case, composite-bl.tif is white wherever the alpha is in [1,
> 254].  Trying
>
> gdalwarp background.tif foreground.tif composite-nn.tif
>
> produces a reasonable image, although it is blocker than when I overlay
> background.tif and foreground.tif in qgis.
>
> Thanks for any tips about what I'm seeing, happy to file a bug if it is
> one!  I've tested this on gdal 3.2.2 on macos (from brew).
> Patrick
>
> ___
> gdal-dev mailing 
> listgdal-dev@lists.osgeo.orghttps://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] gdalwarp alpha band resampling bug

2021-09-17 Thread Even Rouault 
I can't reproduce the issue you describe. There's not a single white 
pixel in the output image (the max of the green and blue bands is < 
255). But I suspect this could be related to a pre-existing 
composite-bl.tif file you might have. gdalwarp doesn't overwrite by 
default the output image. It blends into it. If you add -overwrite, you 
should get a reasonable output.


Le 18/09/2021 à 01:06, Patrick Young a écrit :

Hello,

I've found behavior in gdalwarp related to compositing an image with a 
variable alpha band.  Under bilinear resampling, the alpha compositing 
in areas where the alpha band is between 0 and 255 results in 
completely white pixels.


To reproduce, I've first grabbed a rgba image from the test suite, e.g.:

wget 
https://github.com/OSGeo/gdal/raw/a2db646d1c34905e47eb21657284b529b7478d66/autotest/gcore/data/stefan_full_rgba.tif 



Then,

gdal_create -ot Byte -bands 3 -burn 71 147 240 -outsize 162 150 -a_srs 
EPSG:3857 -a_ullr 0 162 150 0 background.tif
gdal_translate -a_srs EPSG:3857 -a_ullr 0 162 150 0 
stefan_full_rgba.tif foreground.tif

gdalwarp -r bilinear background.tif foreground.tif composite-bl.tif

In this case, composite-bl.tif is white wherever the alpha is in [1, 
254].  Trying


gdalwarp background.tif foreground.tif composite-nn.tif

produces a reasonable image, although it is blocker than when I 
overlay background.tif and foreground.tif in qgis.


Thanks for any tips about what I'm seeing, happy to file a bug if it 
is one!  I've tested this on gdal 3.2.2 on macos (from brew).

Patrick

___
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

[gdal-dev] gdalwarp alpha band resampling bug

2021-09-17 Thread Patrick Young 
Hello,

I've found behavior in gdalwarp related to compositing an image with a
variable alpha band.  Under bilinear resampling, the alpha compositing in
areas where the alpha band is between 0 and 255 results in completely white
pixels.

To reproduce, I've first grabbed a rgba image from the test suite, e.g.:

wget
https://github.com/OSGeo/gdal/raw/a2db646d1c34905e47eb21657284b529b7478d66/autotest/gcore/data/stefan_full_rgba.tif

Then,

gdal_create -ot Byte -bands 3 -burn 71 147 240 -outsize 162 150 -a_srs
EPSG:3857 -a_ullr 0 162 150 0 background.tif
gdal_translate -a_srs EPSG:3857 -a_ullr 0 162 150 0 stefan_full_rgba.tif
foreground.tif
gdalwarp -r bilinear background.tif foreground.tif composite-bl.tif

In this case, composite-bl.tif is white wherever the alpha is in [1, 254].
Trying

gdalwarp background.tif foreground.tif composite-nn.tif

produces a reasonable image, although it is blocker than when I overlay
background.tif and foreground.tif in qgis.

Thanks for any tips about what I'm seeing, happy to file a bug if it is
one!  I've tested this on gdal 3.2.2 on macos (from brew).
Patrick
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] profiles in gdal2tiles.py

2021-09-17 Thread Even Rouault 


Le 17/09/2021 à 23:03, Brent Fraser a écrit :

Hi All,

I'm interested in experimenting with creating tile sets in various 
coordinate systems (other than the usual EPSG:3857 and EPSG:4326). 
 The good news is that it looks like as of GDAL v3.2 gdal2tiles.py 
supports a "profile" option for defining the tile set including the 
coordinate system.


The profile is in JSON with all the detail gdal2tiles would require to 
create tiles (example: 
https://github.com/OSGeo/gdal/blob/master/gdal/data/tms_MapML_APSTILE.json 
)
This follows the JSON encoding of the OGC Two Dimensional Tile Matrix 
Set  specification: 
https://docs.opengeospatial.org/is/17-083r2/17-083r2.html


I suppose I could create a profile JSON file by hand (or do some 
coding) but I thought I would ask if there was an existing tool?
Not that I'm aware of. A few lines of Python should be enough to create 
a profile with zoom levels varying by a factor of 2 for the resolution, 
which is currently a constraint for the profile to be accepted by 
gdal2tiles.


Thanks!
Brent Fraser


___
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

[gdal-dev] profiles in gdal2tiles.py

2021-09-17 Thread Brent Fraser 
Hi All,

I'm interested in experimenting with creating tile sets in various coordinate 
systems (other than the usual EPSG:3857 and EPSG:4326).  The good news is that 
it looks like as of GDAL v3.2 gdal2tiles.py supports a "profile" option for 
defining the tile set including the coordinate system.

The profile is in JSON with all the detail gdal2tiles would require to create 
tiles (example: 
https://github.com/OSGeo/gdal/blob/master/gdal/data/tms_MapML_APSTILE.json)

I suppose I could create a profile JSON file by hand (or do some coding) but I 
thought I would ask if there was an existing tool?

Thanks!
Brent Fraser


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

Re: [gdal-dev] Geoserver 2.20.RC generating high CPU load

2021-09-17 Thread Andrea Aime 
Hi Jukka,
try to get the pid of the process and run a "jstack ", let's see what
happens.
Btw, wrong mailing list :-D

Cheers
Andrea

On Fri, Sep 17, 2021 at 8:29 AM Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> I installed and started GS 2.20 yesterday on Windows and now the
> corresponding OpenJDK 11 process shows constant high CPU usage (12-17%).
> Service is started at localhost:8080 and I do not generate any requests for
> the service. I do not understand what happens and how to investigate the
> situation. Any suggestions?
>
>
>
> -Jukka Rahkonen-
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Geoserver 2.20.RC generating high CPU load

2021-09-17 Thread Rahkonen Jukka (MML) 
Hi,

I installed and started GS 2.20 yesterday on Windows and now the corresponding 
OpenJDK 11 process shows constant high CPU usage (12-17%). Service is started 
at localhost:8080 and I do not generate any requests for the service. I do not 
understand what happens and how to investigate the situation. Any suggestions?

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