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

Javier Jimenez Shaw j1 at jimenezshaw.com
Thu Nov 14 04:32:41 PST 2024


Now reading more carefully what Even wrote, I see that he already mentioned
XMP.

On Thu, 14 Nov 2024 at 13:29, Luigi Pirelli <luipir at gmail.com> wrote:

> Thank you Javier
>
> good starting point to investigate an eventual fix to gdal :) I'll give
> alook!
>
> 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>
>
> **************************************************************************************************
>
>
> On Thu, 14 Nov 2024 at 13:18, Javier Jimenez Shaw <j1 at jimenezshaw.com>
> wrote:
>
>> In this PR I tried to pass the XMP data when a TIFF copy or COG was done
>> https://github.com/OSGeo/gdal/pull/3050
>> Maybe it was not complete.
>>
>> On Thu, 14 Nov 2024 at 13:10, Luigi Pirelli via gdal-dev <
>> gdal-dev at lists.osgeo.org> wrote:
>>
>>> 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.
>>>>
>>>> _______________________________________________
>>> gdal-dev mailing list
>>> gdal-dev at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20241114/948a9bb1/attachment.htm>


More information about the gdal-dev mailing list