ExifTool Forum

[Originally posted by metadatacrucher on 2009-01-27 12:10:21-08]

Hi,

it would be nice if Exiftool could write/dump JSON (Javascript Object Notation) streams/files similar to XML/CSV Export.

Why? It's a slim export format and getting more and more popular for inter-application data exchange.

[Originally posted by exiftool on 2009-01-27 12:15:25-08]

Thanks for the suggestion.  I'll look into this.

- Phil

[Originally posted by metadatacrucher on 2009-01-28 09:02:04-08]

Thanks for digging into this!
I forgot to mention the maybe biggest advantage of JSON:
the support of datatypes like numbers, arrays, objects.
This reduces the parsing amount for exiftool data significantly (e.g. no more need to separator-split a keyword list).

[Originally posted by janfri on 2009-02-04 11:47:18-08]

Indeed that would be very helpful.

[Originally posted by exiftool on 2009-02-04 16:29:56-08]

How about something like this for the output format?:

Basic JSON output:


Above, I have suppressed all tags with the same name to
avoid duplicate entries.  In the next 2 examples, duplicate
tag names are output as long as they are in different groups:

With group names for each tag (the -G1 option):


And with group sections (-g1):


Any suggestions would be useful.  For instance, should I
drop the quotes around numerical values?

- Phil

[Originally posted by metadatacrucher on 2009-02-04 19:52:40-08]

Hi Phil,

thanks for your suggestions! I recommend to make use of the JSON datatypes (see http://json.org/) and not just export everything as string or as an array. For example, numerical values should be exported as numbers (no quotes) and boolean values (e.g. flash used?) as true/false. Maybe also fractional values such as shutter speed could be exported as numbers.

This ensures that JSON parsers in other languages can automatically convert the value to the correct datatype.

I really appreciate that there will be a "flat" (-G1) and a "nested" (-g1) JSON structure, which should also the data access.

I also think it's better to use an array for multi-file output, since Javascript Objects don't preserve the order of their attributes (similar to an associative array in perl):

[Originally posted by exiftool on 2009-02-04 22:29:27-08]

Thanks for the good suggestions.  I will remove the quotes from
valid numbers according to specification on json.org.

The true/false is a bit of a problem because there are really
very few values exactly like this.  There are values like On/Off,
Yes/No, Enabled/Disabled, etc, but they all have subtly different
meanings, although logically they do come down to true/false.
So I don't think I want to do this.

I like your idea about the array.  I'm assuming it will be OK
to do this even when there is only one file read.

- Phil

[Originally posted by metadatacrucher on 2009-02-05 08:18:16-08]

Hi Phil,

yes, it's definitely a good idea to emit a JSON array even when just one image is read. This ensures the programmer can use the same logic (array iteration) to process a single or multifile-output.

About the boolean values: here we are in an old dilemma - do we want the value to be "queryable" in a database (then boolean values/enumerated constants would be a better option) or "presentable" to an enduser (this means to provide meaningful translations of the values).

I see this problem in a bigger context (also with the recent translation efforts). I think it's to early to definitely decide on it. For now, just implement JSON support in your way... I'm sure sooner or later there will be suggestions to refine it with additional export options.

- Franz

[Originally posted by exiftool on 2009-02-05 12:43:50-08]

There you go.  Give version 7.65 a try.  You'll find a
new -j option.

- Phil

[Originally posted by janfri on 2009-02-05 12:48:01-08]

Wow, 7.65 comes with JSON support. Thanks a lot.

About something I'm wondering: Why is not the uppercase letter -J taken for the output format like -T or -X?

Regards,
Jan Friedrich

[Originally posted by exiftool on 2009-02-05 12:59:35-08]

Hi Jan,

You can use -J if you want.  The uppercase options are only
required when there is a conflict with an existing option that has a
different meaning.  Otherwise, case is not significant for any option.

Here there was no existing -j option, so case doesn't
matter.

It is interesting to note that there is only one letter of the alphabet remaining
unused now, and that is -y.  There are existing options for
all other letters.

This is actually one reason why I was happy to add JSON support.
If it were called SJON, I wouldn't have been so willing.

- Phil

[Originally posted by janfri on 2009-02-05 14:08:14-08]

Then we just need YAML support and -y is also used.

Jan

[Originally posted by exiftool on 2009-02-05 14:32:09-08]

LOL.  True.  That fits nicely doesn't it.  

- Phil

[Originally posted by metadatacrucher on 2009-02-05 19:59:45-08]

Hi Phil,

thanks for implementing this so quickly! I'm sure this will increase the "usability" of exiftool's output a lot.