[gdal-dev] Question on gdalwarp, srcnodata and dstalpha

Daniele Romagnoli daniele.romagnoli at geo-solutions.it
Mon Nov 7 00:29:35 PST 2016


Hi Even,
thanks for the feedback.

On Sun, Nov 6, 2016 at 5:33 PM, Even Rouault <even.rouault at spatialys.com>
wrote:

> Le jeudi 03 novembre 2016 18:19:36, Daniele Romagnoli a écrit :
> > Hi List,
> > I was checking a gdalwarp (GDAL 2.1.2) invokation with a colleague and I
> > have a question.
> >
> > I know that when warping a geotiff with internal NODATA_VALUES=0 0 0
> > metadata, only RGB pixels = 0 0 0 are handled as nodata whilst pixels
> like
> > "0 2 4", "50 0 0" will not right?
> >
> > In the past, I had issues using -scrnodata 0 instead of embedded
> > NODATA_VALUES=0 0 0, getting results with sparse nodata around due to
> > band_i = 0 being interpreted as a nodata pixels. This is why I usually
> > suggest to define the NODATA_VALUES metadata to make sure only the exact
> > triplet is handled as nodata.
> >
> > However, today we have processed a simple UTM RGB dataset (without
> > NODATA_VALUES metadata defined) using this command:
> > gdalwarp -t_srs EPSG:4326 -srcnodata 0 -dstnodata None -dstalpha
> >
> > And the result is properly rendered: the alpha mask is zero only where
> the
> > input pixels are "0 0 0" which is exactly what we needed.
> > Do something has been changed in the latest versions? Is the alpha band
> > mask being set to zero only when all input pixels are zero?
>
> Hi Daniele,
>
> This is a good question, and I would have thought the same as you. But when
> digging further, the nodata values must be indeed fully matched for all
> components to consider a pixel as transparent. And this has been the case
> for
> the last 11 years :-)) : https://trac.osgeo.org/gdal/changeset/8286
>
> My confusion came from the fact that the default behaviour of the warping
> engine used by gdalwarp is not that one (see UNIFIED_SRC_NODATA option in
> http://www.gdal.org/structGDALWarpOptions.html#
> a0ed77f9917bb96c7a9aabd73d4d06e08),
> but gdalwarp override it to have the UNIFIED_SRC_NODATA=YES behaviour.
>

Thanks for the investigation.

At this point, if this behavior is there since 11 years, I guess that the
cause of the issues I had in the past was probably involving a gdaladdo
after a gdalwarp in my processing. So that gdalwarp was internally
considering nodata a fully matching 0 triplets to produce the high res
output whilst gdaladdo was considering nodata on band basis, separately,
producing scattered no data.

Cheers,
Daniele


>
> I've also just added support in trunk to be able to specify
> UNIFIED_SRC_NODATA=NO explicitly if wished.
>
> See :
>
> Let create a dataset with a single pixel R,G,B=10,20,30 with
> gdal_translate byte.tif rgb.tif -b 1 -b 1 -b 1 -scale_1 0 255 10 10 \
>     -scale_2 0 255 20 20  -scale_3 0 255 30 30 -srcwin 0 0 1 1
>
> By default:
> gdalwarp rgb.tif out.tif -overwrite  -srcnodata 10 -dstnodata None
> -dstalpha
> lead to (R,G,B,A)=(10,20,30,255)
>
> And (in trunk):
> gdalwarp rgb.tif out.tif -overwrite  -srcnodata 10 -dstnodata None
> -dstalpha \
>                  -wo UNIFIED_SRC_NODATA=NO -wo INIT_DEST=127
> lead to (R,G,B,A)=(127,20,30,255)
>
> ==> Nodata is applied band per band, and alpha is considered to be 255 as
> soon
> as at least one band is valid.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>



-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20161107/d55104b0/attachment.html>


More information about the gdal-dev mailing list