[gdal-dev] 4th band as ALPHA on warp

[Even Rouault]

Le lundi 08 août 2016 09:30:53, Daniele Romagnoli a écrit :
> Hi Even,
> my usual question would be: any plan to backport it? :-)

Not really. I guess this is a new feature.

As currently, our policy is to be rather conservative for what goes in stable 
branches, so people can upgrade from one micro version to another one 
blindlessly.
Regarding that particular feature, it could potentially be backported, but 
then where to draw the limit ? At some point, one such backport will undoubtly 
cause a regression elsewhere, or will have bugs, causing more stabilization 
work in stable branches.

Potential solutions:
- More frequent major.minor.0 releases that our ~ 1 year schedule
- Less conservative policy backport policy in regular stable branches that 
would allow some new features to be added, but within the current limits of no 
ABI change, no backward incompatibilities.
- An extra -backport branch that would have a less conservative policy. To be 
defined what would be the limits: ABI changes allowed or not ?, backward 
incompatibilities ? Would potentially only of interest for people who can 
build from source as it would be unlikely to be widely packaged.

All would need extra staffing / funding.

Another option that already exists: live on the bleeding edge and build from 
trunk ;-)

Even

> 
> Cheers,
> Daniele
> 
> 
> 
> 
> 
> On Sun, Aug 7, 2016 at 10:38 PM, Even Rouault <even.rouault at spatialys.com>
> 
> wrote:
> > Le dimanche 07 août 2016 19:20:05, Even Rouault a écrit :
> > > Le samedi 06 août 2016 15:20:54, Fernando Ribeiro a écrit :
> > > > Dear list,
> > > > 
> > > > Currently we are working with 4 band tifs, first 3 bands as normal
> > > > RBG and the 4th as IR. On performing a warp operation from and to a
> > > > VRT, GDAL seems considering the 4th band as alpha, resulting in full
> > > > black pixels if 4th band value =0.
> > > 
> > > gdalwarp will consider the 4th band as alpha... only if it is
> > > effectively tagged as alpha in the source. You can check it with
> > > gdalinfo
> > > 
> > > > Some attempts were made to solve this issue, so far without success:
> > > > 
> > > > - Using the warp creation options PHOTOMETRIC=RGB and ALPHA=NO
> > > 
> > > This will not influence the warping kernel.
> > > 
> > > > - Manually editing the source VRT and replace Alpha color
> > 
> > interpretation
> > 
> > > > to Undefined
> > > 
> > > This one should work. Strange that this doesn't work for you.
> > > 
> > > > Does anyone have more suggestions?
> > 
> > I've just committed an improvement in trunk: "gdalwarp: add a -nosrcalpha
> > option to wrap the alpha band as a regular band and not as the alpha
> > band"
> > 
> > > > Thank you
> > 
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com