Closed Yang-z closed 11 months ago
@Yang-z nice catch, that is definitely a bug. Let me write a test case for this and then update the change and push out a new release.
That's a weird bug, thanks for also suggesting the fix
🤔 I think there could be all types of bugs coming from that. like if UserComment was 0003
or something...
FYI: I'm writing tests and trying to think of an elegant way to implement this... might just have to be giving users an option. It's very funky behavior actually... I really wish the JSON adhered to the tag type
So I forsee a problem... I may have to remove this code which supports ujson
, since the ujson
library does not take in the parameters of the built-in json
library
Assuming I pull out the json.loads
call or make an adjustment to params passed to it, I would have to drop support for ujson
to address this issue
Let me think more about how to solve this without breaking too much compatibility... in theory, by removing direct (seamelss) support to ujson
, I might be able to effectively enable usage of other libraries like simplejson
or orjson
in the API
@Yang-z thanks for reporting this bug... I think there's other quirky undocumented behavior with exiftool that might end up being bugs. I wrote an FAQ for set_json_loads that you can use to address this issue
@sylikc I'm happy to see you find a way out elegantly. Thanks a lot. I am going to try the new version now.
Hi,
After I write a value e.g.
1.10
to the tagExif:UserComment
and read it by pyExifTool using method involving json (exiftoolhelper.get_tags()), the return value becomes1.1
, the precision just lost. (1.10
means 10th January for me, not equal to1.1
.)According to exiftool doc: exiftool OPTIONS
Additionally, the original outputs of exiftool do keep zeros at the end:
So, I guess parse float as str is nessary. And the fellowing code could fix the problem:
I think It's a good idea to add a option to let users to parse float as str without modifing the lib of pyexiftool.