Please attach a test case here.

Created attachment 288804 [details]
test case for EXIF embedded in PNG

Is Exif in PNG in some way standardized?
From my understanding, what we see here is more or less a thing that is introduced by ImageMagick while converting from JPEG.

Felix is correct.  EXIF in PNG is not standardised.  In fact the JEITA EXIF standard specifies that it is not supported in PNG.  EXIF is only supported in JPEG, TIFF Rev. 6.0 (RGB or YCbCr, but not CMYK) and RIFF WAV.

A PNG file starts with an 8-byte file header followed by a series of chunks, each of which conveys certain information about the image. Chunks declare themselves as critical or ancillary, and a program encountering an ancillary chunk that it does not understand can safely ignore it.

The case of the first letter of the chunk name indicates whether the chunk is critical or not. If the first letter is uppercase, the chunk is critical; if not, the chunk is ancillary.

The file attached to comment 2 declares 5 ancillary chunks:

* zTXtRaw - a compressed name=value pair of text, which in this example reads "profile type exif".
* bKGD - gives the default background color. It is intended for use when there is no better choice available, such as in standalone image viewers (but not web browsers).
* pHYs - holds the intended pixel size and/or aspect ratio of the image (note that the critical IHDR chunk also contains (in this order) the image's width, height, bit depth and color type).
* tIME - stores the time that the image was last changed.
* iTXtComment - contains UTF-8 text, which in this example reads "Created with GIMPd.e"

Support for some of these ancillary chunks would be easier to add to eog (or an eog-plugin) than others.  The Date in statusbar plugin already displays the DateTimeOriginal (0x9003) and DateTimeDigitized (DateTimeDigitized) EXIF tags (but not the DateTime (0x0132) tag which shows the Date/Time the image was last modified) and could probably be extended to read and display the 7 byte long tIME ancillary chunk's value (0x07DE0A120C3923) in the image you attached.

Oops.  The last comment should read, in part, "DateTimeDigitized (0x9004)".

If DateTimeOriginal is mapped using MWG Guidelines then eog reads the value from Xmp.photoshop.DateCreated

According to PNG specifications, XMP rather then EXIF is the correct place to store this type of data. 

* iTXt contains UTF-8 text, compressed or not, with an optional language tag. iTXt chunk with the keyword 'XML:com.adobe.xmp' can contain Extensible Metadata Platform (XMP).

exiv2 can read exif data in PNG files.

Solution may be: Bug 515265 - use exiv2 as metadata source 
      https://bugzilla.gnome.org/show_bug.cgi?id=515265

Extracting the data isn't the issue here. eog already has code that parses the PNG chunks looking for XMP and ICC data.

The thing is that Exif-in-PNG looks to me like 'crutch' that ImageMagick employs when converting JPEGs to preserve the metadata. Are there any other apps writing such files? I am not sure eog should support such 'inofficial' standards as that could open the door to other not-so-standard stuff.

Created attachment 306125 [details]
PNG with EXIF data added by gThumb

This PNG file has EXIF, IPTC and XMP data added by gThumb.

Before opening the image in gThumb, it had zero metadata. The data was added  via the Comments metadata editor in gThumb.

$ exiv2 -pa gthumb.png 
Exif.Image.XResolution                       SLong       1  72
Exif.Image.YResolution                       SLong       1  72
Exif.Image.ResolutionUnit                    SLong       1  pulgada
Exif.Image.DateTime                          Ascii      20  2015:06:25 12:50:03
Exif.Image.YCbCrPositioning                  SLong       1  Centrado
Exif.Image.ExifTag                           Long        1  106
Exif.Photo.ExifVersion                       Undefined   4  2.21
Exif.Photo.ComponentsConfiguration           Undefined   4  YCbCr
Exif.Photo.UserComment                       Ascii      19  gthumb description
Exif.Photo.FlashpixVersion                   Undefined   4  1.00
Exif.Photo.ColorSpace                        SLong       1  sRGB
Iptc.Application2.Caption                    String     18  gthumb description
Iptc.Application2.Urgency                    String      1  0
Xmp.dc.description                           LangAlt     1  lang="x-default" gthumb description

Thanks Alan. Your comment 6 describes exactly how metadata _should_ be specified in a PNG file.  The issue we have here is that the original reporter's file does not follow those specifications, as Felix says in comment 8.  I note that you worked on exiv2 bug 864: Mapping of Exif DateTime fields to XMP changed in spec, so I am wondering if the original reporter would encounter the same issue if they used exiv2 0.25 to perform the process they described (Felix - ImageMagick is not involved as the original reporter removed the metadata before adding some metadata with exiv2).

I think eog should provide some limited support for reading and displaying some ancillary chunks such as tIME.  If anyone is interested in implementing this the structure of a PNG chunk is as follows:

_______________________________________________________
| Length  | Chunk type/name | Chunk data     | CRC     |
| 4 bytes | 4 bytes         | <Length> bytes | 4 bytes |
────────────────────────────────────────────────────────

The CRC is a network-byte-order CRC-32 computed over the chunk type and chunk data, but not the length.

The limited support I referred to above could also be provide in a plugin such as the Date in statusbar plugin.

The process using exiv2 I described in the original report was meant to illustrate the underlying problem, but the actual issue I encountered is described in the title.

In practice, my issue was the sudden inability to browse my collection of photographs, most of which have been processed using ufraw.
Ufraw is an example of a program that embeds EXIF metadata in PNG files. It does use libexiv2, so the problem may become less relevant if 0.25 uses native metadata format.

The copyExifToXmp class is not new to exiv2, what I changed was updating it to Metadata Working Group guidelines.

You can see it in action via: exiv2 -eX image.png; exiv2 -iX image.png

If you run that on your ufraw processed images, hopefully eog will then see the dates. Test it first! That command exports to a XMP sidecar file and then re-imports the metadata, while doing the conversions.

Exiv2 0.25 Conversion Table: http://www.exiv2.org/conversion.html 

exiv2 0.25 packages have landed in Fedora Rawhide, in gentoo, in opensuse ... We are still waiting for Debian ...

PS: You might want to ask the ufraw people why they don't abide by MWG guidelines. :-)

Continuing this aside - I don't think ufraw is adequately maintained this days... which is a shame, since SuperCCD cameras aren't supported with many other software.

I've just tried the command from comment 13 on the test image from comment 2.  EOG now shows the image date metadata on the Details tab of the Image Properties window!

Thanks Alan.

The Date in statusbar plugin does not show the metadata so I guess it doesn't understand XMP.  However the original reporter just wanted to use the File>Properties menu item so that is fine.

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/eog/-/issues/

Thank you for your understanding and your help.