"warning: Failed to decode Exif metadata" with Google Gemini-generated image

[skierpage]

Describe the bug

I generated an image with Imagen/Gemini 2.5 Flash at gemini.google.com, downloaded it, and when I opened the PNG in GIMP, got a GIMP Debug window saying "GIMP encountered an error: GIMP-WARNING: Failed to decode Exif metadata." exiv2 print displays the same warning along with "No Exif data found in the file" so I'm reporting it here as well as GIMP issue 14653.

To Reproduce

Steps to reproduce the behavior:

1. Here's the file, compressed in case GitHub changes the metadata of an uploaded image:
   Gemini_image_exif_warning.zip. I took the original photo that Google Gemini Image generation modified, and nobody can copyright AI images, so do with it whatever you want.
2. To reproduce, go to gemini.google.com, click Image, generate an image. Download it. Run exiv2 print FILENAME (the zip file contains Gemini_Generated_Image_20wm9820wm9820wm.png).
3. This is in exiv2 version 0.28.5 as packaged for Fedora 41 (and in whatever exiv2 library is packaged by the GIMP 3.1.2 Flatpak app).

Expected behavior

No warning, unless of course Google Gemini generates garbled .png files. (with other stripped images exiv2 prints "No Exif data found in the file" without a warning.) ImageMagick doesn't print a warning

Desktop (please complete the following information):

• Linux Fedora 41
• Exiv2 version and source: version 0.28.5 as packaged for Fedora 41, using exiv2-libs version 0.28.5
• Compiler and version: ??
• Compilation mode and/or compiler flags: ?? The binary reports

% ldd /usr/bin/exiv2
        linux-vdso.so.1 (0x00007f508a98a000)
        libexiv2.so.28 => /usr/bin/../lib64/libexiv2.so.28 (0x00007f508a600000)
        libstdc++.so.6 => /usr/bin/../lib64/libstdc++.so.6 (0x00007f508a200000)
        libgcc_s.so.1 => /usr/bin/../lib64/libgcc_s.so.1 (0x00007f508a902000)
        libc.so.6 => /usr/bin/../lib64/libc.so.6 (0x00007f508a00c000)
        libexpat.so.1 => /usr/bin/../lib64/../lib64/libexpat.so.1 (0x00007f508a8d8000)
        libz.so.1 => /usr/bin/../lib64/../lib64/libz.so.1 (0x00007f508a5dc000)
        libbrotlidec.so.1 => /usr/bin/../lib64/../lib64/libbrotlidec.so.1 (0x00007f508a5ce000)
        libINIReader.so.0 => /usr/bin/../lib64/../lib64/libINIReader.so.0 (0x00007f508a8ce000)
        libm.so.6 => /usr/bin/../lib64/../lib64/libm.so.6 (0x00007f508a4e8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f508a98c000)
        libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f508a4af000)
        libinih.so.0 => /lib64/libinih.so.0 (0x00007f508a4aa000)

Additional context

Here's the full exiv2 output:

% exiv2 -v print Gemini_Generated_Image_20wm9820wm9820wm.png
File 1/1: Gemini_Generated_Image_20wm9820wm9820wm.png
Warning: Failed to decode Exif metadata.
File name       : Gemini_Generated_Image_20wm9820wm9820wm.png
File size       : 1705405 Bytes
MIME type       : image/png
Image size      : 1024 x 832
Gemini_Generated_Image_20wm9820wm9820wm.png: No Exif data found in the file

For what it's worth, ImageMagick doesn't print a warning, and magick identify -debug all -verbose Gemini_Generated_Image_20wm9820wm9820wm.png prints out (or hallucinate 😉) exif details, mentioning an 8388-byte Profile-exif chunk and other chunks. Here's its output without -debug all:

