cjee21

So I see that for mkv to mkv, FFmpeg does copy over the `_STATISTICS_WRITING_APP` and `_STATISTICS_WRITING_DATE_UTC` so MediaInfo should use the method at https://codeberg.org/mbunkus/mkvtoolnix/wiki/Track-statistics-tags#determining-if-the-tags-are-up-to-date to detect that it is likely...

Another way to have both statistics and CRC is to mux with MKVToolNix the run through mkclean. But while trying to see which elements it adds CRC for since MediaInfo...

The one from [MediaArea build farm](https://mediaarea.net/download/snapshots/binary/libmediainfo0/20250417/) is too small for the x86_64 part but the one built on GitHub Actions seems okay. I made a test run here: https://github.com/cjee21/MediaInfo/actions/runs/14535214318 Look...

Can try the [Qt version](https://github.com/MediaArea/MediaInfo/tree/master/Project/QMake/GUI). There are no official builds at the moment but it now has language selection and is very close to the Windows version.

?? This got closed? Need another force push to remove the artifact generation and retest.

Added error message which will appear as annotations on GitHub Actions page for the run if the CLI output is not as expected.

Apple also has it: https://www.androidauthority.com/google-apple-hdr-photo-standard-3495035/

More samples (ISO 21496-1?) here: https://helpx.adobe.com/camera-raw/using/gain-map.html

Looks like there are multiple formats, the Android Ultra HDR XMP, Adobe XMP, Apple XMP and the under-development ISO 21496-1 that they all are going to support too.

JPEG uses [MPF](https://exiftool.org/TagNames/MPF.html) to store the additional image. I wonder if Sony's old 3D photos also uses this.