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 <[email protected]> > > 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 > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
