                                        <font size="2" face="Tahoma" color="#000000 ">Hi Even,</font><div><font size="2" face="Tahoma" color="#000000 "><br></font></div><div><font size="2" face="Tahoma" color="#000000 ">thanks for your response. Okay, I see now. </font></div><div><font size="2" face="Tahoma" color="#000000 ">If I would extend </font><font face="Tahoma" size="2">asTIFFTags variable of type </font><span style="font-family: Tahoma; font-size: small;">GTIFFTags in geotiff.cpp, I should be able to use more of the tifftags, or am I wrong? Maybe I have to have a look at the type handling and some other places where the table is used too.</span></div><div><span style="font-family: Tahoma; font-size: small;"><br></span></div><div><font face="Tahoma" size="2">I had another look at the interaction with exiv2. I now think that has something to do with the fact, that exiv2 memory maps the file, because I can repeatedly open, read and write the file with gdal and libtiff and basic fopen() and the code does not have to wait. I will get in contact with the guys of exiv2 to maybe get some insight.</font></div><div><font face="Tahoma" size="2"><br></font></div><div><font face="Tahoma" size="2">Thanks for your help so far.</font></div><div><font face="Tahoma" size="2">Cheers,</font></div><div><font face="Tahoma" size="2">Immanuel</font></div><div><font size="2" face="Tahoma" color="#000000 "><br></font><font size="2" face="Tahoma" color="#000000 "><div class="mb_sig"></div></font><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">

                                       <p style="color: #AAAAAA; margin-top: 10px;">Am 08.09.2015 13:44:54 schrieb Even Rouault <even.rouault@spatialys.com>:</p>Immanuel,

<br>

<br>> 

> sorry for not getting back earlier, I got distracted by other stuff to fix.

<br>> Thanks for your reply. At the moment I will stick with your proposed way of

<br>> writing with libtiff and adding geo data with gdal later, as I have to get

> that code running quickly. But I will try have a look at it again later.

<br>> 

<br>> Now there is another problem slowing the process down. I want to add some

<br>> exif and xmp tags to the images. After fiddling arround with libtiff, which

<br>> has a rather simple (for my case not really useful) conversion of floating

<br>> point values to rational values, I went with exiv2. Tagging with it is very

<br>> easy and straightforward. Unfortunately due to some harddrive buffering (i

<br>> think) the image is locked for a longer time than the actual writing with

<br>> libtiff takes. That blocks exiv2 for quite some time until it gets write

<br>> access to that file, on my machine around 50-60 ms, which is 100 times of

> the actual writing time. So that's really bad.

<br>> 

<br>> Now I'm reviewing my other options. As I'm going to write the geo

<br>> information using GDAL i think it should also use if to write the metadata

<br>> (I did not test it, but I think it will also have to wait for the drive to

<br>> be finished, but then I would stick completely with GDAL, as it's (at the

<br>> moment) slower writing compared to libtiff is still a factor of  >10 faster

> than the lock takes).

<br>> 

<br>> So my question now is, if it is possible to write all kinds of tags using

<br>> GDAL.

<br>

<br>Short answer: no. Only a few TIFF tags can be written currently (the one 

<br>listed in "Metadata" paragraph of http://www.gdal.org/frmt_gtiff.html)

<br>

<br>Adding support for writing XMP (the user would provide the XML) would be easy. 

Writting EXIF data would probably be a bit more involved.

<br>

<br>> gdalinfo reports some of the tags written with exiv2, but not all,

> for examples Exif.Photo.Make is not listed. And if so how do I do that?

<br>

<br>The list of EXIF tags that are read currently is in gcore/gdalexif.h

<br>

<br>> I

<br>> was able to add custom tags using SetMetaData() on the dataset, but these

<br>> can (not surprizingly) not be recognized by the applications, which will

> use my images.

> Maybe you or others can help me with that.

<br>

<br>One option if you want to act directly with libtiff, but don't want to close 

<br>the GDAL dataset and reopen with libtiff afterwards is to call 

<br>GetInternalHandle(NULL) on the GDAL dataset object. It returns a TIFF* handle. 

<br>However this is semi-private / implementation detail and what you could do 

<br>with it could potentially interact badly with what GDAL does, so to be used 

only if really necessary.

<br>

<br>Even

<br>

<br>> 

<br>> Thanks for your assistance,

<br>> Immanuel

<br>> 

<br>> 2015-08-07 20:25 GMT+02:00 Even Rouault <even.rouault@spatialys.com>:

<br>> > Le jeudi 06 août 2015 17:29:06, Immanuel Weber a écrit :

<br>> > > Hi all,

<br>> > > 

> > > I'm working on an application where lots of images have to be written.

<br>> > > Until now I'm using libtiff for that task. But as I want to add

<br>> > > georeferencing and the like I'm having a look at GDAL right now. I did

<br>> > > a quick evaluation of its performance related to libtiff and

<br>> > > unfortunately it has quite a lot of overhead. I first tested GDAL 1.10

> > > and it was a factor of 6-7 slower than the direct write with libtiff.

<br>> > > With GDAL 2.0 it got a little better with a factor of 4. (I took a 1,5

<br>> > > MP image and wrote for a few hundred times to the disk and libtiff

<br>> > > takes about 3 ms for

<br>> > 

<br>> > that,

<br>> > 

<br>> > > where as GDAL around 12 ms). I read about a performance issue with

<br>> > > GDALDataSet::RasterIO vs GDALRasterBand::ReadBlock and tried to

<br>> > > implement the storage using GDALRasterBand::WriteBlock* but that

> > > almost took more time than the GDALDataSet::RasterIO version.

<br>> > > 

<br>> > > Is there any other way to write tiffs quickly with GDAL, or is that

<br>> > > kind

<br>> > 

<br>> > of

<br>> > 

<br>> > > overhead expected for the added functionality?

<br>> > 

<br>> > Immanuel,

<br>> > 

<br>> > WriteBlock() with a INTERLEAVE=BAND file should be really close to pure

<br>> > libtiff

> > performance. Other cases will involve a few extra buffer copies.

<br>> > 

<br>> > Another option is to write the imagery with libtiff as you did, and then

<br>> > open

<br>> > the file in update mode with GDAL to add the georeferencing. This will

> > just rewrite the TIFF header.

<br>> > 

<br>> > > Thanks and best regards,

<br>> > > Immanuel

<br>> > > 

<br>> > > *I wasn't really successful in doing that, because I didn't find a way

<br>> > > to write pixel interleaved images with that

<br>> > 

<br>> > GDAL blocks are per band. But GDAL will take care of combining several

<br>> > blocks

<br>> > of same (x,y) for a INTERLEAVE=PIXEL TIFF. To get the best performance,

<br>> > in INTERLEAVE=PIXEL, you should do (pseudo-code):

<br>> > 

<br>> > for y in yblocks:

<br>> >         for x in xblocs:

<br>> >                 for b in bands:

<br>> >                         GetRasterBand(b)->WriteBlock(x,y, buffer)

<br>> > 

<br>> > to avoid partial TIFF tiles/strips to be written, read and re-written

<br>> > when the

> > data for the band comes.

<br>> > 

<br>> > Even

<br>> > 

<br>> > --

<br>> > Spatialys - Geospatial professional services

<br>> > http://www.spatialys.com

<br>

<br>-- 

<br>Spatialys - Geospatial professional services

<br>http://www.spatialys.com

<br>

                                       </even.rouault@spatialys.com></blockquote>

                                        </div>