% identify -verbose Gemini_Generated_Image_20wm9820wm9820wm.png 
Image:
  Filename: Gemini_Generated_Image_20wm9820wm9820wm.png
  Permissions: rw-r-----
  Format: PNG (Portable Network Graphics)
  Mime type: image/png
  Class: DirectClass
  Geometry: 1024x832+0+0
  Units: Undefined
  Colorspace: sRGB
  Type: TrueColor
  Endianness: Undefined
  Depth: 8-bit
  Channels: 3.0
  Channel depth:
    Red: 8-bit
    Green: 8-bit
    Blue: 8-bit
  Channel statistics:
    Pixels: 851968
    Red:
      min: 0  (0)
      max: 255 (1)
      mean: 124.214 (0.487113)
      median: 110 (0.431373)
      standard deviation: 50.6128 (0.198481)
      kurtosis: -0.496617
      skewness: 0.484408
      entropy: 0.937417
    Green:
      min: 0  (0)
      max: 255 (1)
      mean: 136.91 (0.536903)
      median: 152 (0.596078)
      standard deviation: 50.5232 (0.19813)
      kurtosis: -0.516282
      skewness: -0.440673
      entropy: 0.928334
    Blue:
      min: 0  (0)
      max: 255 (1)
      mean: 140.919 (0.552622)
      median: 124 (0.486275)
      standard deviation: 83.9452 (0.329197)
      kurtosis: -1.46191
      skewness: 0.129399
      entropy: 0.928267
  Image statistics:
    Overall:
      min: 0  (0)
      max: 255 (1)
      mean: 134.014 (0.525546)
      median: 128.667 (0.504575)
      standard deviation: 61.6937 (0.241936)
      kurtosis: -0.824937
      skewness: 0.0577114
      entropy: 0.931339
  Rendering intent: Perceptual
  Gamma: 0.454545
  Chromaticity:
    red primary: (0.64,0.33,0.03)
    green primary: (0.3,0.6,0.1)
    blue primary: (0.15,0.06,0.79)
    white point: (0.3127,0.329,0.3583)
  Matte color: grey74
  Background color: white
  Border color: srgb(223,223,223)
  Transparent color: black
  Interlace: None
  Intensity: Undefined
  Compose: Over
  Page geometry: 1024x832+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: Zip
  Orientation: TopLeft
  Profiles:
    Profile-exif: 8388 bytes
    Profile-xmp: 796 bytes
  Properties:
    date:create: 2025-08-11T20:07:04+00:00
    date:modify: 2025-08-11T03:22:07+00:00
    date:timestamp: 2025-08-11T20:19:17+00:00
    exif:ColorSpace: 1
    exif:ExifOffset: 58
    exif:ExifVersion: 0220
    exif:ImageUniqueID: 1d4646cec8a4defa0000000000000000
    exif:InteroperabilityOffset: 170
    exif:PixelXDimension: 1024
    exif:PixelYDimension: 832
    exif:Software: Picasa
    exif:thumbnail:Compression: 6
    exif:thumbnail:InteroperabilityIndex: R98
    exif:thumbnail:InteroperabilityVersion: 0100
    exif:thumbnail:JPEGInterchangeFormat: 294
    exif:thumbnail:JPEGInterchangeFormatLength: 8088
    exif:thumbnail:ResolutionUnit: 2
    exif:thumbnail:XResolution: 72/1
    exif:thumbnail:YResolution: 72/1
    png:IHDR.bit-depth-orig: 8
    png:IHDR.bit_depth: 8
    png:IHDR.color-type-orig: 2
    png:IHDR.color_type: 2 (Truecolor)
    png:IHDR.interlace_method: 0 (Not interlaced)
    png:IHDR.width,height: 1024, 832
    png:text: 1 tEXt/zTXt/iTXt chunks were found
    png:text-encoded profiles: 1 were found
    signature: 8769c91eddd1fc2f016bbece7a4fb3c1633de398fda3535cbd5d857eb1d29d4a
  Artifacts:
    verbose: true
  Tainted: False
  Filesize: 1.6264MiB
  Number pixels: 851968
  Pixel cache type: Memory
  Pixels per second: 21.4225MP
  User time: 0.040u
  Elapsed time: 0:01.039
  Version: ImageMagick 7.1.1-47 Q16-HDRI x86_64 22763 https://imagemagick.org

