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)
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
