You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using the code at the bottom to remove GPS-related information from images, and I feed it images from iPhones converted to jpg.
The images that are generated as a result display fine, are accepted by exiftool as well as pretty much every tool I've found, but if you feed them again to the same function, if panics with "EOF", trying to read a long integer. Example below.
I've tracked it down to an issue in encodeTagToBytes when the tagID is 0xa301: because type is unknown, it defaults to bytes, which in turn makes unitCount be 4 instead of 1. When the decoder re-reads the produced image, it now thinks it's an offset, not a value.
I've tried changing the yaml in tags_data.go to
- id: 0xa301name: SceneTypetype_name: BYTE
but this now prevents the 0xa301 tag from being written.
The following hack works however, in encodeTagToBytes()
if bt.tagId == 0xa301 {
effectiveType = exifcommon.TypeLong
}
I'm not sure what an more elegant way to do this would be.
Here's an example function that illustrate the issue if called twice, once with an iPhone image (converted to jpeg) and once with the result of the previous iteration.
I'm using the code at the bottom to remove GPS-related information from images, and I feed it images from iPhones converted to jpg.
The images that are generated as a result display fine, are accepted by
exiftool
as well as pretty much every tool I've found, but if you feed them again to the same function, if panics with "EOF", trying to read a long integer. Example below.I've tracked it down to an issue in
encodeTagToBytes
when the tagID is 0xa301: because type is unknown, it defaults to bytes, which in turn makesunitCount
be 4 instead of 1. When the decoder re-reads the produced image, it now thinks it's an offset, not a value.I've tried changing the yaml in tags_data.go to
but this now prevents the 0xa301 tag from being written.
The following hack works however, in
encodeTagToBytes()
I'm not sure what an more elegant way to do this would be.
Here's an example function that illustrate the issue if called twice, once with an iPhone image (converted to jpeg) and once with the result of the previous iteration.
The text was updated successfully, but these errors were encountered: