mapillary
Full Exif Tag Precision and Dynamic Length Decimal Values for Numeric Values in Image Description File
Is the PR still needed if decimal values are serialized in JSON, instead of converting to EXIF rational values? See my comment in https://github.com/mapillary/mapillary_tools/pull/782.
It is at least in that sense that the current hard coded decimal fraction precision of 7 places can be insufficient to exactly represent some Exif rationals in the range -100 < x < 100. Furthermore, this PR also enables users who want to consume and modify the image description file to tune precision to their needs.
@JakeSmarter Do we really need to care about the whole number part? Can we just increase the precision to 8 for all?
@ptpt We do not have to care about the integer part but then we would need to increase precision to 10 faction decimal places in order to represent full precision for all possible Exif rational values. In fact, by doing so we would be able to represent a lot more values than is need for Exif rationals. On average, this is going to result in quite long decimal numbers. Much longer than actually needed in the vast majority of cases. A sign character, 13 digit characters, and a decimal fraction dot character in the worst case scenario. In total, 15 bytes for one number. Is this something we can or want to accept? I have no opinion on this. I am just stating potential consequences. This PR limits emitted numbers to 10 (or fewer if possible) decimal places, which is enough to represent all possible Exif rational values. You could call it an (space) optimization.
By the way, I have already successfully uploaded multiple sequences using this code branch. Again, I have no opinion on this. Maybe someone can disprove my reasoning, which I am also fine with. Do as you like.