[kmilos]

No warning, unless of course Google Gemini generates garbled .png files.

This is possible. See e.g. libjxl/libjxl#4383 (comment)

Please confirm the PNGs are valid first using some other tools. You can also run exiv2 -pS and exiftool -v3 for more info.

[clanmills]

The EXIF metadata has been compressed and stored as a zTXt block.

640 rmills@rmillsm4:~/Downloads $ exiv2  -pSR Gemini_Generated_Image_20wm9820wm9820wm.png  | head
STRUCTURE OF PNG FILE: Gemini_Generated_Image_20wm9820wm9820wm.png
 address | chunk |  length | data                           | checksum
       8 | IHDR  |      13 | .......@....                   | 0x3a808836
      33 | sBIT  |       3 | ...                            | 0xdbe14fe0
      48 | zTXt  |    9404 | Raw profile type APP1..x...Y.$ | 0x042979cc
    9464 | iTXt  |     818 | XML:com.adobe.xmp.....<?xpacke | 0x3db44517
   10294 | IDAT  |    8192 | x...i....$h.y~....."._:......x | 0x34862364
   18498 | IDAT  |    8192 | .....~......!...!..:n?.#Ep^... | 0x12f5c893
   26702 | IDAT  |    8192 | .......5.Ki......l.ny.F......9 | 0xb480b14c
   34906 | IDAT  |    8192 | :Cm.o...B..R..j..... ..iuG-... | 0x84418fad
641 rmills@rmillsm4:~/Downloads $ tvisitor -pRU Gemini_Generated_Image_20wm9820wm9820wm.png  | head
STRUCTURE OF PNG FILE (MM): Gemini_Generated_Image_20wm9820wm9820wm.png
  address | chunk |  length |   checksum | data                                     | decompressed                             | dehexed
        8 |  IHDR |      13 | 0x3a808836 | __.___.@..___
       33 |  sBIT |       3 | 0xdbe14fe0 | ...
       48 |  zTXt |    9404 |  0x42979cc | Raw profile type APP1__x...Y.$..E...-... | .generic profile.    8382.49492a00080000 | II*_.___._..._.___.___1.._.___2___i.._._
     9464 |  iTXt |     818 | 0x3db44517 | XML:com.adobe.xmp_____<?xpacket begin=".
    10294 |  IDAT |    8192 | 0x34862364 | x...i....$h.y~....."._:._...xu.........
    18498 |  IDAT |    8192 | 0x12f5c893 | .....~......!...!..:n?.#Ep^......_....L.
    26702 |  IDAT |    8192 | 0xb480b14c | .......5.Ki......l.ny.F......9..fx.+..U[
    34906 |  IDAT |    8192 | 0x84418fad | :Cm.o...B..R..j..... ..iuG-...?.*..(|...
642 rmills@rmillsm4:~/Downloads $

However, the decompressed Exif block in a PNG (after being decompressed and dehexed) should be: Exif__II*..... (as seen in test/data/ReaganLargePng.png)

The Google file has II*... without the Exif__ leader.

647 rmills@rmillsm4:~/gnu/github/exiv2/0.27-maintenance $ tvisitor -pRU test/data/ReaganLargePng.png 
STRUCTURE OF PNG FILE (MM): test/data/ReaganLargePng.png
  address | chunk |  length |   checksum | data                                     | decompressed                             | dehexed
        8 |  IHDR |      13 | 0x8cf910c3 | ___.___...___
       33 |  zTXt |    8461 | 0x91fbf6a0 | Raw profile type exif__x...iv..r..c.^..a | .exif.    8414.45786966000049492a0008000 | Exif__II*_.___._._._.________.._.___.___
*** dump Exif *** 
     8506 |  zTXt |     636 | 0x4e5178d3 | Raw profile type iptc__x..TKn.0....=...u | .iptc.     778.3842494d04040000000002fd1 | 8BIM..____....Z_..%G..P_ Photographer..s
*** dump Iptc ***      9154 |  iTXt |    7156 | 0x8d6d70ba | XML:com.adobe.xmp_____<?xpacket begin=".
    16322 |  gAMA |       4 |  0xbfc6105 | __..
    16338 |  iCCP | 1151535 | 0x11f49e31 | ICC profile__x...UP......._.!!B....a.qwW | _.. APPL..__prtrRGB Lab .._._._._._)acsp | 
*** dump Icc *** 
  1167885 |  bKGD |       6 | 0xa0bda793 | _._._.
  1167903 |  pHYs |       9 | 0x78a53f76 | __.#__.#.
  1167924 |  tIME |       7 | 0x582d32e4 | ......2
  1167943 |  zTXt |     278 | 0xdb1dfff5 | Comment__x.}..n.@....O..5..h..X/M.F.=.8. | 040621-N-6536T-062.USS Ronald Reagan (CV | 
  1168233 |  IDAT |    8192 | 0x929ed75c | x...k.%.u%....D......GWW...ER.-.6%.%q<.x
  1176437 |  IDAT |    8192 | 0x52c572c0 | .F('.T)\....D"]..."2 '(...D%....(.'&.GTN
  1184641 |  IDAT |    8192 | 0x65a90ffb | y-_....>....3..p.....$....E.Bj%v.v....}.
  1192845 |  IDAT |    8192 | 0xf44da161 | ...S...?..G.....G........../.....E.>4
  1201049 |  IDAT |    7173 | 0xbe6d3574 | .evl...3K..j.S.....x.....Z .D.....b..k1
  1208234 |  IEND |       0 | 0xae426082 | 
END: test/data/ReaganLargePng.png
648 rmills@rmillsm4:~/gnu/github/exiv2/0.27-maintenance $ 

This could be invalid PNG/EXIF as exiftool doesn't decode the exif data either.

674 rmills@rmillsm4:~/Downloads $ exiftool ~/gnu/github/exiv2/0.27-maintenance/test/data/ReaganLargePng.png  | grep -i software
Software                        : GIMP 2.9.5
Profile Copyright               : basICColor dropRGB v1.2 - Copyright (c) 2006 Color Solutions Software, All Rights Reserved.
675 rmills@rmillsm4:~/Downloads $ exiftool Gemini_Generated_Image_20wm9820wm9820wm.png | grep software
676 rmills@rmillsm4:~/Downloads $ 

[clanmills]

I have a patch for this on the 0.27-maintenance branch.

I think the Google file is invalid. The zTXt chunk has the signature:

      48 | zTXt  |    9404 | Raw profile type APP1..x...Y.$ | 0x042979cc

So, I see two issues with the file.

1. Raw profile type APP1
2. II*... without leading 'Exif__'

The patch forgives both. This patch will require a corresponding change to PngImage::printStructure(). Let me know if you want assistance with that: robinwmills@gmail.com

diff --git a/src/pngchunk_int.cpp b/src/pngchunk_int.cpp
index e7844f108..0d70fd447 100644
--- a/src/pngchunk_int.cpp
+++ b/src/pngchunk_int.cpp
@@ -259,7 +259,8 @@ namespace Exiv2 {
             {
                 // Find the position of Exif header in bytes array.
 
-                const byte exifHeader[] = { 0x45, 0x78, 0x69, 0x66, 0x00, 0x00 };
+                const byte exifHeader[]  = { 0x45, 0x78, 0x69, 0x66, 0x00, 0x00 };
+                uint       exifHeaderLen = 6  ;
                 long pos = -1;
 
                 for (long i=0 ; i < length-(long)sizeof(exifHeader) ; i++)
@@ -270,15 +271,20 @@ namespace Exiv2 {
                         break;
                     }
                 }
+                
+                // Gemini_Generated_Image_20wm9820wm9820wm.png 
+                if ( pos == -1 && memcmp("Raw profile type APP1", key, 21) == 0 ) {
+                     pos           = 0;
+                     exifHeaderLen = 0 ;
+                }
 
                 // If found it, store only these data at from this place.
-
                 if (pos !=-1)
                 {
 #ifdef EXIV2_DEBUG_MESSAGES
-                    std::cout << "Exiv2::PngChunk::parseChunkContent: Exif header found at position " << pos << "\n";
+                    std::cout << "Exiv2::PngChunk::parseChunkContent: Exif header found at position " << pos << " exifHeaderLen = " << exifHeaderLen << "\n";
 #endif
-                    pos = pos + sizeof(exifHeader);
+                    pos += exifHeaderLen ;
                     ByteOrder bo = TiffParser::decode(pImage->exifData(),
                                                       pImage->iptcData(),
                                                       pImage->xmpData(),

Patch in action:

839 rmills@rmillsm4:~/gnu/github/exiv2/0.27-maintenance/build $ exiv2 -pe ~/Downloads/Gemini_Generated_Image_20wm9820wm9820wm.png 
Exif.Image.Orientation                       Short       1  1
Exif.Image.Software                          Ascii       7  Picasa
Exif.Image.ExifTag                           Long        1  58
Exif.Photo.ExifVersion                       Undefined   4  48 50 50 48
Exif.Photo.ColorSpace                        Short       1  1
Exif.Photo.PixelXDimension                   Long        1  1024
Exif.Photo.PixelYDimension                   Long        1  832
Exif.Photo.InteroperabilityTag               Long        1  170
Exif.Iop.InteroperabilityIndex               Ascii       4  R98
Exif.Iop.InteroperabilityVersion             Undefined   4  48 49 48 48
Exif.Photo.ImageUniqueID                     Ascii      33  1d4646cec8a4defa0000000000000000
Exif.Thumbnail.Compression                   Short       1  6
Exif.Thumbnail.XResolution                   Rational    1  72/1
Exif.Thumbnail.YResolution                   Rational    1  72/1
Exif.Thumbnail.ResolutionUnit                Short       1  2
Exif.Thumbnail.JPEGInterchangeFormat         Long        1  294
Exif.Thumbnail.JPEGInterchangeFormatLength   Long        1  8088
840 rmills@rmillsm4:~/gnu/github/exiv2/0.27-maintenance/build $ exiv2 -pe ../test/data/ReaganLargePng.png | head -7
Exif.Image.NewSubfileType                    Long        1  0
Exif.Image.ImageWidth                        Long        1  200
Exif.Image.ImageLength                       Long        1  130
Exif.Image.BitsPerSample                     Short       3  8 8 8
Exif.Image.Compression                       Short       1  5
Exif.Image.DocumentName                      Ascii      59  /media/trekstor/exiv2/exiv2-svn/test/data/ReaganLarge.tiff
Exif.Image.ImageDescription                  Ascii     403  040621-N-6536T-062
841 rmills@rmillsm4:~/gnu/github/exiv2/0.27-maintenance/build $ 

[skierpage]

Thanks for being so responsive! For what it's worth I sent feedback to Google within its gemini web page, and created an issue in its discussion forum.

[clanmills]

@skierpage Thanks for reporting that to Google. I hope they respond is a constructive way.

I've retired from Exiv2 and visit occasionally to see what's happening. The 0.27-maintenance release is at the end of life. I shipped 0.27 in December 2018. If Google change nothing, my code is a first step to accepting this file as valid.

Both macOS Preview.app and ACDsee Photo Studio for Mac fail to read the Exif metadata in the file.

On a philosophical level, this is clear evidence that the AI isn't as smart as we are told. Google have not sufficiently tested their generated files. If that file is valid PNG, they should have raised a bug on Exiv2 (and the Open Source applications that use Exiv2).

[kmilos]

Yeah, the whole "Raw profile type APP1" (or "Raw profile type exif") was a legacy kludge as PNG didn't have a real Exif chunk and there never was a standardized way of dong it, so various people went about it differently... As APP1 payload was copied over from JPEG, it was kind of assumed/given it would have the "Exif\0\0" 6-byte prefix.

It now does, so you could also suggest to Google to follow the new spec.

Unfortunately it looks like they fed Gemini (or it somehow figured out) to use the least common way of doing it! 😮

[kmilos]

Thanks @clanmills, I might take a look at your changes and port them to 0.28.x... Hope retirement is treating you well!

[clanmills]

Ah, @kmilos, I am always delighted by your knowledge. I looked at the PNG spec and found nothing about "Raw profile type". Exif support in PNG is built on sandy foundations.

Google should should adopt the "Raw profile type exif" convention for exif metadata.

Phil Harvey has documented "Raw profile type xxxx" in which xxxx := { 8bim | APP1 | exif | icc| icm | iptc | xmp }
https://exiftool.org/TagNames/PNG.html

PNG TextualData Tags

The PNG TextualData format allows arbitrary tag names to be used. The tags listed below are the only ones that can be written (unless new user-defined tags are added via the configuration file), however ExifTool will extract any other TextualData tags that are found. All TextualData tags (including tags not listed below) are removed when deleting all PNG tags.

These tags may be stored as tEXt, zTXt or iTXt chunks in the PNG image. By default ExifTool writes new string-value tags as as uncompressed tEXt, or compressed zTXt if the Compress (-z) option is used and Compress::Zlib is available. Alternate language tags and values containing special characters (unless the Latin character set is used) are written as iTXt, and compressed if the Compress option is used and Compress::Zlib is available. Raw profile information is always created as compressed zTXt if Compress::Zlib is available, or tEXt otherwise. Standard XMP is written as uncompressed iTXt. User-defined tags may set an 'iTXt' flag in the tag definition to be written only as iTXt.

Signature	Comment	More...
Raw profile type 8bim	Photoshop_Profile	--> Photoshop Tags(unregistered)
Raw profile type APP1	APP1_Profile	--> EXIF Tags--> XMP Tags(unregistered)
Raw profile type exif	EXIF_Profile	--> EXIF Tags(unregistered)
Raw profile type icc	ICC_Profile	--> ICC_Profile Tags(unregistered)
Raw profile type icm	ICC_Profile	--> ICC_Profile Tags(unregistered)
Raw profile type iptc	IPTC_Profile	--> Photoshop Tags(unregistered).
Raw profile type xmp	XMP_Profile	--> XMP Tags(unregistered)

Life in retirement is wonderful. Alison and I are both in good health and excellent spirits. I was at Brass Band School last week: https://clanmills.com/2025/Events/IBBSS/

[kmilos]

Google should should adopt the "Raw profile type exif" convention for exif metadata.

They should really switch to PNGv3 w/ a proper eXIf chunk and drop this legacy nonsense born out of necessity. 😉

[clanmills]

@kmilos The sensible course of action here is for Google to adopt the "Raw profile type exif" convention for exif metadata. My patch will lead to more work in PngImage::printStructure(), PngImage::writeMetadata() and associated test files.

I believe the eXIf chunk is never compressed.

Google have used an unconventional method of storing Exif metadata and this will inflict pain on everybody. Google should choose either chunk eXif or chunk zTXt + signature Raw profile type exif.

[kmilos]

I've just pushed a PR that should address this, please feel free to test - it's on main, but should apply to 0.28.x branch cleanly.

I think no other changes should be necessary... Edit: scratch that, will need to fix a few more places as @clanmills wisely figured out already...