[FFmpeg-devel] [PATCH v2 0/3] [RFC] Exif Overhaul

[James Almer]

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.
What you could do i guess is write a function that removes a given entry 
from a raw EXIF buffer.

> 
> Leo Izen (3):
>    various: change EXIF metadata into AVFrameSideData
>    avcodec/pngdec: parse eXIf chunk
>    avcodec/pngenc: write eXIf chunks
> 
>   fftools/ffprobe.c                        |  27 +-
>   libavcodec/Makefile                      |   1 +
>   libavcodec/exif.c                        | 394 +++++++++++++++++++++--
>   libavcodec/exif.h                        |  32 +-
>   libavcodec/exif_internal.h               |  55 ++++
>   libavcodec/mjpegdec.c                    |  91 +-----
>   libavcodec/mjpegdec.h                    |   2 +-
>   libavcodec/pngdec.c                      |  35 ++
>   libavcodec/pngenc.c                      |   4 +
>   libavcodec/tiff.c                        |  19 +-
>   libavcodec/tiff.h                        |   1 +
>   libavcodec/version.h                     |   2 +-
>   libavcodec/webp.c                        |  38 +--
>   libavformat/avidec.c                     |   4 +-
>   libavutil/frame.c                        |   2 +
>   libavutil/frame.h                        |   6 +
>   tests/ref/fate/cover-art-mp3-id3v2-remux |   6 +-
>   tests/ref/fate/exif-image-embedded       |   5 +-
>   tests/ref/fate/exif-image-jpg            |  91 +++---
>   tests/ref/fate/exif-image-webp           |  91 +++---
>   tests/ref/fate/mov-cover-image           |   6 +-
>   21 files changed, 676 insertions(+), 236 deletions(-)
>   create mode 100644 libavcodec/exif_internal.h
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240929/278f3cfb/attachment.sig>