Excerpt from #1464 (comment) case 2:
This is still buggy after PR #1469.
mkdir -p ~/temp
curl https://user-images.githubusercontent.com/4997431/106392842-090dc700-63f4-11eb-856e-749f697bd64d.jpg >! /temp/1464.jpg 2>&-
./exiv2 -pa --grep 2010e.LensType2 ~/temp/1464.jpg
./exiv2 -M'set Exif.Image.ImageDescription Ascii 01234567890123456789012345678901' ~/temp/1464.jpg
./exiv2 -pa --grep 2010e.LensType2 ~/temp/1464.jpg
yields on 0.27-maintenance:
Exif.Sony2010e.LensType2 Short 1 1024 # <-- correct
Exif.Sony2010e.LensType2 Short 1 51712 # <-- wrong
No corruption if the new ImageDescription is shorter than 32 characters (and fits in the already allocated tag); see case 1 in the earlier bug report.
The same corruption with ./exiv2 -M'set Exif.Image.ImageID Ascii foobar' ~/temp/1464.jpg to add a new tag; see case 3 in the earlier bug report.
On master, Sony2010e tags are not printed, but exiftool (e.g., via exiftool -v ~/temp/1464.jpg | grep WB_RGB) confirms that the values are not corrupted.
Excerpt from #1464 (comment) case 2:
This is still buggy after PR #1469.
yields on 0.27-maintenance:
No corruption if the new ImageDescription is shorter than 32 characters (and fits in the already allocated tag); see case 1 in the earlier bug report.
The same corruption with
./exiv2 -M'set Exif.Image.ImageID Ascii foobar' ~/temp/1464.jpgto add a new tag; see case 3 in the earlier bug report.On master, Sony2010e tags are not printed, but exiftool (e.g., via
exiftool -v ~/temp/1464.jpg | grep WB_RGB) confirms that the values are not corrupted.