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 _______________________________________________ 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".
