Access to image metadata (EXIF)

[TiddlyTweeter]

@saqimtiaz

What isn’t clear and would be helpful is knowing the potential use cases for metadata access. Some user stories or scenarios would be very helpful here.

Off the top of my head some unanswered questions are:

• embedded images, external images on a local drive, or remote online images? In particular external images on a local drive might be difficult to work with.
• a one time extraction of image metadata, or an extraction on demand when display an image?

Right. I do see there could be several basic approaches.

Though I’ve mentioned it before it might be useful to re-iterate one typical use case of mine …

– 4,000 paintings by school children in the UK of “Guy Fawkes Night”. Scanned to jpg. Stored as external images in a sub-dir of the wiki at fireworks.html/img/. This is for local use and online use with the same structure on a host. So external images at relative addresses for both local and online.

– Each image contains meta-data I added via an image editor for:

• Name:
• Age:
• Gender:
• School:

– It is this data I want to display when the image is loaded. So extraction of meta-data on demand that exists in TW only for the showing.

I hope this is clear and the reason to want to do it that way too

Best wishes
TT

[saqimtiaz]

@TiddlyTweeter

So extraction of meta-data on demand that exists in TW only for the showing.

I would paraphrase that as follows:
Extraction of metadata on demand where the metadata is not saved in the TW.

Some thoughts off the top of my head follow.

Extracting metadata from images could easily get resource heavy so it would make sense to cache the data for repeated display of the same image. There could also be use cases where users want the metadata to persist in the wiki. The logical approach therefore would be to facilitate extracting metadata on demand and saving it in a tiddler, from where it can be displayed and re-used as needed. A setting that determined whether the tiddlers created to hold the metadata are temp tiddlers would allow for both uses cases: where the metadata is saved in the wiki, and only available until the wiki is reloaded.

A related issue is that the structure and content of the image metadata can vary widely so deciding how to store it in a tiddler would be challenging. Considering the nested nature of the data, the simplest approach would be to just save the raw JSON data and use the new core JSON operators currently in development to fetch and display what is required. That may however not be very user friendly for non-technical end-users.

[TiddlyTweeter]

@saqimtiaz

@TiddlyTweeter

So extraction of meta-data on demand that exists in TW only for the showing.

I would paraphrase that as follows:
Extraction of metadata on demand where the metadata is not saved in the TW.

Right. That is clearer.

TT

[TiddlyTweeter]

@saqimtiaz

There could also be use cases where users want the metadata to persist in the wiki.

Right!

A footnote to my “Guy Fawkes Night” usecase, which I did not mention (to avoid complexity), is the end-user should be able to “favourite” an image. In those cases I was thinking only that the “favourite” holds the link to the image (so you can visit it again) AND add one additional field for “comments”.

Hope this is clear!
TT

[TiddlyTweeter]

@saqimtiaz

The logical approach therefore would be to facilitate extracting metadata on demand and saving it in a tiddler, from where it can be displayed and re-used as needed.

In theory yes. But meta-data saved, eventually, for 4,000 images?

That was always my concern—that burdening TW with meta-data for 4,000 images was overkill?

I totally see for galleries of say 100 images it is no problem saving all the meta-data.

But my use case of 4,000 I’d say it don’t add anything to do that—except for a few where the end-user wants to preserve a link to an image???

Just thoughts!
I don’t actually know.
TT

[saqimtiaz]

@TiddlyTweeter

In theory yes. But meta-data saved, eventually, for 4,000 images?

