I’m feeling the need to dust off my D50…
1 Like
Erm. You mean a Nikon D50 Camera? TT
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.
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.
I kinda get that issue and why it matters.
Right. I’m sure for smaller libraries of images that is optimal.
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
@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
1 Like
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?
2 Likes
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.
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.
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
Right. Plugin.
It is too specialised to be anything other IMO.
TT
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,
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