<div dir="ltr">Hi Andrew, Even,<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 17, 2016 at 9:52 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">Le vendredi 16 septembre 2016 23:11:07, Even Rouault a écrit :<br>
> Le vendredi 16 septembre 2016 22:57:13, Andrew Bell a écrit :<br>
> > Hi,<br>
> ><br>
> > My code for creating a Tiff raster looks something like this:<br>
> ><br>
> > int nBands = 5;<br>
> > dataset->Create(filename, width, height, nBands, ...);<br>
> ><br>
> > for (int i = 1; i <= nBands; ++i)<br>
> > {<br>
> ><br>
> >     GDALRasterBand *band = dataset->GetRasterBand(i);<br>
> >     band->SetDescription(<wbr>someString);<br>
> >     band->WriteBlock(someData);<br>
> ><br>
> > }<br>
> ><br>
> > It appears that only the description to band 1 is written (it's the only<br>
> > one reported by gdalinfo).  A little debugging leads me to believe that<br>
> > what's happening is that WriteBlock() invokes Crystalize() -><br>
> > WriteMetadata(), which takes care of setting the band description.  But<br>
> > once Crystalize() is called, it sets a flag so as to be a NOOP in future<br>
> > calls.  I'm not using streaming.<br>
> ><br>
> > I'm trying to understand if this behavior is by design, a limitation that<br>
> > I can't find in the documentation or a bug.<br>
><br>
> It's a limitation due to how libtiff works mostly and/or how we use it (but<br>
> mostly how libtiff works, and a bit how the TIFF format itself makes it<br>
> hard). Basically for GTiff, you need to do all operations that affect<br>
> metadata, in a broad meaning, ie georeferencing, description, offsets,<br>
> color table, TIFF & GDAL metadata, etc... before writing any imagery.  If<br>
> we allowed to change metadata after crzystalization, this would require<br>
> rewriting the whole set of TIFF tags at the end of file each time their<br>
> serialized form increase.<br>
><br>
> So rewrite your loop into 2: one to set all descriptions, and another one<br>
> to write blocks.<br>
><br>
> Other formats may have similar limitations, so it is generally safe to<br>
> proceed this way in general.<br>
<br>
</div></div>Actually the above is partly true & wrong. It is indeed discouraged to change<br>
metadata after having started writting imagery, but in the case of the band<br>
description, you can still do it. As I said this will cause the TIFF directory<br>
to be rewritten, so a bit of storage loss, but nevertheless the descriptions<br>
are then correctly retrieved.<br>
<br>
I used the following Python test script<br>
<br>
{{{<br>
from osgeo import gdal<br>
gdal.SetCacheMax(0) # to force Fill() to commit to file immediatly<br>
ds = gdal.GetDriverByName('GTiff').<wbr>Create('test.tif', 1000, 1000, 5)<br>
for i in range(5):<br>
    ds.GetRasterBand(i+1).<wbr>SetDescription('foo%d' % i)<br>
    ds.GetRasterBand(i+1).Fill(<wbr>100)<br>
}}}<br>
<br>
Works on latest state of trunk , 2.1 and 2.0 branches<br></blockquote><div><br></div><div>I am so grateful you asked this question, Andrew.</div><div><br></div><div>Even, two follow up questions, one concrete, one more abstract. Is "crystalized" a state of all raster datasets, no matter the driver, and is there a method of determining whether the dataset is crystalized? Could this situation be made less complicated or be made more safe for developers by splitting the existing update access mode into update-metadata and update-imagery access modes?</div><div><br></div></div>-- <br><div class="gmail_signature"><div dir="ltr">Sean Gillies</div></div>
</div></div>