[FFmpeg-devel] [PATCH v2 0/3] [RFC] Exif Overhaul
Anton Khirnov
anton at khirnov.net
Tue Oct 1 14:36:24 EEST 2024
Quoting James Almer (2024-09-30 01:01:39)
> On 9/16/2024 11:43 AM, Leo Izen wrote:
> > I've made some changes to the last EXIF overhaul patch I sent,
> > notably I fixed up some bugs and added MakerNote parsing, so it
> > should not corrupt MakerNotes that are inside TIFF files.
> >
> > MakerNote is supposed to be a binary blob but many camera manufacturers
> > treat it as an IFD (e.g. Canon) with offsets relative to the start of the file,
> > so it has to be parsed in order to move it from TIFF to another file or it will
> > be corrupted.
> >
> > I also fixed the fate tests now that pngenc.c writes eXIf chunks, so those should
> > pass.
> >
> > I haven't come up with a solution that Andreas proposed, which is:
> >
> >> If I see this correctly, then these patches can lead to a situation
> >> where an input packet has rotation metadata in exif which gets exported
> >> twice -- as displaymatrix and as exif metadata side data. If the user
> >> changes the displaymatrix (e.g. applies the transformation to the image
> >> data and removes the displaymatrix side data before reencoding), the
> >> exif data (that the user would probably not be aware of) would still be
> >> there and get propagated into the output, corrupting it.
> >
> > Zeroing out the EXIF orientation tag upon attaching the displaymatrix is
> > something I did consider, but it would corrupt encoding unless I also read
> > the displaymatrix data and attach it as EXIF orientation. This isn't too hard
> > if the Orientation tag exists but it's more difficult if it doesn't already
> > exist. It's also not clear what to do if the AVDisplayMatrix is not in the
> > dihedral group D4.
> >
> > Currently there's no code that takes an AVDictionary and writes it back into
> > EXIF as these are not compatible structures. EXIF includes integers of varying
> > lengths, while AVDictionary contains strings only.
>
> Conversion from AVDictionary to coded EXIF metadata would be lossy
> anyway because of the double type.
So why not introduce an (extensible) struct for "parsed EXIF" that
contains properly typed data instead of forcing our callers to parse
strings.
--
Anton Khirnov
More information about the ffmpeg-devel
mailing list