Please pay attention to the subsequent sentence. As I mentioned, there could be a setting that you could use so that the metadata was saved in $:/temp/* tiddlers. Temp tiddlers would only be created for the images that are actually viewed and temp tiddlers are not saved in the wiki, they exist only in memory until the wiki is closed or reloaded, and should have no significant impact on the wiki in any form.

[TiddlyTweeter]

My emphasis in bold …

@saqimtiaz

Considering the nested nature of the data, the simplest approach would be to just save the raw JSON data and use the new core JSON operators currently in development to fetch and display what is required. That may however not be very user friendly for non-technical end-users.

Right.

BUT I think IF there is a final user interface that can query the JSON simply it will be well okay with idiots like me.

Just a comment
TT

[TiddlyTweeter]

@saqimtiaz

Please pay attention to the subsequent sentence. As I mentioned, there could be a setting that you could use so that the metadata was saved in $:/temp/* tiddlers. Temp tiddlers would only be created for the images that are actually viewed and temp tiddlers are not saved in the wiki, they exist only in memory until the wiki is closed or reloaded, and should have no significant impact on the wiki in any form.

Ciao @saqimtiaz

I think that approach is good!

Part of the issue for a developer is like at least 3 scenarios …

1 – Only fetch meta-data for temporary use (e.g. only sample from TT’s 4,000 for showing) — Images always external. Nothing kept.

2 – Fetch meta-data from images for permanent storage in TW. — Images external to TW but link to and kept meta-data internal. (e.g. smaller numbers needing decent docs, say 100).

3 – Fetch meta-data AND images from an arbitrary address for permanent storage in TW (e.g. my 15 cat images with meta-data).

I think this is the point, in a way, it gets complicated unless we also think about what it is FOR.

Just comments
Not wanting to muddy-the-waters.

TT

[TW_Tones]

Keep in mind metadata or exif data is going to be small compared to a typical image. My guess is not more than 1kb so 4k number of images will need 4mb bytes. Even safe in a single file wiki, perhaps i would need a node install for my 100k images. And one can purge data you dont need.

[TiddlyTweeter]

@TW_Tones

Keep in mind metadata or exif data is going to be small compared to a typical image.

I think that is very true. One MIGHT keep such meta-data regardless at lowish overhead.

But in my 4,000 scenario what would be the added value of doing that?

I guess you could analyse & filter on Age / School / Gender but to do that meaningfully I’d hope you’d be a child psychologist, art therapist or serious lover of primitive art.

A comment
TT

[Ste_W]

I’m feeling the need to dust off my D50…

[TiddlyTweeter]

@Ste_W

the need to dust off my D50…

Erm. You mean a Nikon D50 Camera? TT

[saqimtiaz]

@TiddlyTweeter

3 – Fetch meta-data AND images from an arbitrary address for permanent storage in TW (e.g. my 15 cat images with meta-data).

In practice this would take the form of the user dragging and dropping the images into TW to import them. All the usual limitations we usually have with reading/writing external files still apply, so we cannot automate that import much further.

The trick that allows reading metadata from external images is that any image that can be referenced via a URI can be loaded in a canvas element to extract the image as binary data. We would in fact need to confirm that this does work for local images referenced via a relative path.

The potential logic of the code that fetches the metadata for an image could look something like this given a string that is either an image tiddler title or a URI:

• check if its a binary tiddler and if so extract the data directly
• if it is a URI, check if there is a tiddler storing the metadata for the image
  • if there is no such image, try to load it and extract its data and place it in a tiddler.

The benefit of putting the metadata in a tiddler is that you can use usual wikitext techniques for deciding how to display it. It would also allow insight for users into what metadata is available and make it easier for users to determine what part of it to display.

@TiddlyTweeter

I think this is the point, in a way, it gets complicated unless we also think about what it is FOR.

Absolutely and more user stories from others would be helpful. Another consideration could be, what happens if we have saved metadata and the metadata in the image file changes? Might not matter for most use cases but it really depends on the users needs and workflow.

Mind you I am not committing myself to implementing anything here but we can at least chart out the best approach to take.

[TiddlyTweeter]

@saqimtiaz

The potential logic of the code that fetches the metadata for an image could look something like this given a string that is either an image tiddler title or a URI:

• check if its a binary tiddler and if so extract the data directly
• if it is a URI, check if there is a tiddler storing the metadata for the image
  • if there is no such image, try to load it and extract its data and place it in a tiddler.

I kinda get that issue and why it matters.

@saqimtiaz

The benefit of putting the metadata in a tiddler is that you can use usual wikitext techniques for deciding how to display it. It would also allow insight for users into what metadata is available and make it easier for users to determine what part of it to display.

Right. I’m sure for smaller libraries of images that is optimal.

@saqimtiaz

Mind you I am not committing myself to implementing anything here but we can at least chart out the best approach to take.

Right.

I am not expecting anything. I just happily surprised you had enough interest to facilitate this discussion practically.
It has been very useful, at least to me.

I am thankful.

TT

[TW_Tones]

@TiddlyTweeter the key metadata I would like as discussed in this thread and the original thread?, metadata available in a litebox were raised in my reply Spotlight: A Dream to Have a LightBox Gallery in Tiddlywiki - #22 by TW_Tones

[Flibbles]

This is a really neat idea, but we’d all be in agreement that a feature like this would be best suited for a plugin, and not to be added to core code, right?

[Mark_S]

@TiddlyTweeter

• Name:
• Age:
• Gender:
• School:

Since you have an editor that will let you do this, you might experiment to see if Saq’s solution will work with your custom fields, or if the EXIF namespace is rigorously applied.

I note that the native EXIF info would be mostly of value only to a photography aficionado.

[TiddlyTweeter]

@Mark_S

Since you have an editor that will let you do this, you might experiment to see if Saq’s solution will work with your custom fields, or if the EXIF namespace is rigorously applied.

It works. But his solution is best for embedded images, I think, which is a no-no for me. But the proof of concept by @saqimtiaz is real neat.

@Mark_S

I note that the native EXIF info would be mostly of value only to a photography aficionado.

Totally right! Even as a photographer I am totally bored by knowing your “exposure” or lens type. Generally useful, in standard fields, are likely date and geolocation? But even then only in some circumstances.

For myself I long used EXIF to store descriptive details of an image so that in image software I can find exactly what image I am looking for.

TT

[TiddlyTweeter]

@Flibbles

This is a really neat idea, but we’d all be in agreement that a feature like this would be best suited for a plugin, and not to be added to core code, right?

Right. Plugin.

It is too specialised to be anything other IMO.

TT

[TW_Tones]

@Flibbles

a feature like this would be best suited for a plugin, and not to be added to core code, right?

es, like most new features a plugin is the way to start, however time will tell if it needs to move into the core. One key advantage is other plugins will not need a dependency or to separately handle this process. Keep in mind just because tiddlywiki can then extract, store or view exif data does not mean you want or need to, you may change your mind and want to do so later, if tiddlywiki strips the data then this is lost information.

• I think it is wrong for tiddlywiki to import something and selectively and silently remove a part of what was imported (the metadata), although an option to do so would be a good feature,

@Mark_S

I note that the native EXIF info would be mostly of value only to a photography aficionado.

I am not sure I can fully agree with this, but it will be of great value to “photography aficionados”, because earlier I was using tiddlywiki to obtain Geolocation info from the phone (Yes it worked), import or send images to tiddlywiki (in an app) and interact with https://what3words.com/ and access to images location and time (rather than merely the images file date, which changes with a simple edit like crop and contrast).

That is, being able to handle accurate time and date details, and geolocation info inside and outside images, and within mobile apps (which tiddlywiki can be) at a minimum, is now almost universally taken for granted, but also a key part of mobile and desktop mapping, street view and photography to name a few. Time of an image and location is useful to blogging, personal logging, tracking diets, family history, restaurant and accommodation reviews, for matters relating to weather and more. I has even being critical in a few case to legal matters.

[Post script edit]

what3words API

The what3words API is a fast and simple interface that allows you to convert 3 word addresses to coordinates and vice versa. It features a powerful AutoSuggest function, which can validate user input and limit it to certain geographic areas. We offer a variety of libraries, including Java, JavaScript, Swift, Python, Node.js, PHP and more to make our API easy to integrate for your business. Get started with the what3words API | what3words