[gdal-dev] gdal_retile not generating alpha band

[Tom Wardrop]

It would be really nice if I could find a single pass solution for this. I need to retile 200GB of imagery and would prefer not to have to process it twice. I think my work-around using gdal_translate is a better solution than converting black pixels to alpha, besides, I’m using GeoServer with the ImagePyramid plugin which I don’t believe supports “nodata” transparency. It needs an alpha channel.

Tom Wardrop
IT Development Officer
ICT Section, Systems & Customer Service Group

[Description: C:\Users\royl.MSC\AppData\Roaming\Microsoft\Signatures\logo\logo.png]
Phone: 1300 308 461  |  Direct: 07 4086 4668  |  Fax: 07 4092 3323
Email: tomw at msc.qld.gov.au<mailto:RoyL at msc.qld.gov.au>  |  Website: www.msc.qld.gov.au<http://www.msc.qld.gov.au/>
65 Rankin Street, Mareeba  |  PO Box 154, Mareeba, Queensland, Australia, 4880

ý Go green, keep it on screen - think before you print


From: David Strip <gdal at stripfamily.net<mailto:gdal at stripfamily.net>>
Date: Tuesday, 5 May 2015 12:49 am
To: Tom Wardrop <tomw at msc.qld.gov.au<mailto:tomw at msc.qld.gov.au>>, "gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>" <gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>>
Subject: Re: [gdal-dev] gdal_retile not generating alpha band

This sounds more like a problem with a missing NODATA value rather than transparency/alpha. As far as I can tell from the docs, there is no means to specify the NODATA value in the gdal_retile command, including the CO options. If the only place that true black occurs is in the regions with no input, you could use gdal_edit.py to add a NODATA value.

On 5/3/2015 11:23 PM, Tom Wardrop wrote:
Hi all,

I retiled whole lot of imagery over the weekend using the following gdal_retile command:


gdal_retile.py -v -r bilinear -levels 8 -ps 2048 2048 -s_srs EPSG:28355 -co "TILED=YES" -co "ALPHA=YES" -targetDir ~/output ~/input/*.tif

The result was good until I realised all the areas that should be transparent were instead black. It seems the problem is the source imagery didn’t have an alpha channel; it didn’t need one as there was no transparent data to represent. Because the source imagery didn’t fill the entire extent, gdal_retile had to create loads of transparent and partially-transparent tiles, which of course wound up black.

I was under the impression that "-co ALPHA=YES” would instruct gdal_retile to generate an alpha channel for all the generated tiles. Is this a bug? If not, how do I otherwise instruct gdal_retile to generate an alpha channel when required?

I’m working around this by using gdal_translate to re-save the source imagery with an (empty) alpha channel, so gdal_retile now outputs transparent tiles.

Any feedback is appreciated.

Cheers,
Tom




________________________________

Mareeba Shire Council Disclaimer

This message and any attachments may contain privileged and confidential information intended only for the use of the intended addressee(s). Any unauthorised use of this material is prohibited. If you received this message in error please notify the sender immediately, delete the message and destroy any printed or electronic copies. Opinions expressed in this e-mail are those of the sender and do not necessarily represent the views of the Mareeba Shire Council. Council does not accept any responsibility for the loss or damage that may result from reliance on, or the use of, any information contained in this e-mail or attachments.

We recommend that you scan this e-mail and any attachments for viruses before opening. This Council does not accept liability for any loss or damage incurred either directly or indirectly from opening this e-mail or any attachments to it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150504/72f37dc9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 403C01F8-B3C0-4FFC-B18D-E7CE62F0DC36[12].png
Type: image/png
Size: 9094 bytes
Desc: 403C01F8-B3C0-4FFC-B18D-E7CE62F0DC36[12].png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150504/72f37dc9/attachment.png>