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

[Leo Izen]

On 10/1/24 7:36 AM, Anton Khirnov wrote:
> 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.
> 

EXIF is basically an IFD, or a tiff directory, that contains a list of 
tags. Each tag has a type, which may also be IFD.

How would you recommend I go about doing this in a way that works with 
frame side data, which as far as I understand has to be a flat buffer? 
Doing so with sizeof(foo) would not work if I need extensibility.

- Leo Izen (Traneptora)