[gdal-dev] How to generate COG without loosing Exif, XMP etc metadata

[Luigi Pirelli]

Tnx Even

I suspected that -strict was not "complete". In any case My first code
version was adding tags over an already generated COG, but the result was
an unreadable/broken file in QGIS. I suppose because pyexiv2 is not
flexible enough and stuck with a rigid version of tiff structure.
I'll try a workaround using some lib or app able to maintain a readable
image, tnx for the hint.

Luigi Pirelli

**************************************************************************************************
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Book: Mastering QGIS3 - 3rd Edition
<https://www.packtpub.com/eu/application-development/mastering-geospatial-development-qgis-3x-third-edition>
**************************************************************************************************


On Thu, 14 Nov 2024 at 13:02, Even Rouault <even.rouault at spatialys.com>
wrote:

> Luigi,
>
> The GDAL GeoTIFF or COG drivers have currently no provision for writing
> EXIF (the fact that you see Exif.Image.Software is due to, I assume,
> exiftool synthetizing that information from the regular Software TIFF tag,
> which is propagated), so I don't have any solution to offer. Could
> potentially be implemented, but not a 5-minute job.
>
> "Breaking" the COG structure shouldn't be the end of the world. The
> breakage should be minimal. That will just cause one extra HTTP GET to
> clients. 95% of the value of COG is just being a tiled GeoTIFF with
> overviews. Putting all metadata (including the main TIFF directory) at
> beginning of the file is just the cherry on the cake.
>
> (a quick skim at https://github.com/airbusgeo/cogger which is useful to
> COGify a tiled GeoTIFF doesn't show any provision for EXIF, so I don't
> think you can use it for your use case)
>
> The XMP TIFF tag is propagated:
>
> $ gdal_translate autotest/gdrivers/data/gtiff/byte_with_xmp.tif out.tif
> -of cog
>
> $ gdalinfo out.tif -mdd all | grep XMP
> Metadata (xml:XMP):
>      <rdf:li>XMP</rdf:li>
>
> Even
> Le 14/11/2024 à 12:39, Luigi Pirelli via gdal-dev a écrit :
>
> Hi,
>
> I'm struggling to generate a COG maintaining the original (or at least a
> selected subset of) Exif and XMP tags (I ses that Iptc tags are not
> propagated at all, but I'm not interested in them).
> I used gda_translate via CLI or python and the best option seems -strict
> that, theoretically should maintain all original tags.
>
> But some standard tags are propagated and others not!
> e.g.
> Exif.Image.Software yes
> Exif.Photo.CameraOwnerName no
> Exif.Image.Artist yes
> Exif.Image.Copyright yes
> Exif.Image.DateTimeOriginal no
> Exif.Photo.DateTimeOriginal no
> Exif.Image.Model no
> Exif.Image.CameraSerialNumber no
> etc
>
> It is a bug? a feature? if a bug in any case is there a way to override?
> The reason to find a solution is that adding tags over a COG with
> "standard" tools like exiftool, exiv2 etc destroy COG structure. So I need
> to add or modify tags before converting to COG.
>
> any suggestion?
>
> Luigi Pirelli
> mails: luipir at gmail.com
>            luigi.pirelli at geobeyond.it
>
>
> **************************************************************************************************
> * LinkedIn: https://www.linkedin.com/in/luigipirelli
> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
> * GitHub: https://github.com/luipir
> * Book: Mastering QGIS3 - 3rd Edition
> <https://www.packtpub.com/eu/application-development/mastering-geospatial-development-qgis-3x-third-edition>
>
> **************************************************************************************************
>
> _______________________________________________
> gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
> Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20241114/8de49875/attachment-0001.htm>